Supabase DB 백업 복원 후 Storage 파일이 없는 이유
데이터베이스 백업을 복원했는데 이미지 파일이 없다면, 수파베이스의 데이터베이스와 스토리지 파일을 구분해야 합니다.
Postgres 상태와 Storage bytes를 구분Storage API 실제 object bytes는 DB backup 밖DB 상태 복원과 object binary 복구를 구분
데이터베이스 백업을 복원했는데 이미지 파일이 없다면, 수파베이스의 데이터베이스와 스토리지 파일을 구분해야 합니다.
증상부터 분리
데이터베이스 백업을 복원했는데 이미지 파일이 없다면, 수파베이스의 데이터베이스와 스토리지 파일을 구분해야 합니다.
공식 문서에서 확인되는 핵심
공식 문서상 데이터베이스 백업에는 스토리지 에이피아이로 저장한 실제 오브젝트 바이트가 들어가지 않고, 데이터베이스에는 그 메타데이터만 들어갑니다.
그래서 오래된 데이터베이스 백업이나 피아이티알을 복원해도, 그 뒤 삭제된 스토리지 오브젝트 자체가 되살아나는 것은 아닙니다.
다섯 장면으로 정리
| 장면 | 핵심 | 조건 |
|---|---|---|
| 1 | DB 백업 성공! 파일은 왜 없지?! | Postgres 상태와 Storage bytes를 구분 |
| 2 | DB backup 파일 metadata만 | Storage API 실제 object bytes는 DB backup 밖 |
| 3 | 오래된 backup·PITR 삭제 파일 복원 아님 | DB 상태 복원과 object binary 복구를 구분 |
| 4 | 새 프로젝트 복원도 Storage 별도 | Storage objects·bucket settings는 수동 재구성 항목 |
| 5 | metadata + 파일 bytes 따로 보호 | 실제 프로젝트 삭제·복원 시험 아님 |
여기까지는 단정하면 안 됩니다
새 프로젝트로 복원하는 기능도 데이터베이스 중심이며, 스토리지 오브젝트와 버킷 설정은 별도 재구성이 필요합니다.
설정 변경 전 읽기 전용 확인
- Postgres 상태와 Storage bytes를 구분
- Storage API 실제 object bytes는 DB backup 밖
- DB 상태 복원과 object binary 복구를 구분
- Storage objects·bucket settings는 수동 재구성 항목
- 실제 프로젝트 삭제·복원 시험 아님
검증 범위
복구 설계에서는 데이터베이스 메타데이터와 실제 파일 바이트를 따로 보호해야 합니다. 실제 프로젝트에서 파일을 지우거나 복원한 시험은 아닙니다.
이 글은 제조사 공식 문서를 해설하고 가상 도식을 사용한 교육 자료입니다. 실제 장비·운영 데이터베이스·고객 데이터·장애·복구·성능 시험 결과를 주장하지 않습니다.
- https://supabase.com/docs/guides/platform/backups
- https://supabase.com/docs/guides/platform/clone-project
짧은 영상으로 보기
YouTube 예약 영상의 실제 ID가 생기면 이 링크만 연결할 수 있습니다. 글과 로컬 영상 자체는 독립적으로 확인 가능합니다.