보안 기준: 백업과 복구

데이터를 얼마나 자주 백업하고, 문제가 생겼을 때 어디까지 되돌릴 수 있는지를 정리한 문서입니다. 전체 구성은 업무 시스템 보안 기준에 있습니다.

백업은 두 가지 질문으로 정합니다

백업 이야기는 「매일 받습니다」로 끝나기 쉽지만, 실제로 필요한 답은 둘입니다.

질문	뜻	예
어느 시점까지 되돌릴 수 있는가	사고 직전 얼마만큼의 작업이 사라질 수 있는가	하루치까지 감수 / 한 시간 이내
되돌리는 데 얼마나 걸리는가	업무가 멈추는 시간	반나절 / 한 시간

앞의 것을 복구 목표 시점, 뒤의 것을 복구 목표 시간이라고 부릅니다. 이 둘을 정하지 않으면 「백업이 있다」와 「업무가 곧 재개된다」가 다른 이야기라는 것을 사고가 난 뒤에 알게 됩니다.

기본 구성

특별한 요구가 없으면 다음을 기준으로 합니다.

• 데이터베이스 자동 백업을 매일 1회 수행합니다
• 백업은 운영 데이터베이스와 다른 저장소에 보관합니다
• 보관 기간은 계약에서 정한 기간(예: 30일)을 따릅니다
• 고객이 요청하면 데이터를 일반적으로 사용할 수 있는 형식으로 제공합니다

관리형 데이터베이스 서비스를 쓰는 경우 플랜에 따라 보관 기간이 다릅니다. 예를 들어 Supabase 문서는 Pro 플랜이 최근 7일, Team 14일, Enterprise 30일의 일일 백업을 제공하며, 더 촘촘한 복구가 필요하면 시점 복구(PITR) 기능을 켜라고 안내합니다. 어떤 플랜을 쓸지는 필요한 보관 기간과 함께 정합니다.

고객사가 정할 것

결정	고려할 점
되돌릴 수 있어야 하는 기간	며칠 전 자료까지 복구가 필요한지
감수할 수 있는 손실 범위	하루치 입력이 사라져도 되는지, 한 시간 이내여야 하는지
백업 비용	촘촘한 복구는 비용이 올라갑니다

업무 성격에 따라 답이 다릅니다. 하루 몇 건이 들어오는 시스템과, 하루 수백 건이 들어오는 시스템은 하루치 손실의 무게가 다릅니다.

복구는 미리 해 봅니다

백업 파일이 있다는 것과 그 파일로 시스템이 되살아난다는 것은 다른 사실입니다. 그래서 구축 단계에서 복구를 한 번 해 봅니다. 확인하는 것은 셋입니다.

1. 백업에서 데이터베이스가 정상적으로 복원되는가
2. 복원 후 화면이 정상 동작하는가
3. 복원에 실제로 얼마나 걸리는가

세 번째가 복구 목표 시간의 근거가 됩니다. 「반나절」이라고 적어 두었는데 실제로 이틀이 걸린다면 그 계획은 틀린 것입니다.

사람이 지운 데이터

장애보다 흔한 것은 사람이 실수로 지우는 경우입니다. 그래서 시스템 쪽에서도 다음을 함께 설계합니다.

• 중요한 자료는 바로 삭제하지 않고 사용 중지로 둡니다. 지난 기록이 그 자료를 가리키고 있기 때문입니다
• 삭제와 수정은 감사 로그에 남깁니다
• 되돌리기가 필요한 동작은 확인 절차를 한 번 둡니다

백업에서 복구하면 그 시점 이후의 다른 작업도 함께 되돌아갑니다. 실수 하나 때문에 전체를 되돌리는 일이 없도록, 시스템 안에서 되살릴 수 있는 범위를 넓혀 두는 편이 낫습니다.

자주 막히는 곳

상황	원인	대응
백업은 있는데 복구해 본 적이 없습니다	설정만 하고 확인을 미뤘습니다	구축 단계에서 1회, 이후 주기적으로 확인
복구했더니 최근 자료가 없습니다	백업 주기와 기대가 달랐습니다	되돌릴 시점 기준을 다시 정합니다
실수로 지운 자료 하나 때문에 전체를 되돌려야 합니다	시스템 안에 되살릴 방법이 없습니다	사용 중지 방식과 기록 보존을 검토합니다
백업 파일을 어디서 받는지 모릅니다	인계가 없었습니다	인수인계 시 위치와 절차를 문서로 받습니다

출처

• Supabase: Database Backups