개인 서버 백업을 미루면 안 되는 이유

개인 서버를 오래 운영하다 보면 묘한 안심이 생긴다. 오늘도 잘 돌아가니까, 내일도 괜찮겠지. 그러다 어느 날 디스크가 꽉 차거나, 잘못된 rm -rf를 실행하거나, 전원이 나간다.

백업은 문제가 생기기 전까지는 필요한지 실감이 안 된다. 그래서 자꾸 미루게 된다.

무엇을 백업해야 하는가

서버에서 복구 불가능한 것들을 먼저 정리하는 게 낫다.

• 데이터베이스: PostgreSQL이라면 pg_dump, SQLite라면 파일 복사
• 업로드 파일: /var/uploads 같은 사용자 첨부파일 디렉토리
• 설정 파일: nginx 설정, .env, systemd 서비스 파일
• SSL 인증서: Let's Encrypt라면 /etc/letsencrypt/ 전체

코드 자체는 git 리포지토리에 있으니 굳이 백업 대상에 넣지 않아도 된다.

현재 상태 빠르게 보기

df -h                          # 디스크 사용량
sudo ss -lntp                  # 열려 있는 포트
sudo journalctl -n 80          # 최근 시스템 로그

이 세 줄은 서버 이상이 의심될 때마다 먼저 실행하게 됐다. 특히 df -h는 디스크가 80% 넘으면 백업보다 정리가 먼저지만, 동시에 백업을 미루면 안 되는 신호이기도 하다.

자동화하지 않으면 실행되지 않는다

수동으로 백업하는 방법은 잊어버린다. cron으로 돌려두는 게 맞다.

# crontab -e
0 3 * * * pg_dump mydb | gzip > /backup/mydb-$(date +%Y%m%d).sql.gz
0 3 * * * rsync -az /var/uploads/ /backup/uploads/

백업 파일이 실제로 만들어지는지 다음 날 확인하는 것도 잊으면 안 된다. cron이 조용히 실패하는 경우가 생각보다 많다.

외부 저장소에 보내야 의미가 있다

같은 서버에 백업 파일을 저장하면 디스크 장애 때 같이 날아간다. rclone으로 S3나 Backblaze B2 같은 외부 스토리지에 주기적으로 올려두는 게 맞다.

rclone copy /backup/ remote:my-server-backup/

백업 파일의 크기와 날짜를 가끔 눈으로 확인하는 것도 좋다. 자동화했다고 믿고 2년 뒤 열어보면 비어있는 경우가 실제로 있다.