restic 비밀번호를 잃어버리면 어떻게 되나요?

백업은 영원히 사라집니다. restic은 모든 것을 클라이언트 쪽에서 암호화하며 복구 키가 없습니다. 비밀번호는 백업하는 서버에만 두지 말고 비밀번호 관리자에 보관하세요.

저장소는 어디에 둬야 하나요?

그 서버만 빼고 어디든 됩니다. S3 호환 오브젝트 스토리지, SFTP로 연결한 다른 VPS, 집에 있는 컴퓨터 등입니다. 같은 디스크에 있는 백업은 그 디스크와 운명을 같이합니다.

restic으로 데이터베이스는 어떻게 백업하나요?

먼저 덤프를 만들고 그 덤프를 백업하세요. PostgreSQL은 'pg_dump -Fc', MySQL은 'mysqldump --single-transaction'입니다. 실행 중인 데이터베이스 파일을 그대로 복사하면 시작되지 않는 백업이 될 수 있습니다.

백업은 공간을 얼마나 차지하나요?

생각보다 적습니다. restic은 파일을 조각으로 나눠 각 조각을 한 번만 저장하므로, 거의 바뀌지 않는 서버의 일일 스냅샷은 바뀐 데이터만큼만 늘어납니다.

그래도 Managed Backups가 필요한가요?

해결하는 문제가 다릅니다. Managed Backups는 대시보드에서 되돌릴 수 있는 서버 전체의 일일 복원 지점을 줍니다. restic은 직접 관리하는 파일 단위의 외부 사본을 줍니다. 둘 다 쓰는 사람도 많습니다.

restic으로 VPS 백업하는 법 (암호화, 서버 외부 보관)

restic을 이용한 암호화·중복 제거 VPS 백업. S3 호환 스토리지나 다른 서버의 저장소, systemd 타이머, 보존 정책, 복원 테스트까지 다룹니다.

누구나 백업이 있습니다. 실제로 복원해 보기 전까지는요. 폴더는 비어 있고, cron 작업은 3월에 멈춰 있었고, 아카이브는 방금 고장 난 바로 그 디스크에 있었습니다. restic은 이런 문제 대부분을 해결합니다. 내 쪽에서 암호화하고, 데이터 조각을 한 번만 저장하고, 파일 하나 복원을 서버 전체 백업만큼 쉽게 만들어 줍니다.

Ubuntu나 Debian에서 저희가 정말로 믿고 쓸 수 있는 구성을 소개합니다.

1. restic 설치하기

apt update && apt install -y restic
restic self-update

배포판 패키지는 뒤처지는 경우가 많습니다. self-update로 최신 버전을 받으세요.

2. 저장소 위치 정하기

저장소는 보호하려는 서버 위에 있으면 안 됩니다. 흔한 선택지는 두 가지입니다.

SFTP로 연결한 다른 서버: sftp:backup@203.0.113.20:/srv/restic/web1
S3 호환 오브젝트 스토리지: s3:https://s3.example.com/my-bucket/web1

3. 자격 증명 저장하기

타이머와 셸이 같은 설정을 쓰도록 root만 읽을 수 있는 파일 하나에 모두 담으세요.

cat > /root/.restic-env <<'EOF'
export RESTIC_REPOSITORY="s3:https://s3.example.com/my-bucket/web1"
export RESTIC_PASSWORD_FILE="/root/.restic-pass"
export AWS_ACCESS_KEY_ID="your-key-id"
export AWS_SECRET_ACCESS_KEY="your-secret"
EOF
openssl rand -base64 32 > /root/.restic-pass
chmod 600 /root/.restic-env /root/.restic-pass

이제 /root/.restic-pass의 내용을 비밀번호 관리자에 복사하세요. 이게 없으면 백업을 복호화할 수 없습니다. 여러분도, 다른 누구도.

4. 초기화하고 첫 백업 실행하기

source /root/.restic-env
restic init
restic backup /etc /home /root /srv /var/www \
  --exclude-caches --exclude '/root/.cache'
restic snapshots

경로는 데이터가 실제로 있는 곳에 맞게 조정하세요. Docker 볼륨은 /var/lib/docker/volumes에, 앱 데이터는 /srv나 /opt에 있는 경우가 많습니다.

5. 데이터베이스: 먼저 덤프, 그다음 백업

실행 중인 데이터베이스의 원본 파일을 백업하지 마세요. 백업 직전에 덤프를 만드세요.

mkdir -p /var/backups/db
sudo -u postgres pg_dump -Fc mydb > /var/backups/db/mydb.dump

/var/backups/db를 백업 경로에 추가하세요. 덤프에 대해서는 PostgreSQL 가이드에서 더 자세히 다룹니다.

6. systemd로 예약하기

여기서는 cron보다 타이머가 낫습니다. journal에 로그를 남기고, 예정 시각에 서버가 꺼져 있었다면 나중에 실행해 줍니다.

# /etc/systemd/system/restic-backup.service
[Unit]
Description=restic backup

[Service]
Type=oneshot
ExecStart=/bin/bash -c 'source /root/.restic-env && restic backup /etc /home /root /srv /var/www /var/backups/db --exclude-caches && restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune'

# /etc/systemd/system/restic-backup.timer
[Unit]
Description=Daily restic backup

[Timer]
OnCalendar=*-*-* 03:30:00
Persistent=true

[Install]
WantedBy=timers.target

systemctl daemon-reload
systemctl enable --now restic-backup.timer
systemctl list-timers restic-backup.timer

forget --prune은 일간 7개, 주간 4개, 월간 6개의 스냅샷을 남기고 나머지를 지웁니다. 데이터베이스 덤프 단계가 있다면 ExecStartPre= 줄에 넣으세요.

7. 실제로 무언가를 복원해 보기

"백업이 있다"를 사실로 만드는 단계가 바로 이것입니다. 디렉터리 하나를 임시 폴더로 되돌려 보고 내용을 확인하세요.

source /root/.restic-env
restic restore latest --target /tmp/restore-test --include /etc/nginx
ls -la /tmp/restore-test/etc/nginx
restic check

지금 한 번 하고, 그 뒤로 몇 달마다 반복하세요. restic check는 저장소 구조를 검증하고, 복원은 데이터가 정말 있다는 것을 증명합니다.

restic과 Managed Backups

둘은 경쟁 관계가 아닙니다. Managed Backups는 매일 서버 전체의 복원 지점을 만들고, 대시보드에서 되돌릴 수 있습니다. 업그레이드가 꼬였을 때 빠르게 복구하는 방법이죠. 가격은 월 $2이며 모든 연간 요금제에 무료로 포함됩니다. restic은 직접 관리하는 스토리지에 파일 단위의 외부 사본을 남깁니다. 지난주 화요일에 지운 파일이 문제일 때나, 저희 인프라 바깥에 완전히 독립된 사본을 두고 싶을 때 진가를 발휘합니다.

민감한 데이터를 다룬다면 디스크 전체 암호화와 함께 쓰거나, 직접 백업 대상을 운영하는 암호화 스토리지 활용 사례를 참고하세요. 대부분의 작은 서버와 그 백업 작업에는 Micro 요금제로 충분합니다.