새벽마다 NAS로 — tar+ssh 자동 백업 (왜 rsync를 안 썼나)

셀프호스팅 구축기 12편. 서버는 지켰다(11편). 이제 서버가 죽어도 데이터는 살리는 법.

← 이전 편: 11편 — 공짜로 워드프레스 지키기 (Wordfence)
→ 다음 편: 13편 — 내 노트는 내 서버에 (Obsidian LiveSync)

요약

• 백업 없는 셀프호스팅은 시한폭탄 — 디스크 하나 죽으면 사진·글·DB가 한 번에 사라진다
• 매일 새벽 cron이 중요 폴더를 tar로 묶어 ssh로 NAS에 던진다
• rsync(전용 데몬·포트 873)를 일부러 안 썼다 — SSH는 이미 열려 있으니 추가로 열 포트가 0
• DB 덤프가 끝난 뒤 파일 백업이 돌아야 그 덤프까지 한 묶음에 들어간다 — 순서가 정합성을 만든다
• “백업이 돌았다”와 “백업이 성공했다”는 다르다 — 0바이트 파일은 실패로 처리

1. 백업 없는 셀프호스팅 = 시한폭탄

내 컴퓨터에 블로그를 올린다는 건, 클라우드가 대신 해주던 백업도 내 책임이 된다는 뜻이다. SSD 하나가 수명을 다하거나, 명령 하나 잘못 치면, 몇 달치 글과 사진과 데이터베이스가 한순간에 날아간다.

규칙은 단순하다. 백업은 다른 물리적 장치에, 자동으로, 매일. 손으로 하는 백업은 반드시 잊어버린다.

2. 왜 rsync가 아니라 tar + ssh인가

백업이라면 보통 rsync를 떠올린다. 빠르고 증분 동기화도 된다. 그런데 NAS(여기선 시놀로지)에서 rsync를 제대로 쓰려면 rsync 전용 서비스(데몬, 포트 873)를 켜야 한다. 포트를 하나 더 여는 것이다.

우리 데이터는 작아서 매일 통째로 묶어도 부담이 없다. 그렇다면 포트를 더 여는 대가를 치를 이유가 없다. 노출 면적을 줄이는 쪽이 셀프호스팅에선 거의 항상 옳다.

3. 한 줄짜리 백업

tar czf - /중요/데이터/폴더 | ssh -p <포트> [email protected] "cat > /backup/site-$(date +%F).tgz"

tar czf -는 폴더를 묶어 화면(stdout)으로 흘려보내고, 그걸 ssh가 받아 NAS에서 파일로 떨군다. 중간에 임시 파일을 만들지 않으니 디스크도 덜 쓴다. 파일명에 날짜($(date +%F))가 들어가 매일 다른 이름으로 쌓인다.

4. 순서가 정합성을 만든다 — DB 먼저

데이터베이스는 그냥 폴더를 복사하면 안 된다. 쓰는 도중에 복사하면 반쯤 쓰다 만 상태가 백업될 수 있다. 그래서 먼저 DB를 안전하게 덤프(dump) 파일로 뽑고, 그 덤프가 끝난 뒤에 파일 백업이 돌아야 한다.

flowchart LR
    A[04:30 DB 덤프] --> B[덤프 파일 생성]
    B --> C[05:00 파일 백업
덤프 포함해서 묶음]
    C --> D[NAS 전송]

시간차를 두는 이유가 이것이다. 두 cron의 순서가 곧 백업의 정합성이다.

5. “성공”을 검증하라

가장 흔한 착각: cron이 시간 맞춰 실행됐으면 백업이 된 줄 안다. 하지만 실행 ≠ 성공이다. 디스크가 꽉 찼거나 NAS가 잠깐 죽었으면, 0바이트짜리 빈 파일이 남는다.

• 백업이 끝나면 만들어진 파일 크기를 확인한다
• 일정 크기 미만이면 실패로 간주하고 알림을 보낸다
• 오래된 백업은 자동 삭제(rotate)해서 디스크가 차지 않게 한다

이 세 줄을 추가하는 순간, 백업은 “있는 줄 알았는데 비어 있던” 함정에서 벗어난다.

한 줄 정리

백업은 다른 장치에·자동으로·매일. tar czf - … | ssh면 포트 하나 더 안 열고 NAS에 던질 수 있다. DB 덤프 먼저, 그다음 파일 백업. 그리고 크기를 확인해 “성공”을 검증하자 — 비어 있는 백업은 백업이 아니다.