다중 서버 백업·복구 전략 — rsync Pull 기반 자동 백업과 재해 복구

서버가 죽는 건 시간 문제입니다. 정전, 디스크 고장, 랜섬웨어 — 어떤 이유든 데이터는 사라집니다. 백업은 "할까 말까"가 아니라 "얼마나 빨리 복구할 수 있느냐"의 문제입니다. 다중 서버 환경에서 rsync Pull 방식으로 자동 백업하고, SMART로 디스크 건강을 감시하고, 어떤 서버가 죽어도 빈 서버에 재구축하는 절차를 정리합니다.백업 서버 하드웨어는 이전 글에서 다뤘으니, 이 글은 운영 전략과 자동화에 집중합니다.

백업이 필요한 진짜 이유

정전은 UPS로 버틸 수 있고, 네트워크 장애는 재부팅으로 해결됩니다. 진짜 무서운 건 디스크의 물리적 고장입니다. HDD의 연간 고장률(AFR)은 1~3%입니다. 서버 10대를 3년 운영하면 1대 이상에서 디스크 고장이 발생할 확률이 26~60%입니다.

Pull vs Push

서버 백업 방식은 크게 Push(운영 서버가 백업 서버에 보냄)와 Pull(백업 서버가 운영 서버에서 가져옴)로 나뉩니다. Pull 방식을 선택한 이유는 보안과 중앙 관리입니다.

Pull 방식의 핵심은 "운영 서버는 백업에 대해 아무것도 모른다"는 것입니다. 백업 서버가 SSH 키로 운영 서버에 접속해 rsync로 데이터를 가져옵니다. 운영 서버 입장에서는 평소와 다름없이 SSH 접속을 허용할 뿐이며, 백업 스크립트가 존재하지 않으므로 공격자가 운영 서버를 장악해도 백업을 손상시킬 수 없습니다.

rsync 스크립트 설계

rsync의 --archive --compress --delete 옵션으로 증분 백업을 수행합니다. 변경된 파일만 전송하므로 첫 백업 이후에는 수 분 이내에 완료됩니다.

cron 스케줄 설계

다중 서버를 동시에 백업하면 네트워크 대역폭과 디스크 I/O가 겹칩니다. 서버별로 시간을 분리해 백업 윈도우 충돌을 방지합니다.

30분 간격으로 배치하면 이전 백업이 완료된 후 다음 백업이 시작됩니다. AI 추론 서버의 모델 파일이 가장 크지만(수십 GB), 모델 변경이 없으면 rsync 증분이라 실제 전송은 수 MB입니다. flock이 있으므로 만약 이전 백업이 늦어져도 다음 백업과 충돌하지 않습니다.

HDD 건강 감시

백업 디스크가 죽으면 백업이 의미 없습니다. WD Red Pro 10TB × 3의 SMART 상태를 30분마다 자동 체크하고, Grafana에서 실시간 모니터링합니다.

가장 중요한 SMART 지표는 Reallocated_Sector_Ct(재할당된 섹터 수)입니다. 이 값이 0에서 1로 바뀌는 순간이 디스크 교체 타이밍입니다. "아직 동작하니까 괜찮다"가 아니라, "재할당이 시작됐으면 곧 더 많아진다"는 전제로 움직입니다. 디스크 가격보다 데이터 소실 비용이 압도적으로 크기 때문입니다.

재해 복구 계획

재해 복구에서 가장 중요한 원칙은 "전자동 복구를 하지 않는다"입니다. 자동 복구는 잘못 트리거될 위험이 있습니다. 네트워크 순단을 장애로 오판하고 정상 데이터를 백업 데이터로 덮어쓸 수 있습니다. 사람이 상황을 확인하고, 복구 범위를 판단한 후, 명시적으로 복구를 실행합니다.

실전 교훈

백업 서버 구축 과정에서 Seagate IronWolf 12TB에서 WD Red Pro 10TB로 교체한 경험입니다.

정리

백업은 "보험"이 아니라 "인프라"입니다. 서버가 죽었을 때 "얼마나 빨리 복구할 수 있느냐"가 백업 시스템의 성능입니다. rsync Pull + flock + SMART + 수동 복구 절차 — 이 네 가지를 갖추면, 어떤 서버가 죽어도 반나절 이내에 서비스를 복원할 수 있습니다.