Jenkins Backup and Restore Runbook: ThinBackup, Filesystem Archives, and Recovery Steps

Jenkins backup and restore is a core reliability control for CI/CD teams: if a controller host, disk, or VM fails, you need a repeatable way to recover jobs, credentials, plugins, and system configuration. This guide provides an implementation-focused runbook you can adapt for plugin-based backups (including ThinBackup-style workflows) or filesystem-level backups.

Originally published on 2015-09-20; fully revised and updated.

Legacy source and preserved references

The original post was a short link collection. The references below are preserved for attribution and historical context; validate each one before using it in production workflows.

• Original article permalink
• Jenkins Backup and Restore using ThinBakcup
• How Do I Backup Jenkins Jobs using Grunt?
• Backup Jenkins configuration to S3
• bash-backup-script for jenkins job-configs via user-crontab
• Backup and restore Jenkins using jenkins plugins
• YouTube video referenced in the source post

The original embedded YouTube gallery reported an API key restriction error, so this update does not rely on the embedded video content.

What to include in your Jenkins backup set

For most traditional Jenkins controller installations, the critical state is under JENKINS_HOME. At minimum, include configuration, jobs, plugins, and credential material needed for decryption and runtime access.

• ${JENKINS_HOME}/config.xml and related global configuration files
• ${JENKINS_HOME}/jobs/ (job definitions and job-level config)
• ${JENKINS_HOME}/plugins/ (installed plugin binaries and metadata)
• ${JENKINS_HOME}/users/ and node/controller metadata as applicable
• ${JENKINS_HOME}/credentials.xml together with ${JENKINS_HOME}/secrets/
• Any external dependencies your pipelines require to run after restore (for example, shared libraries or external secrets backends)

Backup strategy options compared

Recommended backup workflow

Use a workflow that emphasizes consistency, off-host durability, and regular restore verification.

flowchart TD
    A[Backup schedule triggers] --> B[Pre-backup checks]
    B --> C{Need strict consistency}
    C -- yes --> D[Stop Jenkins or quiesce]
    C -- no --> E[Proceed online]
    D --> F[Archive JENKINS_HOME]
    E --> F
    F --> G[Create checksum and retain]
    G --> H[Copy backup off-host]
    H --> I[Test restore in non-prod]
    I --> J[Record results]

Example commands: filesystem backup and off-host copy

This example prioritizes consistency by stopping Jenkins during archive creation. Adapt service name, user, and paths for your distribution or container platform.

#!/usr/bin/env bash
set -euo pipefail

JENKINS_HOME=/var/lib/jenkins
BACKUP_ROOT=/srv/backups/jenkins
STAMP=$(date +%F-%H%M%S)
ARCHIVE=${BACKUP_ROOT}/jenkins-home-${STAMP}.tar.gz

sudo systemctl stop jenkins
sudo mkdir -p ${BACKUP_ROOT}
sudo tar -C ${JENKINS_HOME} -czf ${ARCHIVE} .
sudo systemctl start jenkins

sha256sum ${ARCHIVE} | tee ${ARCHIVE}.sha256Code language: JavaScript (javascript)

# Off-host copy (example)
rsync -av --progress /srv/backups/jenkins/ backupuser@backup-host:/data/jenkins/Code language: PHP (php)

Example commands: restore on the same or a replacement host

Always preserve the current Jenkins home before overwrite, then restore from the selected archive.

BACKUP_FILE=/srv/backups/jenkins/jenkins-home-2026-10-14-010000.tar.gz

sudo systemctl stop jenkins
sudo mv /var/lib/jenkins /var/lib/jenkins.pre-restore
sudo mkdir -p /var/lib/jenkins
sudo tar -C /var/lib/jenkins -xzf ${BACKUP_FILE}
sudo chown -R jenkins:jenkins /var/lib/jenkins
sudo systemctl start jenkinsCode language: JavaScript (javascript)

Post-restore validation checklist

• Jenkins service is running and web UI is reachable
• Representative jobs appear and can be opened
• Credentials-backed jobs can authenticate to required systems
• Required plugins load without startup errors
• Agents/nodes reconnect and run at least one smoke build

sudo systemctl status jenkins
curl -I http://127.0.0.1:8080/loginCode language: JavaScript (javascript)

Best practices and common pitfalls

• Test restores regularly; a backup is only useful if restore is proven.
• Keep at least one off-host copy to survive host-level loss.
• Back up credentials material together (credentials.xml and secrets/).
• Document RTO/RPO and retention so backup behavior matches business recovery goals.
• Avoid single-method dependency; combine local quick-restore copies with durable remote storage.

Rajesh Kumar

I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.

I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.