[Jenkins] Jenkins 백업 스크립트의 정석 (서버가 불타도 3분 만에 부활하기)

데브옵스(DevOps) 엔지니어의 가장 큰 덕목은 배포 속도를 빠르게 만드는 것도 중요하지만, '최악의 장애 상황에서도 인프라를 신속하게 복구(Disaster Recovery)해 내는 것'입니다. 수십 개의 프로젝트 파이프라인과 플러그인, 계정 정보, 복잡한 인증키(Credentials)들이 세팅된 젠킨스 서버의 하드디스크가 어느 날 갑자기 물리적 장애로 뻗어버린다면 어떻게 될까요? 백업이 없다면 전사의 배포 프로세스는 수일 동안 올스톱되며 당신은 시말서를 피할 수 없을 것입니다.

이번 [Jenkins 실무 완벽 가이드] 시리즈에서는 이러한 끔찍한 재앙을 코웃음 치며 3분 만에 어제 상태로 복구해 내기 위한 완벽하고 효율적인 Jenkins 데이터 백업 스크립트 작성 노하우와 AWS S3 이중화 전략에 대하여 3,000자 분량으로 아주 치밀하게 딥다이브 해보겠습니다.

🗑️ 1. 무엇을 백업하고, 무엇을 버릴 것인가? (용량 최적화)

초보 인프라 관리자들은 "백업? 그냥 /var/jenkins_home 디렉토리 전체를 통째로 압축해서 보관하면 되잖아?"라고 생각합니다. 이는 매우 무식하고 위험한 발상입니다.

jenkins_home 내부에는 파이프라인 설정 파일뿐만 아니라, workspace/ (수십 GB에 달하는 소스코드와 node_modules), caches/, logs/ 같은 엄청난 찌꺼기 파일들이 함께 들어있습니다. 이 전체를 압축하려고 시도하면 압축에만 수십 분이 걸려 서버 CPU를 잡아먹고, 백업 파일 용량이 100GB를 훌쩍 넘어 스토리지 비용이 폭발하게 됩니다. 우리가 백업해야 할 진짜 '영혼'은 불과 수십 MB 내외의 XML 설정 파일들입니다.

✅ 반드시 백업해야 할 4대 핵심 타겟:

• *.xml (최상위 루트에 있는 젠킨스 글로벌 시스템 설정 파일들)
• jobs/ (개별 파이프라인들의 설정(config.xml) 및 빌드 히스토리)
• plugins/ (설치된 플러그인 바이너리 .jpi 파일 모음)
• secrets/ 및 credentials.xml (가장 중요한 보안 암호화 키와 금고 데이터)

⚙️ 2. ThinBackup 플러그인 (간편한 대안)

직접 쉘 스크립트를 짜는 것이 부담스럽다면 가장 유명한 ThinBackup 플러그인을 추천합니다. 이 녀석을 설치하고 설정에 들어가면, 딱 젠킨스 구동에 필요한 알짜배기 설정 파일들만 쏙쏙 뽑아내어 매일 밤 12시(Cron 스케줄링)에 지정된 서버 경로로 예쁘게 압축해서 뱉어냅니다. 초보자에게는 훌륭한 선택입니다.

💻 3. 상위 1% 실무의 정석: 수동 쉘 스크립트 + AWS S3 전송

하지만 백업 파일을 젠킨스가 떠 있는 똑같은 서버 /tmp 폴더에만 놔두면, 서버 하드가 타버렸을 때 백업본도 같이 타버립니다. 백업의 철칙인 '오프사이트 백업(물리적으로 떨어진 안전한 클라우드에 복사본 저장)'을 달성하려면 결국 커스텀 쉘 스크립트를 작성하여 AWS S3 같은 스토리지로 쏘아 올려야 합니다.

아래는 실무 서버의 크론탭(Crontab)에 등록하여 매일 새벽 3시에 돌리는 완벽한 백업 스크립트 예제입니다.

#!/bin/bash
# 파일명: jenkins_backup_to_s3.sh

JENKINS_HOME="/var/jenkins_home"
BACKUP_TEMP_DIR="/tmp/jenkins_backup_temp"
DATE=$(date +"%Y%m%d_%H%M")
ARCHIVE_NAME="jenkins_backup_${DATE}.tar.gz"

echo "1. 임시 백업 디렉토리 생성 중..."
mkdir -p $BACKUP_TEMP_DIR

echo "2. rsync를 이용해 핵심 파일만 동기화 (workspace, caches, logs 등 찌꺼기는 철저히 배제)"
# --exclude 옵션을 통해 불필요한 공룡 폴더들을 과감히 버립니다.
rsync -avz \
  --exclude 'workspace' \
  --exclude 'caches' \
  --exclude 'logs' \
  --exclude 'tools' \
  $JENKINS_HOME/ $BACKUP_TEMP_DIR/

echo "3. 추출된 알짜배기 설정들을 압축(Tar) 중..."
tar -czvf /tmp/$ARCHIVE_NAME -C $BACKUP_TEMP_DIR .

echo "4. AWS S3 버킷으로 백업 아카이브 전송 시작..."
# AWS CLI가 서버에 설치되어 있고 권한이 설정되어 있어야 합니다.
aws s3 cp /tmp/$ARCHIVE_NAME s3://my-company-jenkins-backup-bucket/

echo "5. 전송 완료! 로컬에 남은 임시 파일과 압축본 청소 중..."
rm -rf $BACKUP_TEMP_DIR
rm -f /tmp/$ARCHIVE_NAME

echo "✅ Jenkins 백업이 성공적으로 S3에 안전하게 보관되었습니다!"

이제 새 서버를 띄운 뒤, S3에서 저 tar.gz 파일을 다운받아 빈 jenkins_home 경로에 압축만 풀어주고 데몬을 재시작하면, 불과 3분 만에 모든 파이프라인과 플러그인, 계정이 완벽하게 복구된 좀비 젠킨스를 만나실 수 있습니다.

🎯 4. 마무리 및 다음 단계

지금까지 용량 폭발을 막기 위해 찌꺼기를 걸러내고 영혼(설정 파일)만 추출하는 압축의 미학부터, 클라우드 스토리지로 쏘아 올려 물리적 재앙까지 대비하는 완벽한 젠킨스 백업 스크립트 작성 기법에 대해 3,000자 분량으로 아주 치밀하게 다루어 보았습니다. 오늘 당장 서버에 접속하여 이 스크립트를 크론탭에 등록해 두십시오. 미래의 당신을 구원할 동아줄이 될 것입니다.

백업 스크립트도 Cron(크론)이라는 스케줄링을 통해 매일 새벽에 자동으로 돌게 만들었습니다. 그렇다면 파이프라인 자체도 누군가 커밋을 하거나 버튼을 누르지 않아도 "매일 자정에 데이터베이스 덤프를 떠라", "매주 월요일 아침 9시에 보안 스캔을 돌려라" 하고 주기적으로 알아서 돌게 만들 순 없을까요? 이어지는 26단계 포스팅에서는 사람의 개입 없이 스스로 일어나는 기계들의 스케줄링 자동화, 'Jenkins 주기적 빌드(Cron Trigger) 마스터 가이드'에 대해 아주 꼼꼼하게 파헤쳐 보겠습니다!