내 블로그 서버 원격 백업: 치뉴클라우드 저빈도 스토리지 + Restic

블로그를 구축하고 나면 페이지가 열리고, 관리자 페이지에 로그인되며, 글이 정상적으로 발행되면 모든 게 끝났다는 착각에 빠지기 쉽습니다.

하지만 나중에 생각해보니, 사실 그렇지 않더군요.

블로그 자체를 다시 구축하는 것은 어렵지 않습니다. 어려운 것은 시간이 지나면서 쌓인 것들, 예를 들어 글, 데이터베이스, 이미지, 설정 파일, 리버스 프록시, Docker Compose, 환경 변수, 크론 작업 같은 것들입니다. 서버의 하드디스크가 어느 날 고장 나거나, 제가 실수로 디렉터리를 잘못 삭제하거나, 시스템 업그레이드 중 문제가 생기면 이런 것들을 다시 배포하는 것만으로는 되살리기 어렵습니다.

그래서 결국 블로그 서버에 원격 백업을 하기로 결정했습니다.

저는 치뉴클라우드의 저빈도 스토리지를 선택했고, 백업 도구로는 Restic을 사용하며, 주기는 일주일에 한 번입니다. 아주 고급스러운 방법은 아니지만 개인 블로그에는 충분합니다.

이 글은 주로 제 작업 과정을 기록한 것입니다. 나중에 서버에 실제로 문제가 생기면, 이 글을 보고 복구할 수 있을 것입니다.

왜 원격 백업을 해야 하는가

많은 사람들이 백업이라고 하면 가장 먼저 서버 로컬에 복사본을 만드는 것을 떠올립니다.

예를 들어:

cp -r /www /backup/www

이런 것도 물론 백업이지만, 문제는 같은 기기에 있다는 점입니다.

단순히 파일 하나를 잘못 삭제한 경우라면 로컬 백업이 유용합니다. 하지만 하드디스크가 고장 나거나, 서버 시스템이 다운되거나, 기기 자체에 접근할 수 없게 되면 로컬 백업도 함께 사라집니다.

그래서 제 생각에 안정적인 방법은 다음과 같아야 합니다:

• 서버 로컬에서 블로그를 운영하고
• 백업은 다른 곳에 저장하며
• 평소에는 신경 쓰지 않다가
• 실제 문제가 생겼을 때 가져와서 복구할 수 있다

이것이 제가 이번에 객체 스토리지를 선택한 이유입니다.

왜 치뉴클라우드 저빈도 스토리지를 선택했는가

치뉴클라우드 객체 스토리지에는 표준 스토리지, 저빈도 스토리지, 아카이브 스토리지 등 다양한 유형이 있습니다.

블로그 백업 같은 데이터는 평소에는 거의 다운로드하지 않고, 실제 문제가 생겼을 때만 꺼내서 복구하는 특징이 있습니다.

따라서 표준 스토리지는 다소 낭비이고, 아카이브 스토리지는 너무 번거롭습니다. 저빈도 스토리지는 그 중간에 위치하여 '자주 접근하지는 않지만, 필요할 때 가져올 수 있는' 데이터에 적합합니다.

물론 저빈도 스토리지에도 단점은 있습니다.

일반적으로 최소 보관 기간이 있습니다. 저빈도 스토리지는 보통 30일의 최소 보관 기간이 있어서, 업로드 후 빠르게 삭제하더라도 최소 보관 기간에 따라 요금이 부과될 수 있습니다.

또 한 가지는 저빈도 스토리지에서 복구를 위해 다운로드할 때 검색 비용이 발생한다는 점입니다. 즉, 평소에 보관해 두는 것은 비교적 저렴하지만, 실제로 다운로드하여 복구할 때 추가 비용이 발생합니다.

그래서 제 전략은 간단합니다:

• 일주일에 한 번 백업한다.
• 매일 삭제하지 않는다.
• 백업을 하나만 유지하지 않는다.
• 최근 몇 달간의 백업만 유지하면 충분하다.

결국 최근 12개의 주간 백업, 즉 약 3개월치를 유지하도록 설정했습니다.

왜 압축 파일을 직접 업로드하지 않는가

처음에는 가장 간단한 방법을 생각했습니다: 매주 압축 파일을 만들어 치뉴클라우드에 업로드하는 것입니다.

예를 들어:

tar -czf blog-backup.tar.gz /www /etc/nginx

이 방법은 확실히 간단하지만, 나중에 몇 가지 문제가 있을 것 같았습니다.

첫째, 매번 전체 백업입니다. 웹사이트 디렉터리가 30GB라면 매주 30GB를 다시 압축하고 업로드해야 합니다. 일주일 동안 글 하나만 수정했더라도 다시 전체를 업로드해야 합니다.

둘째, 버전 관리가 어렵습니다. 시간이 지나면 압축 파일이 많아집니다. 어떤 것이 정상이고, 어떤 것이 데이터베이스를 포함하며, 어떤 것으로 복구했는지 스스로 잊어버리기 쉽습니다.

셋째, 암호화를 직접 처리해야 합니다. 블로그에는 데이터베이스, 설정 파일, 키, 환경 변수가 있을 수 있습니다. 일반 압축 파일을 객체 스토리지에 바로 두는 것은 불안했습니다.

넷째, 복구 경험이 좋지 않습니다. 실제로 복구해야 할 때 압축 파일을 다운로드하고, 압축을 풀고, 경로를 확인하고, 수동으로 덮어써야 합니다.

나중에 알아보니 치뉴 Kodo가 S3 호환 인터페이스를 지원하고, Restic이 S3에 직접 백업할 수 있어서 결국 Restic을 선택했습니다.

Restic이란 무엇인가

Restic은 백업 도구입니다. 단순히 파일을 압축하여 업로드하는 것이 아니라 백업을 저장소(repository) 형태로 만듭니다.

몇 가지 장점이 있습니다:

• 증분 백업 지원
• 중복 제거 지원
• 기본 암호화
• 과거 스냅샷 확인 가능
• 특정 시점으로 복구 가능
• S3 호환 객체 스토리지와 연동 가능

간단히 말해, 첫 번째 백업은 많은 양을 업로드하지만, 이후에는 변경된 부분만 업로드합니다.

예를 들어 이번 주에 몇 편의 글만 수정했다면, Restic은 블로그 전체를 다시 업로드하지 않습니다. 변경 사항을 인식하고 필요한 내용만 업로드합니다.

이는 주간 백업에 매우 적합합니다.

먼저 무엇을 백업할지 확인하기

백업 전에 가장 중요한 단계는 명령어를 작성하는 것이 아니라, 무엇을 백업할지 먼저 명확히 하는 것입니다.

많은 사람들이 처음부터 서버 루트 디렉터리 전체를 백업하려고 합니다:

/

이것이 가장 안정적으로 보이지만, 사실은 그렇지 않습니다.

시스템 전체에는 백업할 필요가 없는 것들이 많습니다. 예를 들어 캐시, 로그, 임시 파일, Docker 이미지 레이어 등입니다. 이런 것들은 용량이 크고 복구 시에도 유용하지 않을 수 있습니다.

제가 실제로 신경 쓰는 것은 다음과 같습니다:

/www
/var/www
/opt
/etc/nginx
/etc/systemd/system

사람마다 서버 경로가 다르므로 자신의 서버 경로에 맞게 조정해야 합니다.

1Panel로 블로그를 배포했다면 다음을 중점적으로 봐야 합니다:

/opt/1panel
/opt/1panel/apps
/www

Docker Compose로 블로그를 배포했다면 다음을 중점적으로 백업해야 합니다:

• docker-compose.yml
• .env
• 마운트된 데이터 디렉터리
• 데이터베이스 덤프 파일

블로그에 데이터베이스가 있다면 반드시 별도로 덤프를 떠야 합니다. 웹사이트 파일만 백업하고 데이터베이스를 백업하지 않으면, 복구 후 프로그램만 있고 글 데이터는 없을 가능성이 높습니다.

백업하지 않는 것이 좋은 항목

다음 디렉터리는 일반적으로 백업에 포함하지 않는 것이 좋습니다:

/var/log
/tmp
/var/tmp
/var/lib/docker/overlay2
node_modules
.cache
logs

이유는 간단합니다.

로그는 계속 증가하며, 블로그 복구 시 일반적으로 필요하지 않습니다. 임시 디렉터리는 백업할 필요가 없습니다. node_modules는 다시 설치할 수 있습니다. Docker의 overlay2는 용량이 크고 직접 복사하여 복구하기에 적합하지 않습니다. 캐시 디렉터리를 백업하면 공간만 낭비합니다.

백업은 많은 것보다 꼭 필요한 것을 선별해서 하는 게 중요합니다. 백업해야 할 것은 반드시 백업하고, 백업하지 말아야 할 것은 넣지 말아야 합니다.

Restic 설치

제 서버는 Ubuntu이므로 apt로 설치합니다:

sudo apt update
sudo apt install -y restic

설치 후 버전을 확인합니다:

restic version

버전 번호가 보이면 설치가 완료된 것입니다.

치뉴클라우드 정보 준비

다음으로 치뉴클라우드의 몇 가지 정보를 준비해야 합니다:

• Access Key
• Secret Key
• Bucket 이름
• Region ID

Access Key와 Secret Key는 치뉴클라우드 관리자 페이지에서 확인할 수 있습니다.

Bucket 이름은 생성한 객체 스토리지 공간의 이름입니다.

Region ID는 공간이 위치한 지역에 따라 다릅니다. 예를 들어 화동, 화남, 화북, 싱가포르 등 지역에 따라 Region ID가 다릅니다.

Restic이 치뉴 Kodo의 S3 주소에 연결하는 형식은 대략 다음과 같습니다:

s3:s3.<Region-ID>.qiniucs.com/<bucket_name>

예를 들어 Region ID가 다음과 같다면:

cn-east-1

Bucket 이름이 다음과 같다면:

my-blog-backup

저장소 주소는 다음과 같이 쓸 수 있습니다:

s3:s3.cn-east-1.qiniucs.com/my-blog-backup/blog-server

마지막 blog-server는 제가 직접 추가한 경로로, 이 버킷 내의 다른 백업 내용을 구분하기 위한 것입니다.

나중에 NAS, 사진, 다른 서버 등을 백업하고 싶다면 같은 버킷 내에서 디렉터리를 나누어 사용할 수 있습니다.

Restic 설정 파일 생성

매번 명령어에 AK, SK, 저장소 주소, 비밀번호를 수동으로 입력하고 싶지 않아서, 이 정보들을 별도의 설정 파일에 넣었습니다.

먼저 디렉터리를 생성합니다:

sudo mkdir -p /etc/restic

그런 다음 설정 파일을 생성합니다:

sudo nano /etc/restic/blog.env

다음 내용을 작성합니다:

여기서 자신의 정보로 변경해야 합니다:

• 당신의치뉴AccessKey
• 당신의치뉴SecretKey
• cn-east-1
• 당신의bucket이름
• 직접설정한긴백업비밀번호

RESTIC_PASSWORD는 반드시 잘 보관해야 합니다.

이 비밀번호는 치뉴클라우드 비밀번호가 아니라, Restic이 백업 저장소를 암호화하는 데 사용하는 비밀번호입니다. 나중에 백업을 복구할 때도 이 비밀번호가 필요합니다.

이 비밀번호를 잃어버리면, 치뉴클라우드의 파일이 남아있어도 복구할 수 없습니다.

저장 후 설정 파일의 권한을 제한합니다:

sudo chmod 600 /etc/restic/blog.env

이렇게 하면 일반 사용자가 안에 있는 키를 쉽게 읽을 수 없습니다.

백업 저장소 초기화

처음 Restic을 사용할 때는 저장소를 초기화해야 합니다.

실행:

sudo bash -c 'source /etc/restic/blog.env && restic -r "$RESTIC_REPOSITORY" -o s3.region="$QINIU_REGION" init'

성공하면 다음과 같은 메시지가 표시됩니다:

created restic repository ...

여기서 오류가 발생하면 계속 진행하지 마세요. 일반적으로 다음 항목을 확인해야 합니다:

• Access Key가 잘못되지 않았는지
• Secret Key가 잘못되지 않았는지
• Bucket 이름이 잘못되지 않았는지
• Region ID가 잘못되지 않았는지
• 서버가 치뉴의 S3 인터페이스에 접근할 수 있는지

이 단계가 성공하면 계속 진행합니다.

작은 디렉터리로 먼저 테스트, 실제 데이터는 바로 백업하지 않기

먼저 블로그 전체를 백업하기보다는 작은 디렉터리로 테스트하여 업로드와 복구가 모두 문제없는지 확인하는 것이 좋습니다.

테스트 디렉터리 생성:

mkdir -p /tmp/qiniu-test
echo "hello backup" > /tmp/qiniu-test/test.txt

이 작은 디렉터리를 백업합니다:

sudo bash -c 'source /etc/restic/blog.env && restic -r "$RESTIC_REPOSITORY" -o s3.region="$QINIU_REGION" backup /tmp/qiniu-test'

스냅샷 확인:

sudo bash -c 'source /etc/restic/blog.env && restic -r "$RESTIC_REPOSITORY" -o s3.region="$QINIU_REGION" snapshots'

방금 생성된 스냅샷이 보이면 백업이 업로드된 것입니다.

이어서 복구 테스트:

복구된 파일 확인:

cat /tmp/qiniu-restore/tmp/qiniu-test/test.txt

다음이 보이면:

hello backup

백업과 복구 모두 문제가 없는 것입니다.

이 단계가 다소 번거로워 보일 수 있지만, 매우 중요하다고 생각합니다. 백업 도구는 업로드만 되는 것이 아니라 반드시 복구도 가능해야 하기 때문입니다.

실제 백업 스크립트 작성

테스트가 문제없으면 실제 백업 스크립트를 작성합니다.

스크립트 생성:

sudo nano /usr/local/bin/backup-blog-to-qiniu.sh

다음 내용을 작성합니다:

저장 후 스크립트에 실행 권한을 부여합니다:

sudo chmod +x /usr/local/bin/backup-blog-to-qiniu.sh

여기서 몇 가지는 자신의 서버에 맞게 변경해야 합니다.

/var/www가 없으면 삭제해도 됩니다. /www가 없어도 삭제해도 됩니다. 블로그 데이터가 다른 디렉터리에 있다면 해당 디렉터리를 추가하세요. 데이터베이스가 Docker에 있다면 데이터베이스 덤프 명령어의 컨테이너 이름을 자신의 것으로 변경하세요.

경로를 그대로 복사해서 붙여넣기만 하면 안 됩니다. 백업 스크립트는 자신의 서버 실제 상황에 맞는 것이 가장 중요합니다.

첫 번째 수동 실행

스크립트를 작성한 후 먼저 수동으로 한 번 실행합니다:

sudo /usr/local/bin/backup-blog-to-qiniu.sh

처음에는 백업해야 할 모든 데이터를 업로드해야 하므로 시간이 좀 더 걸립니다.

실행 후 로그를 확인합니다:

tail -n 100 /var/log/blog-qiniu-backup.log

그리고 스냅샷을 확인합니다:

sudo bash -c 'source /etc/restic/blog.env && restic -r "$RESTIC_REPOSITORY" -o s3.region="$QINIU_REGION" snapshots'

새로운 스냅샷이 보이면 실제 백업이 성공한 것입니다.

주간 자동 백업 설정

저는 일주일에 한 번, 예를 들어 매주 월요일 새벽 4시에 백업하도록 설정했습니다.

root의 크론 작업을 편집합니다:

sudo crontab -e

다음 줄을 추가합니다:

0 4 * * 1 /usr/local/bin/backup-blog-to-qiniu.sh

이 줄의 의미는:

매주 월요일 새벽 4시에 백업 스크립트를 실행합니다.

저장 후 확인합니다:

sudo crontab -l

방금 추가한 줄이 보이면 크론 작업이 추가된 것입니다.

서버 시간대도 확인할 수 있습니다:

timedatectl

서버 시간대가 원하는 대로 설정되어 있지 않다면 한국 시간으로 변경할 수 있습니다:

sudo timedatectl set-timezone Asia/Seoul

백업 복구 방법

백업은 첫 번째 단계일 뿐, 복구가 핵심입니다.

먼저 어떤 스냅샷이 있는지 확인합니다:

sudo bash -c 'source /etc/restic/blog.env && restic -r "$RESTIC_REPOSITORY" -o s3.region="$QINIU_REGION" snapshots'

최신 백업을 /restore/blog에 복구합니다:

특정 스냅샷을 복구하려면 latest 대신 스냅샷 ID를 사용합니다:

복구 시 운영 중인 디렉터리를 직접 덮어쓰는 것은 권장하지 않습니다.

더 안정적인 방법은 먼저 임시 디렉터리, 예를 들어:

/restore/blog

에 복구한 후, 파일이 완전한지, 데이터베이스 덤프가 존재하는지, 설정에 문제가 없는지 확인한 다음 덮어쓸지 결정하는 것입니다.

MySQL 백업 파일이 있다면 다음과 같이 복구할 수 있습니다:

mysql -u root -p < mysql-all.sql

MySQL이 Docker 컨테이너에 있다면 다음과 같을 수 있습니다:

docker exec -i mysql컨테이너이름 mysql -u root -p데이터베이스비밀번호 < mysql-all.sql

구체적인 명령어는 데이터베이스 환경에 따라 다릅니다.

비용 관련

저빈도 스토리지의 비용은 업로드 트래픽보다 다음과 같은 항목에서 주로 발생합니다:

• 스토리지 용량 비용
• 요청 비용
• 복구 시 데이터 검색 비용
• 외부 네트워크로 다운로드 시 발생하는 송신 트래픽 비용

일주일에 한 번만 백업하고 평소에 복구하지 않는다면 비용이 크게 발생하지 않습니다.

비용이 실제로 높아지는 경우는 다음과 같습니다:

• Docker 디렉터리 전체를 백업하는 경우
• 로그, 캐시, 임시 파일을 백업하는 경우
• 백업에 많은 이미지, 동영상, 첨부 파일이 포함된 경우
• 저빈도 스토리지의 객체를 자주 삭제하는 경우
• 저빈도 스토리지에서 자주 다운로드하여 복구하는 경우

그래서 저는 '일주일에 한 번 백업하고 하나만 유지'하는 방식을 선택하지 않았습니다. 저빈도 스토리지는 빈번한 삭제에 적합하지 않으므로, 최근 12개의 주간 백업을 유지하는 것이 더 안정적입니다.

Restic의 보존 명령어는 다음과 같습니다:

restic forget --keep-weekly 12 --prune

이는 최근 12개의 주간 백업을 유지한다는 의미입니다.

나중에 블로그 데이터가 점점 커지면 전략을 조정할 수 있습니다. 예를 들어 8주, 12주, 24주를 유지하는 등 데이터 양과 예산에 따라 결정하면 됩니다.

최종 백업 전략

정리하자면, 제 백업 전략은 대략 다음과 같습니다:

• 블로그 파일을 백업한다.
• Nginx 설정을 백업한다.
• Docker Compose와 환경 변수를 백업한다.
• 데이터베이스는 별도로 덤프한다.
• 캐시, 로그, node_modules는 백업하지 않는다.
• 매주 자동으로 한 번 실행한다.
• 최근 12개의 주간 스냅샷을 유지한다.
• 일정 시간마다 수동으로 복구 테스트를 한 번씩 한다.

개인 블로그로서 이 방법은 복잡하지 않고 비용도 많이 들지 않습니다.

가장 중요한 것은 서버에 실제 문제가 생겼을 때 완전히 손을 쓸 수 없는 상황을 피하는 것입니다.

예전에는 백업이 '나중에 할 일'이라고 생각했습니다. 하지만 서버라는 것은 실제로 문제가 생길 때 일반적으로 미리 알려주지 않습니다.

그래서 이번 기회에 확실히 해두기로 했습니다.

블로그는 천천히 쓸 수 있고, 서버도 천천히 설정할 수 있지만, 데이터는 한 곳에만 두지 않는 것이 좋습니다.