백업처럼 보이는 파일이 계속 쌓이면 저장 비용을 줄이고 싶어진다. 당시에는 명시적으로 허용된 백업 정리와 반복 생성 중단이 진행됐고, 아홉 개 R2 버킷의 해당 객체 목록까지 다시 확인했다.
하지만 그 조치를 누구에게나 그대로 적용할 기본 방법으로 공개할 수는 없다. 그 환경에서는 필요 없다고 판단한 보존 정책이었고, 다른 사업의 복구 요구는 다를 수 있다. 공개할 노하우는 삭제 명령보다 먼저 해야 할 구분이다.
내가 잃고 싶지 않은 것은 무엇인가
나는 저장 공간이 줄었다는 말보다 필요한 자료를 다시 찾을 수 있는지를 더 먼저 묻는다. 비용을 줄일 자료와 반드시 남길 자료를 구별하고, 복구할 수 있다는 설명을 실제 복구 절차와 연결한다.
자료를 세 층으로 구별한다
- 운영 원본: 서비스가 지금 의존하는 자료.
- 재생성 가능한 캐시: 원본과 생성 절차가 있어 다시 만들 수 있는 결과.
- 복구용 사본: 장애나 잘못된 변경 이전으로 돌아가기 위해 보존한 자료.
정책을 바꾸기 전에 묻는 질문
이 객체를 지워도 같은 내용을 다시 만들 수 있는가? 원본도 같은 버킷에 있는가? 얼마나 오래된 시점까지 복구해야 하는가? 복구 방법을 실제로 시험했는가?
prefix 이름에 backup이 들어간다는 이유만으로 전체 객체를 삭제하지 않는다. 적용 대상 목록과 개수·크기를 먼저 검토하고, 보존 결정과 복구 검증을 기록한다. 이 글에는 운영 데이터를 지우는 일괄 명령을 넣지 않는다.
수명 주기와 데이터베이스 이력을 따로 본다
R2 수명 주기는 정해진 대상 객체의 보존 동작을 자동화한다. 규칙이 걸리는 prefix와 다른 정책의 겹침을 확인해야 한다. D1 Time Travel은 별도의 데이터베이스 복구 기능이므로 R2에 사본 파일이 없다는 이유로 같은 상태라고 판단하지 않는다.
코드와 구현 살펴보기
정책 검토용 기록 형식 · 자동 삭제 설정이 아님
{
"scope": "a reviewed test prefix",
"classification": "regenerable cache",
"source_preserved": true,
"restore_drill_completed": true,
"reviewed_object_count": 0,
"approved_retention_days": null
}독립적인 운영자가 알아야 할 것
원본이 어디에 있고 어떤 명령으로 복구하며 얼마만큼 과거로 돌아갈 수 있는지를 문서만으로 설명할 수 있어야 한다. 한도와 보존 기간은 사용 중인 제품과 플랜의 현재 문서에서 확인한다.
내가 공개하려는 것은 비용을 줄였다는 성공담만이 아니다. 비용을 줄이는 동안 복구 책임까지 어떻게 남기는가에 관한 판단 과정이다.