백업이 없으면 복구도 없다

서버 운영에서 백업은 보험이다. 아무 일 없을 때는 비용과 수고만 드는 것 같지만, 장애가 터지는 순간 백업이 없으면 모든 것을 잃는다. 하드웨어 고장, 랜섬웨어 감염, 운영자의 실수로 인한 데이터 삭제, 소프트웨어 업데이트 중 데이터 손상까지, 데이터를 잃는 시나리오는 끝없이 많다. 서버 백업의 기본 개념과 전략을 정리한다.

풀 백업, 증분 백업, 차등 백업

백업 방식은 크게 세 가지로 나뉜다. 풀 백업(Full Backup)은 전체 데이터를 매번 복사하는 방식이다. 복구가 간단하지만 시간과 저장 공간을 많이 소모한다. 증분 백업(Incremental Backup)은 마지막 백업 이후 변경된 데이터만 복사한다. 속도가 빠르고 저장 공간도 적게 쓰지만, 복구 시 풀 백업본과 이후 모든 증분본을 순서대로 적용해야 한다. 차등 백업(Differential Backup)은 마지막 풀 백업 이후 변경된 모든 데이터를 복사한다. 증분보다 복구가 빠르지만 시간이 지날수록 백업 크기가 커진다. 실무에서는 주 1회 풀 백업, 매일 증분 백업을 조합하는 방식이 가장 보편적이다.

3-2-1 백업 원칙

백업 전략의 표준으로 통하는 규칙이다. 데이터 사본을 최소 3개 보관하고, 2종류 이상의 서로 다른 저장 매체에 저장하며, 1개는 물리적으로 다른 장소에 보관한다. 예를 들어 서버 로컬 디스크에 1차 백업, 외장 NAS에 2차 백업, AWS S3 같은 클라우드 스토리지에 3차 백업을 두는 구조다. 로컬 백업만 있으면 서버실 화재나 침수 시 원본과 백업이 동시에 소실된다. 원격지 백업이 이 위험을 제거한다.

데이터베이스 백업의 특수성

파일 시스템 백업과 데이터베이스 백업은 성격이 다르다. 데이터베이스가 가동 중인 상태에서 단순히 데이터 파일을 복사하면 트랜잭션 일관성이 깨진 불완전한 백업이 될 수 있다. MySQL의 mysqldump, PostgreSQL의 pg_dump 같은 논리적 백업 도구는 일관된 스냅샷을 생성한다. 대용량 데이터베이스에서는 물리적 백업 도구(XtraBackup, pg_basebackup)가 속도 면에서 유리하다. WAL(Write-Ahead Log) 아카이빙을 설정하면 특정 시점으로 복구하는 PITR(Point-In-Time Recovery)이 가능해진다.

백업 검증을 하지 않은 백업은 백업이 아니다

백업을 수행하는 것만으로는 부족하다. 백업 파일이 실제로 복구 가능한지 정기적으로 검증해야 한다. 실무에서 의외로 흔한 사고가 수개월간 백업을 돌렸는데 정작 복구하려니 파일이 손상되어 있었다는 케이스다. 월 1회 이상 테스트 환경에서 백업 파일을 실제로 복원하고, 데이터 정합성을 확인하는 절차를 운영 프로세스에 포함시켜야 한다.

백업 자동화

백업은 사람이 수동으로 하면 반드시 누락이 발생한다. cron 스케줄러로 백업 스크립트를 자동 실행하고, 결과를 Slack이나 이메일로 통지받는 파이프라인을 구성하는 것이 표준이다. 오픈소스 도구로는 rsync 기반 스크립트, Restic, Borg Backup이 널리 쓰이며, 클라우드 환경에서는 AWS Backup, GCP Snapshot 같은 매니지드 서비스를 활용할 수 있다.

서버백업 #데이터백업 #3-2-1백업 #증분백업 #풀백업 #데이터베이스백업 #PITR #백업전략 #rsync #재해복구