중요 파일 백업 자동화 완벽 가이드

restic과 systemd-timer를 활용한 암호화 백업 자동화 시스템을 구축합니다. S3 연동부터 보존 정책 설정까지, 실무에서 바로 적용 가능한 백업 전략을 배웁니다.

---

목차

1. restic_설치와_저장소_초기화
2. 암호화_백업_원리_이해
3. systemd_timer_스케줄링
4. S3_버킷_설정과_연동
5. 백업_보존_정책_설정
6. 백업_검증과_무결성_체크

---

1. restic 설치와 저장소 초기화

어느 날 김개발 씨는 회사 서버에서 중요한 설정 파일을 잘못 수정했습니다. 다행히 백업이 있었지만, 복구하는 데 반나절이 걸렸습니다.

박시니어 씨가 말했습니다. "백업 시스템을 제대로 갖춰놓으면 이런 일을 몇 분 안에 해결할 수 있어요."

restic은 빠르고 안전한 백업 프로그램입니다. 마치 은행 금고처럼 파일을 암호화하여 안전하게 보관합니다.

한 번 설정해두면 자동으로 백업이 진행되어 데이터 손실 걱정을 덜 수 있습니다.

다음 코드를 살펴봅시다.

# restic 설치 (Ubuntu/Debian)
sudo apt update
sudo apt install restic -y

# 로컬 백업 저장소 초기화
export RESTIC_REPOSITORY="/backup/repo"
export RESTIC_PASSWORD="your-secure-password"
restic init

# 첫 백업 실행 - /home/important 디렉토리 백업
restic backup /home/important --tag initial

# 백업 목록 확인
restic snapshots

김개발 씨는 입사 6개월 차 개발자입니다. 최근 회사에서 작은 사고가 있었습니다.

동료 개발자가 실수로 중요한 데이터베이스 설정 파일을 삭제한 것입니다. 다행히 백업이 있었지만, 복구 과정이 너무 복잡했습니다.

팀장님이 회의를 소집했습니다. "앞으로 이런 일이 반복되지 않도록 백업 시스템을 제대로 구축해야 합니다.

김개발 씨, 이번 프로젝트를 맡아주세요." 김개발 씨는 막막했습니다. 백업 도구는 많지만, 어떤 것을 선택해야 할까요?

선배 박시니어 씨가 조언했습니다. "요즘은 restic을 많이 씁니다.

설치도 쉽고, 암호화도 자동으로 해주거든요." restic이란 정확히 무엇일까요? 쉽게 비유하자면, restic은 마치 타임머신과 같습니다.

특정 시점의 파일 상태를 스냅샷으로 저장해두었다가, 필요할 때 언제든 그 시점으로 되돌릴 수 있습니다. 더 중요한 것은 모든 데이터가 암호화되어 저장된다는 점입니다.

설령 백업 파일이 유출되더라도 비밀번호 없이는 열어볼 수 없습니다. 전통적인 백업 방식은 어떤 문제가 있었을까요?

예전에는 tar나 rsync 같은 도구를 사용했습니다. 하지만 이런 도구들은 암호화를 별도로 설정해야 했고, 증분 백업을 관리하기도 까다로웠습니다.

파일이 조금만 변경되어도 전체를 다시 백업하는 경우가 많았습니다. 시간도 오래 걸리고, 저장 공간도 많이 차지했습니다.

박시니어 씨가 설명합니다. "restic의 가장 큰 장점은 중복 제거 기능입니다.

같은 내용의 파일은 한 번만 저장하고, 변경된 부분만 추가로 저장합니다. 그래서 백업 속도도 빠르고 용량도 적게 차지하죠." 김개발 씨가 먼저 restic을 설치했습니다.

Ubuntu 서버에서는 apt 명령어로 간단히 설치할 수 있습니다. 설치가 완료되면 백업을 저장할 저장소를 초기화해야 합니다.

저장소를 초기화할 때 가장 중요한 것은 비밀번호입니다. 이 비밀번호는 모든 백업 데이터를 암호화하는 마스터 키입니다.

만약 이 비밀번호를 잃어버리면 백업 데이터를 영원히 복구할 수 없습니다. 따라서 안전한 곳에 반드시 보관해야 합니다.

환경변수로 RESTIC_REPOSITORY와 RESTIC_PASSWORD를 설정하면, 매번 명령어를 칠 때마다 저장소 경로와 비밀번호를 입력하지 않아도 됩니다. 이렇게 하면 자동화 스크립트를 작성할 때도 편리합니다.

첫 백업을 실행해봅시다. restic backup 명령어에 백업할 디렉토리 경로를 지정하면 됩니다.

--tag 옵션으로 이 백업에 이름표를 달아둘 수 있습니다. 나중에 특정 태그가 달린 백업만 찾아볼 때 유용합니다.

백업이 완료되면 restic snapshots 명령어로 현재까지 생성된 모든 백업 목록을 확인할 수 있습니다. 각 스냅샷에는 고유한 ID가 부여되고, 백업 시간과 태그 정보가 표시됩니다.

김개발 씨는 첫 백업이 성공적으로 완료된 것을 확인하고 안도의 한숨을 쉬었습니다. "생각보다 간단하네요!" 박시니어 씨가 웃으며 말합니다.

"설치는 시작일 뿐이에요. 이제 이걸 자동화하고, 원격 저장소에 백업하는 방법을 배워야죠."

실전 팁

💡 - RESTIC_PASSWORD는 반드시 안전한 비밀번호 관리 도구에 보관하세요

• 첫 백업 후 restic check 명령으로 저장소 무결성을 검증하는 습관을 들이세요

---

2. 암호화 백업 원리 이해

김개발 씨는 궁금해졌습니다. "백업 파일이 암호화된다는데, 정확히 어떻게 작동하는 거죠?" 박시니어 씨가 화이트보드 앞에 섰습니다.

"좋은 질문입니다. 암호화 원리를 이해하면 왜 restic이 안전한지 알 수 있어요."

restic의 암호화는 AES-256 알고리즘을 사용합니다. 마치 은행 금고의 다중 잠금장치처럼 여러 단계의 보안을 제공합니다.

데이터는 저장되기 전에 자동으로 암호화되고, 복원할 때만 복호화됩니다.

다음 코드를 살펴봅시다.

# 암호화 키 확인 (저장소 정보 출력)
restic cat config

# 특정 파일 백업 및 암호화 과정 확인
restic backup /home/important/secret.conf --verbose

# 백업된 데이터 구조 확인
ls -lh /backup/repo/data/
# 파일명이 해시값으로 되어있어 원본을 알 수 없음

# 스냅샷 상세 정보 확인
restic snapshots --json | python3 -m json.tool

백업 시스템에서 가장 중요한 것은 무엇일까요? 바로 보안입니다.

아무리 백업을 잘해두어도, 그 데이터가 유출되면 큰 문제가 됩니다. 특히 고객 정보나 회사 기밀이 담긴 파일이라면 더욱 그렇습니다.

박시니어 씨가 설명을 시작했습니다. "예전에 한 회사에서 백업 서버가 해킹당한 적이 있었어요.

백업 파일이 암호화되지 않아서 모든 데이터가 그대로 유출됐죠. restic을 쓰면 그런 걱정이 없습니다." 암호화란 정확히 무엇일까요?

쉽게 비유하자면, 암호화는 마치 편지를 암호문으로 바꾸는 것과 같습니다. 원본 편지를 특수한 규칙에 따라 뒤섞어서, 열쇠(비밀번호)가 없으면 읽을 수 없게 만듭니다.

restic은 이런 암호화 과정을 자동으로 처리해줍니다. restic이 사용하는 AES-256 알고리즘은 현대 암호화 기술 중 가장 안전한 방식 중 하나입니다.

미국 정부도 기밀 문서를 암호화할 때 이 방식을 사용합니다. 슈퍼컴퓨터로도 수백 년이 걸려야 해독할 수 있을 정도로 강력합니다.

백업 과정을 단계별로 살펴봅시다. 먼저 저장소를 초기화할 때, restic은 무작위로 생성된 마스터 키를 만듭니다.

이 마스터 키는 사용자가 입력한 비밀번호로 한 번 더 암호화되어 저장됩니다. 그래서 비밀번호만 알면 마스터 키를 복원할 수 있고, 마스터 키로 모든 백업 데이터를 복호화할 수 있습니다.

실제 파일을 백업할 때는 어떻게 될까요? 파일은 작은 조각으로 나뉩니다.

각 조각은 청크라고 부릅니다. 각 청크는 개별적으로 암호화되어 저장됩니다.

파일 이름도 암호화되고, 디렉토리 구조도 암호화됩니다. 심지어 파일 크기 정보까지 숨겨집니다.

김개발 씨가 실제로 백업 저장소의 data 폴더를 열어보았습니다. "어?

파일 이름이 전부 이상한 문자열이네요?" 박시니어 씨가 고개를 끄덕입니다. "맞아요.

저건 각 청크의 SHA-256 해시값입니다. 원본 파일 이름을 전혀 알 수 없죠." 이런 방식의 장점은 무엇일까요?

첫째, 백업 서버가 해킹당해도 안전합니다. 공격자가 백업 파일을 가져가도, 비밀번호 없이는 아무것도 볼 수 없습니다.

둘째, 클라우드 저장소를 사용할 때도 안심할 수 있습니다. AWS S3나 Google Cloud Storage에 백업을 올려도, 서비스 제공자조차 내용을 알 수 없습니다.

하지만 주의할 점도 있습니다. 비밀번호를 잃어버리면 정말로 끝입니다.

백업 데이터를 복구할 방법이 전혀 없습니다. 따라서 비밀번호는 반드시 안전한 곳에 보관해야 합니다.

회사에서는 보통 비밀번호 관리 솔루션을 사용하거나, 여러 담당자가 나눠서 보관합니다. 김개발 씨가 restic cat config 명령으로 저장소 설정을 확인했습니다.

JSON 형식으로 출력된 정보에는 암호화 알고리즘, 청킹 방식 등이 명시되어 있습니다. 하지만 마스터 키 자체는 표시되지 않습니다.

보안을 위해 철저히 숨겨져 있는 것입니다. 박시니어 씨가 마무리했습니다.

"암호화는 백업 시스템의 핵심입니다. restic은 이 모든 과정을 투명하게 처리해주니까, 우리는 백업 전략에만 집중하면 됩니다."

실전 팁

💡 - 비밀번호는 최소 20자 이상의 무작위 문자열을 사용하세요

• 정기적으로 restic check 명령으로 암호화 무결성을 검증하세요

---

3. systemd timer 스케줄링

김개발 씨는 매일 수동으로 백업 명령어를 실행하고 있었습니다. 어느 날 깜빡하고 백업을 빼먹었고, 하필 그날 서버에 문제가 생겼습니다.

박시니어 씨가 말했습니다. "사람은 실수하기 마련이에요.

시스템이 자동으로 백업하게 만들어야죠."

systemd-timer는 리눅스의 작업 스케줄러입니다. 마치 알람시계처럼 정해진 시간에 자동으로 프로그램을 실행합니다.

cron보다 강력하고, 로깅과 모니터링도 쉽게 할 수 있습니다.

다음 코드를 살펴봅시다.

# /etc/systemd/system/restic-backup.service 생성
[Unit]
Description=Restic backup service
After=network-online.target

[Service]
Type=oneshot
Environment="RESTIC_REPOSITORY=/backup/repo"
Environment="RESTIC_PASSWORD_FILE=/root/.restic-password"
ExecStart=/usr/bin/restic backup /home/important --tag automated
# 백업 실패시 관리자에게 알림
ExecStartPost=/usr/bin/bash -c 'if [ $? -ne 0 ]; then echo "Backup failed" | mail -s "Restic Alert" admin@example.com; fi'

# /etc/systemd/system/restic-backup.timer 생성
[Unit]
Description=Restic backup timer

[Timer]
# 매일 새벽 2시에 실행
OnCalendar=daily
OnCalendar=02:00
Persistent=true

[Install]
WantedBy=timers.target

수동 백업의 가장 큰 문제는 무엇일까요? 바로 사람의 실수입니다.

아무리 성실한 개발자라도 가끔은 깜빡할 수 있습니다. 바쁜 날이면 백업을 건너뛰기도 합니다.

그리고 그런 날에 한정해서 문제가 생깁니다. 김개발 씨는 지난주 경험을 떠올렸습니다.

금요일 저녁, 급한 배포 건으로 정신이 없었습니다. 백업을 실행하지 않고 퇴근했고, 주말에 서버 디스크에 문제가 생겼습니다.

월요일 출근해서 알았을 때는 이미 늦었습니다. 팀장님이 말했습니다.

"앞으로는 백업을 자동화하세요. 시스템이 알아서 하도록 만들어야 합니다." 박시니어 씨가 systemd-timer를 소개했습니다.

systemd-timer란 무엇일까요? 쉽게 비유하자면, systemd-timer는 마치 자동 출퇴근 기록기와 같습니다.

정해진 시간이 되면 자동으로 작업을 실행하고, 실행 결과를 기록합니다. 예전에 많이 쓰던 cron과 비슷하지만, 훨씬 더 많은 기능을 제공합니다.

cron의 문제점은 무엇이었을까요? cron은 단순합니다.

정해진 시간에 명령어를 실행하는 것이 전부입니다. 만약 그 시간에 서버가 꺼져 있었다면?

작업은 실행되지 않고 그냥 넘어갑니다. 실행 결과를 확인하기도 어렵습니다.

로그를 직접 파일로 리다이렉션해야 합니다. systemd-timer는 이런 문제를 모두 해결합니다.

서버가 꺼져 있었다면 Persistent 옵션으로 부팅 후 즉시 실행할 수 있습니다. 실행 결과는 자동으로 journalctl에 기록됩니다.

작업 간 의존성도 설정할 수 있습니다. 네트워크가 준비된 후에 실행하도록 지정할 수 있습니다.

백업 자동화를 위해서는 두 개의 파일이 필요합니다. 첫째는 service 파일입니다.

이 파일은 실제로 실행할 명령어를 정의합니다. restic backup 명령어와 필요한 환경변수를 설정합니다.

Type=oneshot은 이 작업이 한 번 실행되고 종료됨을 의미합니다. 백업은 계속 실행되는 서비스가 아니라 일회성 작업이기 때문입니다.

둘째는 timer 파일입니다. 이 파일은 언제 service를 실행할지 정의합니다.

OnCalendar 옵션으로 실행 시간을 지정합니다. 매일 새벽 2시에 실행하려면 "OnCalendar=02:00"으로 설정합니다.

주말을 제외하고 평일만 실행하려면 "Mon..Fri --* 02:00:00"처럼 상세하게 지정할 수 있습니다. 김개발 씨가 두 파일을 작성하고 systemd에 등록했습니다.

systemctl daemon-reload로 설정을 새로고침하고, systemctl enable restic-backup.timer로 타이머를 활성화합니다. 이제 서버가 재부팅되어도 타이머는 자동으로 시작됩니다.

실행 상태는 어떻게 확인할까요? systemctl status restic-backup.timer 명령으로 타이머가 활성화되었는지 확인합니다.

systemctl list-timers 명령으로 다음 실행 예정 시간을 볼 수 있습니다. 실제 백업이 실행된 후에는 journalctl -u restic-backup.service로 상세한 로그를 확인할 수 있습니다.

박시니어 씨가 추가 팁을 알려줍니다. "ExecStartPost를 활용하면 백업 실패 시 이메일 알림을 보낼 수 있어요.

또는 Slack 웹훅으로 메시지를 보낼 수도 있죠." 김개발 씨는 처음으로 완전 자동화된 백업 시스템을 구축했습니다. 이제 매일 새벽 2시, 서버는 혼자서 조용히 백업을 실행합니다.

김개발 씨는 편안하게 잠들 수 있게 되었습니다.

실전 팁

💡 - Persistent=true 옵션으로 서버 다운타임 동안 놓친 백업도 부팅 후 실행되게 하세요

• RandomizedDelaySec 옵션으로 여러 서버의 백업 시간을 분산시킬 수 있습니다

---

4. S3 버킷 설정과 연동

김개발 씨의 백업 시스템이 잘 작동하고 있었습니다. 그런데 어느 날 서버실에 화재가 발생했습니다.

다행히 큰 피해는 없었지만, 팀장님이 말했습니다. "로컬 백업만으로는 부족해요.

원격지에도 백업을 보관해야 합니다."

AWS S3는 클라우드 저장소 서비스입니다. 마치 인터넷 상의 무한 창고처럼 어디서든 접근할 수 있습니다.

restic은 S3와 완벽하게 연동되어, 암호화된 백업을 안전하게 원격 보관할 수 있습니다.

다음 코드를 살펴봅시다.

# AWS CLI 설치 및 설정
sudo apt install awscli -y
aws configure
# Access Key ID, Secret Key, Region 입력

# S3 버킷 생성
aws s3 mb s3://mycompany-backups --region ap-northeast-2

# S3용 restic 저장소 초기화
export AWS_ACCESS_KEY_ID="your-access-key"
export AWS_SECRET_ACCESS_KEY="your-secret-key"
export RESTIC_REPOSITORY="s3:s3.ap-northeast-2.amazonaws.com/mycompany-backups"
export RESTIC_PASSWORD="your-secure-password"
restic init

# S3로 백업 실행
restic backup /home/important --tag s3-backup

# S3 백업 목록 확인
restic snapshots

로컬 백업의 치명적인 약점은 무엇일까요? 바로 물리적 위험입니다.

화재, 침수, 도난, 하드웨어 고장 등 서버실에 문제가 생기면 백업도 함께 사라질 수 있습니다. 박시니어 씨가 실제 경험담을 들려주었습니다.

"예전 직장에서 서버실 에어컨이 고장 났어요. 한여름 밤에 온도가 급상승하면서 서버 여러 대가 동시에 다운됐죠.

백업 서버도 같은 서버실에 있어서 함께 망가졌어요." 이런 상황을 단일 장애점이라고 합니다. 한 곳에 문제가 생기면 모든 것이 멈춰버리는 구조입니다.

이를 해결하는 방법은 지리적 분산입니다. 백업을 멀리 떨어진 다른 장소에도 보관하는 것입니다.

클라우드 스토리지가 바로 이 문제의 해결책입니다. AWS S3는 전 세계 여러 데이터센터에 데이터를 분산 저장합니다.

한 곳에 문제가 생겨도 다른 곳에서 데이터를 가져올 수 있습니다. 게다가 내구성이 99.999999999%입니다.

1000억 개의 파일을 저장해도 1년에 1개만 손실될 확률입니다. 김개발 씨가 AWS 콘솔에 로그인했습니다.

S3 서비스로 이동해서 새 버킷을 만들려고 하는데, 설정 옵션이 너무 많았습니다. "어떻게 설정해야 하죠?" 박시니어 씨가 안내합니다.

"백업용 버킷은 보안이 최우선이에요. 퍼블릭 액세스는 완전히 차단하고, 버전 관리를 활성화하세요." 버킷 이름은 전 세계적으로 고유해야 합니다.

회사 이름과 용도를 조합해서 짓는 것이 좋습니다. 리전은 가능한 한 가까운 곳을 선택합니다.

한국 서버라면 서울 리전인 ap-northeast-2가 적합합니다. 버전 관리 기능을 활성화하면 어떤 이점이 있을까요?

실수로 백업 파일을 덮어쓰거나 삭제해도, 이전 버전을 복구할 수 있습니다. restic 자체도 스냅샷을 관리하지만, S3 레벨에서 한 번 더 보호막을 치는 셈입니다.

이중 안전장치인 것입니다. restic을 S3와 연동하는 방법은 간단합니다.

RESTIC_REPOSITORY 환경변수에 S3 URL을 지정하면 됩니다. URL 형식은 "s3:리전주소/버킷이름"입니다.

AWS 인증 정보는 AWS_ACCESS_KEY_ID와 AWS_SECRET_ACCESS_KEY로 제공합니다. 보안을 위해 IAM 사용자를 별도로 만드는 것이 좋습니다.

이 사용자에게는 해당 버킷에 대한 읽기/쓰기 권한만 부여합니다. 만약 인증 키가 유출되어도 피해를 최소화할 수 있습니다.

김개발 씨가 처음으로 S3 백업을 실행했습니다. 로컬 백업보다 시간이 조금 더 걸렸습니다.

인터넷을 통해 데이터를 전송하기 때문입니다. 하지만 초기 백업 이후에는 변경된 부분만 전송되므로 빠릅니다.

AWS 콘솔에서 S3 버킷을 확인하니, data 폴더 아래에 암호화된 청크 파일들이 생성되어 있었습니다. 파일명은 모두 해시값이라 원본을 알 수 없습니다.

혹시 AWS 직원이 이 파일을 본다 해도, 내용은 완전히 암호화되어 있어 안전합니다. 박시니어 씨가 비용 최적화 팁을 알려줍니다.

"S3에는 여러 스토리지 클래스가 있어요. 자주 접근하지 않는 백업은 Glacier로 이동시키면 비용을 80% 이상 절감할 수 있습니다." 김개발 씨는 이제 진정한 의미의 안전한 백업 시스템을 갖추게 되었습니다.

로컬과 클라우드, 두 곳에 백업이 보관되니 안심입니다.

실전 팁

💡 - S3 버킷에는 반드시 라이프사이클 정책을 설정하여 오래된 백업을 자동으로 Glacier로 이동시키세요

• MFA 삭제 보호를 활성화하면 실수로 버킷을 삭제하는 것을 방지할 수 있습니다

---

5. 백업 보존 정책 설정

백업이 계속 쌓이면서 김개발 씨는 새로운 고민에 빠졌습니다. S3 비용이 점점 늘어나고 있었습니다.

박시니어 씨가 물었습니다. "10년 전 백업을 지금도 보관할 필요가 있을까요?

보존 정책이 필요한 시점이네요."

백업 보존 정책은 어떤 백업을 얼마나 오래 보관할지 정하는 규칙입니다. 마치 서랍 정리처럼 중요한 것은 오래 보관하고, 불필요한 것은 삭제합니다.

restic의 forget과 prune 명령으로 자동화할 수 있습니다.

다음 코드를 살펴봅시다.

# 보존 정책 설정
# 최근 7일: 매일 백업 보관
# 최근 4주: 매주 백업 보관
# 최근 12개월: 매월 백업 보관
# 최근 3년: 매년 백업 보관
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --keep-yearly 3 --prune

# 특정 태그의 백업만 정리
restic forget --keep-last 10 --tag automated --prune

# 정책 적용 전 시뮬레이션 (실제 삭제 안함)
restic forget --keep-daily 7 --keep-weekly 4 --dry-run

# 사용하지 않는 데이터 블록 완전 제거
restic prune

# 저장 공간 확인
restic stats

백업을 무한정 보관하면 어떤 일이 벌어질까요? 저장 공간은 계속 증가하고, 비용도 함께 늘어납니다.

더 큰 문제는 정작 필요한 백업을 찾기 어려워진다는 것입니다. 수천 개의 스냅샷 중에서 원하는 시점을 찾는 것은 건초더미에서 바늘 찾기와 같습니다.

김개발 씨의 회사는 매일 자동 백업을 실행하고 있었습니다. 1년이 지나니 365개의 스냅샷이 쌓였습니다.

S3 비용 청구서를 보니 예상보다 훨씬 많이 나왔습니다. 팀장님이 비용 절감을 요청했습니다.

박시니어 씨가 화이트보드에 그림을 그렸습니다. "백업은 시간이 지날수록 가치가 떨어집니다.

어제 파일이 필요할 확률은 높지만, 1년 전 파일이 필요할 확률은 낮죠." 백업 보존 정책이란 정확히 무엇일까요? 쉽게 비유하자면, 백업 보존 정책은 마치 사진 정리와 같습니다.

최근 사진은 하루 단위로 보관하지만, 1년 전 사진은 한 달에 한 장만 남기고 삭제합니다. 10년 전 사진은 1년에 한 장만 남깁니다.

이렇게 하면 공간도 절약되고, 중요한 순간은 여전히 보관할 수 있습니다. 실무에서 흔히 사용하는 3-2-1 규칙이 있습니다.

최근 백업일수록 촘촘하게 보관합니다. 일주일 이내는 매일 백업을 모두 보관합니다.

실수로 파일을 삭제했을 때 빠르게 복구할 수 있습니다. 한 달 이내는 매주 백업을 보관합니다.

1년 이내는 매월 백업을 보관합니다. restic의 forget 명령어가 이런 정책을 자동으로 적용해줍니다.

--keep-daily 7은 최근 7일간의 일별 백업을 보관하라는 의미입니다. --keep-weekly 4는 최근 4주간의 주별 백업을 보관합니다.

--keep-monthly 12는 최근 12개월간의 월별 백업을 보관합니다. --keep-yearly 3은 최근 3년간의 연별 백업을 보관합니다.

김개발 씨가 궁금해했습니다. "그럼 정확히 어떤 백업이 삭제되나요?" 박시니어 씨가 설명합니다.

"restic은 각 기간마다 가장 최근 백업을 하나씩 선택합니다. 예를 들어 이번 주 백업이 5개 있다면, 가장 최근 것만 남기고 나머지는 삭제 대상이 됩니다." --dry-run 옵션을 활용하면 실제로 삭제하지 않고 시뮬레이션만 할 수 있습니다.

어떤 스냅샷이 삭제될지 미리 확인할 수 있어서 안전합니다. 정책이 의도대로 작동하는지 검증한 후에 실제 삭제를 진행하는 것이 좋습니다.

forget 명령은 스냅샷 메타데이터만 삭제합니다. 실제 데이터 블록은 여전히 저장소에 남아 있습니다.

왜냐하면 다른 스냅샷이 같은 블록을 공유하고 있을 수 있기 때문입니다. 완전히 제거하려면 prune 명령을 실행해야 합니다.

prune은 어떤 스냅샷에도 속하지 않는 고아 블록을 찾아서 삭제합니다. 이 과정은 시간이 오래 걸릴 수 있습니다.

전체 저장소를 스캔해야 하기 때문입니다. 따라서 사용량이 적은 시간대에 실행하는 것이 좋습니다.

김개발 씨가 보존 정책을 적용했습니다. 365개의 스냅샷이 48개로 줄어들었습니다.

S3 사용량도 크게 감소했습니다. 하지만 필요한 시점의 백업은 여전히 모두 보관되어 있었습니다.

박시니어 씨가 자동화 팁을 알려줍니다. "systemd 서비스 파일에 forget과 prune을 추가하세요.

백업할 때마다 자동으로 정리되게 만들 수 있어요." 회사의 규정에 따라 보존 정책을 조정할 수도 있습니다. 금융 회사처럼 장기 보관이 필요한 경우 --keep-yearly를 10이나 20으로 늘릴 수 있습니다.

반대로 빠르게 변화하는 개발 환경이라면 최근 백업만 집중적으로 보관할 수 있습니다.

실전 팁

💡 - 보존 정책을 변경하기 전에 반드시 --dry-run으로 시뮬레이션 해보세요

• 중요한 백업에는 --keep-tag 옵션으로 특정 태그를 영구 보존할 수 있습니다

---

6. 백업 검증과 무결성 체크

3개월간 백업 시스템이 잘 작동하고 있었습니다. 김개발 씨는 안심하고 있었죠.

그런데 박시니어 씨가 물었습니다. "백업이 제대로 되고 있는지 확인해봤어요?" 김개발 씨는 당황했습니다.

"매일 실행되고 있는데요?" "실행되는 것과 제대로 복구되는 것은 다른 문제입니다."

백업 검증은 저장된 백업이 실제로 복구 가능한지 확인하는 과정입니다. 마치 소화기의 정기 점검처럼, 정작 필요할 때 작동하지 않으면 의미가 없습니다.

restic의 check와 restore로 정기적으로 검증해야 합니다.

다음 코드를 살펴봅시다.

# 백업 저장소 무결성 검사
restic check

# 상세 검사 (모든 데이터 블록 검증)
restic check --read-data

# 특정 스냅샷 복원 테스트
restic snapshots
# 복원할 스냅샷 ID 확인
restic restore abc123def --target /tmp/restore-test

# 복원된 파일 비교
diff -r /home/important /tmp/restore-test/home/important

# 백업 통계 확인
restic stats --mode restore-size

# 자동화된 검증 스크립트
#!/bin/bash
restic check || echo "Check failed" | mail -s "Backup Alert" admin@example.com
restic restore latest --target /tmp/test && rm -rf /tmp/test || echo "Restore failed" | mail -s "Restore Alert" admin@example.com

백업 시스템의 가장 무서운 함정은 무엇일까요? 바로 거짓 안도감입니다.

매일 백업이 실행되고 있으니 안전하다고 믿습니다. 그런데 막상 복구가 필요한 순간, 백업이 손상되어 있다는 사실을 알게 됩니다.

이미 늦었습니다. 박시니어 씨가 실제 사례를 들려주었습니다.

"예전 회사에서 2년간 백업을 돌렸어요. 모니터링도 녹색 불이었죠.

그런데 실제로 서버가 고장 나서 복구하려는데, 백업 파일이 전부 손상되어 있었어요. 하드웨어 오류가 조용히 진행되고 있었던 겁니다." 이런 상황을 사일런트 데이터 손상이라고 합니다.

겉으로는 정상이지만, 내부적으로 조금씩 망가져가는 것입니다. 몇 달 후에 발견했을 때는 모든 백업이 쓸모없어져 있습니다.

백업 검증이 왜 중요한지 이제 알 수 있습니다. 백업 검증은 마치 정기 건강검진과 같습니다.

겉으로 아무 문제가 없어 보여도, 속을 들여다보면 문제를 조기에 발견할 수 있습니다. restic은 이런 검증 기능을 기본으로 제공합니다.

restic check 명령어는 저장소의 구조적 무결성을 검사합니다. 메타데이터가 올바른지, 스냅샷 정보가 정확한지, 인덱스 파일이 손상되지 않았는지 확인합니다.

이 검사는 비교적 빠르게 완료됩니다. 실제 데이터 블록까지 읽지는 않기 때문입니다.

더 철저한 검사가 필요하다면 --read-data 옵션을 사용합니다. 이 옵션은 저장소의 모든 데이터 블록을 실제로 읽어서 체크섬을 검증합니다.

손상된 블록을 정확히 찾아낼 수 있습니다. 대신 시간이 오래 걸립니다.

수 테라바이트의 백업이라면 몇 시간씩 걸릴 수 있습니다. 김개발 씨가 처음으로 전체 검증을 실행했습니다.

다행히 모든 검사를 통과했습니다. "이제 안심해도 되는 거죠?" 박시니어 씨가 고개를 저었습니다.

"검증만으로는 부족합니다. 실제로 복원 테스트를 해봐야 해요." 복원 테스트가 왜 필요할까요?

파일이 온전하게 저장되어 있어도, 복원 과정에서 문제가 생길 수 있습니다. 권한 설정, 심볼릭 링크, 특수 파일 등 복잡한 파일시스템 요소들이 제대로 복원되는지 확인해야 합니다.

실제 재해 상황에서 처음 시도했다가 실패하면 끝입니다. restic restore 명령으로 특정 스냅샷을 복원할 수 있습니다.

--target 옵션으로 복원 위치를 지정합니다. 원본 위치에 바로 복원하면 기존 파일을 덮어쓸 수 있으니, 별도의 테스트 디렉토리를 사용하는 것이 안전합니다.

복원 후 diff 명령으로 원본과 비교하면 정확성을 검증할 수 있습니다. 김개발 씨가 월별로 자동 검증 스크립트를 만들었습니다.

매월 첫째 주 일요일에 전체 검사를 실행하고, 무작위로 하나의 스냅샷을 복원해서 검증합니다. 문제가 발견되면 즉시 관리자에게 이메일을 보냅니다.

박시니어 씨가 추가 조언을 합니다. "복원 테스트는 다른 서버에서 하는 것도 좋아요.

실제 재해 시에는 원래 서버를 사용할 수 없을 수도 있으니까요." 재해 복구 훈련도 정기적으로 실시해야 합니다. 단순히 파일 몇 개를 복원하는 것이 아니라, 전체 시스템을 복원하는 절차를 연습합니다.

데이터베이스 덤프 복원, 설정 파일 복원, 서비스 재시작까지 전 과정을 시뮬레이션합니다. 이런 훈련을 통해 복구 시간을 크게 단축할 수 있습니다.

김개발 씨는 이제 진정한 의미의 안전한 백업 시스템을 완성했습니다. 백업을 만드는 것만이 아니라, 그 백업이 실제로 작동하는지 지속적으로 검증합니다.

밤에도 편히 잠들 수 있게 되었습니다. 박시니어 씨가 마지막으로 말합니다.

"백업은 보험과 같습니다. 평소에는 쓸모없어 보이지만, 정작 필요할 때 생명줄이 됩니다.

제대로 관리하세요."

실전 팁

💡 - 최소한 월 1회 이상 restic check --read-data로 전체 검증을 수행하세요

• 복원 테스트는 원래 서버가 아닌 별도의 테스트 환경에서 진행하는 것이 안전합니다

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!