오래된 웹 페이지를 지금 다시 읽어야 하는 이유
인터넷 초창기부터 전해 내려오는 'The Tao of Backup(백업의 도)'이라는 웹사이트가 있어요. 노자의 도덕경 같은 동양 고전 말투를 흉내 낸 글인데요, 백업이 뭔지 묻는 초심자에게 스승이 선문답처럼 답해주는 짧은 이야기들로 이루어져 있어요. 디자인은 그 시절 그대로 투박하지만, 내용은 지금 읽어도 뜨끔할 만큼 정확하거든요.
이렇게 오래된 글을 지금 다시 볼 만한 이유가 있어요. 기술은 발전했는데 백업 사고는 줄지 않았거든요. 클라우드, 스냅샷, RAID, Git까지 있으니 다들 “우린 괜찮겠지” 하는데, 막상 사고가 나면 “백업은 있었는데 복구가 안 되더라”는 얘기가 꼭 나와요. 대표적인 예가 2017년 GitLab.com 사고예요. 실수로 운영 DB를 지웠는데, 여러 겹으로 준비해 둔 백업 방식 중 제대로 작동한 게 거의 없었어요. 우리나라에서도 2025년 국가정보자원관리원 화재 때, 공무원 업무용 클라우드인 'G드라이브' 자료를 따로 백업해 두지 않아 복구가 어려웠다는 보도가 있었고요.
The Tao of Backup은 이런 실수를 피하는 방법을 7가지 원칙으로 정리해요. 하나씩 요즘 개발 환경에 맞춰 풀어볼게요.
백업의 7원칙을 요즘 환경에 맞춰 읽기
1. 범위(Coverage): 전부 백업하고 있나요?
코드만 백업해 두고 안심하는 경우가 많아요. 그런데 잃어버렸을 때 진짜 아픈 건 DB 데이터, 서버 설정 파일,.env 같은 시크릿, CI/CD 설정, 그리고 Notion이나 GitHub 이슈처럼 SaaS 안에 있는 데이터예요. “Git에 올라가 있으니 괜찮다”는 건 코드에만 해당하는 얘기예요.2. 빈도(Frequency): 얼마나 자주 하나요?
여기서 알아두면 좋은 용어가 RPO(복구 시점 목표)예요. 이게 뭐냐면 “사고가 나면 최대 몇 시간 치 데이터까지 잃어도 괜찮은가”를 정한 기준이에요. 하루에 한 번 백업하면 최악의 경우 하루 치 작업을 날릴 수 있어요. 그러니 데이터가 얼마나 자주 바뀌는지를 보고 백업 주기를 정해야 해요.3. 분리(Separation): 원본과 같은 곳에 두지 마세요
원본과 같은 서버, 같은 디스크, 같은 데이터센터에 있는 백업은 화재나 랜섬웨어가 닥치면 원본과 함께 사라져요. 그래서 나온 게 유명한 3-2-1 규칙이에요. 복사본은 3개, 저장 매체는 2종류 이상, 그중 1개는 다른 장소에 두라는 거예요. 요즘은 랜섬웨어 때문에 수정이나 삭제가 아예 안 되는(immutable) 백업도 함께 두는 추세예요. S3의 Object Lock 같은 기능이 그 역할을 해요.4. 이력(History): 여러 시점을 남기세요
파일이 조용히 망가졌는데 아무도 모른 채 백업이 그 위를 덮어쓰면 백업도 같이 망가져요. 그래서 여러 시점의 버전을 남겨둬야 해요. 그리고 동기화(sync)와 RAID는 백업이 아니에요. 실수로 지운 파일은 동기화되는 순간 반대편에서도 지워지거든요.5. 검증(Testing): 복구해 본 적 있나요?
7원칙 중 딱 하나만 꼽으라면 이거예요. 한 번도 복구해 보지 않은 백업은 '백업이라고 믿는 파일'일 뿐이에요. 정기적으로 실제 복구 훈련을 하고, 복구하는 데 몇 시간이 걸리는지(RTO, 복구 시간 목표)도 재봐야 해요.6. 보안(Security): 백업도 지켜야 해요
백업에는 원본 데이터가 고스란히 들어 있어요. 운영 DB는 꽁꽁 막아두고 덤프 파일은 아무나 접근할 수 있는 버킷에 두면 소용이 없죠. 백업은 암호화하고, 백업에 접근하는 권한은 운영 계정과 따로 관리하세요.7. 무결성(Integrity): 백업하는 데이터가 멀쩡한가요?
이미 깨진 데이터를 백업하면 깨진 백업이 하나 더 생길 뿐이에요. 체크섬으로 백업 파일이 손상되지 않았는지 주기적으로 확인하고, DB라면 덤프가 끝까지 정상적으로 됐는지도 확인해야 해요.요즘 도구로 실천하기
개인 개발 환경이나 작은 서비스라면 restic이나 borg 같은 도구로 시작하기 좋아요. 중복 제거, 암호화, 스냅샷 이력 관리를 기본으로 지원해서 7원칙 중 여러 개를 한 번에 챙길 수 있거든요. restic으로 하면 흐름이 이래요.
- 백업:
restic -r <저장소> backup ~/projects - 무결성 점검:
restic -r <저장소> check --read-data-subset=5% - 복구 테스트:
restic -r <저장소> restore latest --target /tmp/restore-test
한국 개발자에게 주는 시사점
스타트업이나 작은 팀일수록 백업은 “인프라 담당이 알아서 하겠지” 하고 넘어가기 쉬워요. 그런데 사고가 나면 가장 먼저 듣는 질문이 “언제 시점으로 되돌릴 수 있어요?”예요. 이번 주에 딱 한 가지만 해보세요. 백업 파일 하나를 골라서 실제로 복구해 보는 거예요. 해보면 생각보다 많은 구멍이 보일 거예요.
마무리
한 줄 정리: 백업의 핵심은 '저장해 두는 것'이 아니라 '복구할 수 있다는 확신'이에요.
여러분 팀은 마지막으로 복구 훈련을 한 게 언제인가요? 백업은 있었는데 복구가 안 됐던 경험이 있다면 같이 나눠주세요.
🔗 출처: Hacker News