백업보다 중요한 복구: 20명에서 100명 규모의 사내 시스템 백업 설계

백업이 성공했다는 알림은 데이터를 되살릴 수 있다는 보증이 아니다. 파일이 손상됐거나, 필요한 암호화 키가 없거나, 복구 순서를 아무도 모르면 백업은 있어도 업무를 재개할 수 없다. 사내 시스템의 백업 설계는 저장 횟수보다 복구 목표와 복원 시험에서 시작해야 한다.

먼저 RPO와 RTO를 정한다

• RPO, 복구 시점 목표: 장애가 나면 최대 몇 분 또는 몇 시간의 데이터를 잃어도 되는가?
• RTO, 복구 시간 목표: 장애 발생 후 몇 시간 안에 업무를 다시 시작해야 하는가?

예를 들어 휴가 신청은 몇 시간 전 데이터로 돌아가도 수기로 보완할 수 있지만, 주문이나 회계 기록은 같은 기준을 적용하기 어렵다. 시스템 전체에 하나의 숫자를 붙이지 말고 업무별로 정한다.

백업 대상은 DB만이 아니다

대상	반드시 보존할 것	복구 때 확인할 것
데이터베이스	스키마, 업무 데이터, 권한 정책	버전 호환, 확장 기능, 사용자 권한
객체 저장소	원본 파일, 결과 파일, 메타데이터	DB의 파일 키와 실제 객체 일치
애플리케이션	소스, 이미지, 배포 설정	특정 버전을 다시 배포할 수 있는가
설정과 비밀정보	필요한 환경 설정과 키의 안전한 사본	접근 권한, 키 교체 여부
운영 기록	복구 절차, 담당자, 최근 시험 결과	담당자가 없어도 따라 할 수 있는가

소스 저장소는 백업의 일부일 뿐이다. 배포 당시 이미지와 DB 스키마가 맞지 않으면 애플리케이션을 재배포해도 정상 동작하지 않는다. 마이그레이션과 배포 버전을 함께 기록해야 한다.

관리형 백업도 별도 사본이 필요하다

Supabase의 유료 플랜은 자동 일일 백업 보존 기간을 제공하고, 더 짧은 복구 시점이 필요하면 PITR을 선택할 수 있다. 하지만 프로젝트를 삭제하면 해당 프로젝트의 백업도 함께 영구 삭제된다. 무료 프로젝트는 정기적인 논리 백업과 외부 보관이 특히 중요하다. Supabase 데이터베이스 백업

물리 백업이나 PITR을 사용하는 프로젝트는 대시보드에서 내려받는 논리 백업 파일이 없을 수 있다. 이 경우 Supabase CLI의 db dump나 pg_dump로 별도 논리 사본을 만들어야 한다. Supabase 논리 백업 내려받기

R2나 S3의 파일도 같은 계정 안에 복사해 두는 것만으로는 충분하지 않다. 잘못된 삭제 권한이 원본과 복사본에 동시에 적용될 수 있기 때문이다. 보존 잠금, 별도 버킷 또는 별도 계정, 삭제 권한 분리를 조합한다. R2의 Bucket Lock은 정한 기간 동안 객체 삭제를 막을 수 있고, 수명 주기 규칙보다 잠금 규칙이 우선한다. Cloudflare R2 Bucket Lock

인원별 현실적인 운영 단계

20명

• 관리형 DB 자동 백업을 확인한다.
• 주 1회 이상 논리 백업을 다른 저장 위치에 보관한다.
• 중요한 파일은 원본 저장소와 권한이 분리된 위치에 복제한다.
• 분기마다 한 번, 새 환경에 DB와 파일 일부를 복원한다.

50명

• 업무별 RPO와 RTO를 문서화한다.
• 백업 실패, 마지막 성공 시각, 저장 용량을 감시한다.
• 월 1회 복원 시험을 하고 담당자 외 한 명도 절차를 수행해 본다.
• 삭제 사고를 대비해 보존 정책과 관리자 승인 절차를 둔다.

100명

• 핵심 업무에는 PITR이나 더 짧은 백업 간격을 검토한다.
• 운영 계정 침해를 가정해 별도 계정과 별도 자격 증명으로 사본을 보관한다.
• 연 1회 이상 전체 재해 복구 훈련을 하고 실제 RTO를 잰다.
• 복구 중 사용할 임시 업무 절차와 공지 책임자를 정한다.

복원 시험에서 확인할 항목

1. 빈 환경에서 시작해 문서만 보고 복구할 수 있는가?
2. DB 사용자, 확장 기능, 스토리지 권한까지 돌아오는가?
3. 첨부 파일 링크가 깨지지 않는가?
4. 복구된 시스템에서 로그인과 핵심 업무가 가능한가?
5. 실제 소요 시간이 목표 RTO 안에 들어오는가?
6. 복구용 키와 백업에 접근한 기록이 남는가?

좋은 백업은 많은 사본이 아니라, 삭제 사고와 계정 침해를 견디고 정해진 시간 안에 업무를 되살릴 수 있는 사본이다. 마지막 백업 성공 시각보다 마지막 복원 성공 시각을 운영 대시보드에 표시하면 팀의 관심도 자연스럽게 복구 가능성으로 이동한다.