04. 파일 Object Storage 백업 상세

이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.

• 파일 백업은 DB 백업과 왜 별도로 다뤄야 하는가?
• Object Storage에서 삭제와 덮어쓰기를 복구하려면 무엇을 준비해야 하는가?
• Spring 업로드 흐름에서 DB row와 object key 불일치는 어떻게 발생하는가?

개요

사용자 업로드 파일은 DB 백업만으로 복구되지 않는다.

DB에는 파일의 metadata, owner, object key, 상태 값이 있고 실제 bytes는 Object Storage에 저장되는 경우가 많다.

따라서 파일 백업은 DB 백업과 같은 시각, 같은 보존 정책, 같은 복구 검증으로 다뤄야 한다.

백엔드 개발자는 업로드, 교체, 삭제, 만료 처리 흐름을 설명할 수 있어야 한다.

그 흐름을 모르면 파일은 있는데 DB row가 없거나, DB row는 있는데 object가 없는 상태를 만들 수 있다.

파일 데이터의 특징

파일 데이터는 DB row와 다른 운영 특성을 가진다.

• 파일은 크기가 커서 전체 복사 비용이 크다.
• 삭제나 덮어쓰기가 즉시 영구 손실이 될 수 있다.
• lifecycle 정책이 오래된 object를 자동 삭제할 수 있다.
• CDN cache나 thumbnail 생성 결과가 원본과 다르게 남을 수 있다.
• object key는 DB row와 연결되어야 의미가 생긴다.
• 파일에는 개인정보나 민감 정보가 포함될 수 있어 접근 로그와 암호화가 중요하다.

파일 백업은 “버킷을 복사했다”가 아니라 “사용자가 다시 접근할 수 있다”까지 확인해야 한다.

Spring 업로드 흐름

일반적인 Spring 업로드 흐름은 DB 트랜잭션과 Object Storage 작업이 완전히 하나로 묶이지 않는다.

client upload
  Spring controller
    validate file
      upload object
        save file metadata row
          return file id

이 흐름에서는 다음 불일치가 생길 수 있다.

• object upload는 성공했지만 DB insert가 실패한다.
• DB row는 생성됐지만 object upload가 timeout 처리된다.
• 사용자가 파일을 교체했는데 이전 object 삭제가 실패한다.
• 삭제 요청 후 DB row만 삭제되고 object가 남는다.
• lifecycle 정책이 object를 삭제했지만 DB row는 남아 있다.

백업과 복구 문서는 이런 불일치를 찾는 검증 SQL과 object 목록 비교를 포함해야 한다.

버전 관리와 보존

Object Storage 백업의 핵심은 삭제와 덮어쓰기를 되돌릴 수 있는지다.

다음 설정을 확인한다.

• versioning 활성화 여부
• 삭제 marker 보존 여부
• lifecycle 만료 기간
• replication 대상 버킷과 지연 시간
• 암호화 키와 복구 권한
• object lock 또는 retention 정책
• 접근 로그와 감사 로그 보존 기간

Versioning이 없으면 잘못된 삭제를 복구할 수 있는 시간이 매우 짧아진다.

Lifecycle 정책은 비용 절감에 유용하지만 복구 요구와 충돌할 수 있다.

관찰 명령 예시

S3 compatible storage를 쓴다면 object와 version 상태를 별도로 확인한다.

aws s3api list-objects-v2 \
  --bucket user-files-prod \
  --prefix uploads/2026/07/01/ \
  --max-items 20
 
aws s3api list-object-versions \
  --bucket user-files-prod \
  --prefix uploads/2026/07/01/

DB metadata와 object key를 비교한다.

select id, object_key, status, created_at
from file_assets
where created_at >= timestamp '2026-07-01 00:00:00'
order by created_at desc
limit 50;

운영 문서에는 명령 결과 자체보다 누락 여부, 기준 시각, 대상 prefix, 검사한 샘플 수가 남아야 한다.

복구 시나리오

파일 복구는 사고 유형별로 절차가 다르다.

• 사용자가 실수로 삭제한 파일은 versioning에서 이전 version을 복원한다.
• 배치가 잘못된 prefix를 삭제했다면 삭제 marker와 감사 로그로 범위를 찾는다.
• DB row만 사라졌다면 object 목록에서 metadata를 재구성할 수 있는지 검토한다.
• object만 사라졌다면 DB row를 기준으로 사용자 영향 범위를 계산한다.
• thumbnail만 손실되었으면 원본에서 재생성하는 편이 복구보다 안전할 수 있다.

모든 파일을 한 번에 복원하기보다 손실 범위를 확정하고 우선순위를 나눠야 한다.

운영 체크리스트

• DB 백업과 Object Storage 백업의 기준 시각을 함께 기록한다.
• versioning과 lifecycle 설정을 복구 목표와 비교한다.
• 파일 삭제 배치가 dry-run과 승인 절차를 갖는지 확인한다.
• object key naming이 사용자, 날짜, 도메인 기준으로 추적 가능한지 확인한다.
• 업로드 실패와 DB 저장 실패를 별도로 로깅하는지 확인한다.
• 복구 후 접근 권한과 presigned URL 생성이 정상인지 확인한다.
• 원본과 파생 파일의 복구 우선순위를 구분한다.

장애 신호

• DB에는 파일 row가 있는데 object 조회가 404를 반환한다.
• 버킷에는 object가 있는데 어느 사용자 파일인지 알 수 없다.
• lifecycle 변경 후 오래된 첨부 파일 문의가 급증한다.
• 삭제 배치 실행 후 특정 prefix의 object 수가 급감한다.
• versioning이 꺼져 있어 이전 파일을 찾을 수 없다.
• 복구한 파일의 권한이 잘못되어 다른 사용자가 접근할 수 있다.

파일 장애는 데이터 손실이면서 보안 사고가 될 수도 있다.

안전한 완화 조치

• 삭제 사고가 의심되면 lifecycle와 삭제 배치를 즉시 멈춘다.
• 해당 prefix에 object lock이나 보존 정책을 적용할 수 있는지 확인한다.
• DB row와 object key 목록을 먼저 export해 증거를 보존한다.
• 복원은 별도 prefix에 수행한 뒤 검증 후 교체한다.
• 사용자 접근 권한을 확인하기 전 공개 URL을 다시 열지 않는다.
• thumbnail이나 cache 파일은 원본 보존 여부를 먼저 확인한다.

복구 속도보다 손실 범위 확정과 권한 검증이 우선이다.

하지 말아야 할 대응

• DB 백업만 복원하고 파일 복구가 끝났다고 보고하지 않는다.
• 삭제된 prefix에 새 파일을 먼저 업로드해 증거를 덮지 않는다.
• versioning 상태를 확인하지 않고 lifecycle 정책을 다시 실행하지 않는다.
• object key를 추측해 수동으로 연결하지 않는다.
• 접근 권한 검증 없이 복구 파일을 공개하지 않는다.

인프라 담당자와 공유할 자료

• 버킷명, prefix, region, versioning 상태
• 사고 기준 시각과 의심되는 삭제/덮어쓰기 작업
• 관련 DB 테이블과 object key 샘플
• lifecycle, replication, retention 설정 변경 이력
• 손실된 원본 파일과 재생성 가능한 파생 파일 구분
• 복구 후 확인해야 할 사용자 접근 경로

공유 자료는 DB와 Object Storage를 같은 시간축으로 맞춰야 한다.

확인 질문

확인 질문

• DB 백업만으로 사용자 파일 복구가 끝나지 않는 이유는 무엇인가?
  • DB에는 metadata와 object key만 있고 실제 파일 bytes는 Object Storage에 있기 때문이다.
• 삭제된 파일을 복구하려면 Object Storage에서 무엇이 필요할 수 있는가?
  • versioning, 삭제 marker, retention, 감사 로그, 복구 권한이 필요할 수 있다.
• DB row와 object key 불일치를 줄이려면 무엇을 검증해야 하는가?
  • 업로드/삭제 흐름의 실패 지점과 DB metadata, object 목록의 기준 시각별 일치 여부를 검증해야 한다.

리뷰 체크포인트

• DB 백업과 파일 백업의 기준 시각이 함께 관리되는가?
• versioning과 lifecycle 정책이 RPO/RTO와 맞는가?
• 삭제 배치에 dry-run과 승인 절차가 있는가?
• object key와 DB row를 비교하는 검증 절차가 있는가?
• 복구 후 접근 권한 검증이 포함되어 있는가?