데이터베이스 볼륨이 가득 찬 후 Immich를 복구하는 방법

Immich 데이터베이스 볼륨이 가득 차면 새로운 Immich 쓰기를 중지하고 PostgreSQL 데이터 디렉터리를 보존한 다음, 복구를 시도하기 전에 안전한 작업 공간을 확보하세요. 파일이 크다는 이유만으로 pg_wal 또는 다른 PostgreSQL 내부 파일을 삭제하지 마세요.

데이터베이스 파일 시스템이 가득 차면 체크포인트 또는 크래시 복구가 중단될 수 있으므로, 사진 애플리케이션 자체가 정상적으로 보인 후에도 반복적인 재시작이 계속 실패할 수 있습니다. 먼저 PostgreSQL 데이터, Docker 루트 저장소, 공유 메모리 또는 다른 마운트 중 어느 파일 시스템이 가득 찼는지 확인한 다음, 롤백에 필요할 수 있는 증거를 훼손하지 않고 해당 계층을 복구하세요.

어느 파일 시스템이 가득 찼는지 확인하고 추가 쓰기를 중지하세요

PostgreSQL 마운트, Docker 데이터 루트, 호스트 루트 파일 시스템 및 오류에 언급된 tmpfs/공유 메모리 경로의 바이트와 inode 여유 공간을 확인하세요. 타임스탬프를 PostgreSQL 로그와 대조하세요. pg_wal에서 “장치에 남은 공간이 없습니다”라는 메시지가 표시되는 경우는 이미지 캐시 또는 썸네일 파티션이 가득 찬 경우와 다릅니다.

Immich 데이터베이스 복구 토론에서는 저장 공간이 가득 차 임시 WAL 파일을 쓸 수 없어서 PostgreSQL이 복구를 중단한 사례를 보여 줍니다. 오래되었고 배포 환경에 따라 다른 사례이지만, 파일 권한을 변경하거나 스택을 재시작하는 것만으로는 용량 문제를 해결할 수 없는 이유를 보여 줍니다.

업로드와 백그라운드 작업을 일시 중지한 다음, 새로운 데이터베이스 작업을 생성하는 애플리케이션 구성 요소를 중지하세요. 최초 실패 로그 구간과 마운트 구성을 보존하세요. 가득 찬 파일 시스템이 실제로 PostgreSQL 데이터 파일 시스템이 아니라면 데이터베이스를 불필요하게 이동하지 말고 실제 위치를 복구하세요.

공간을 확보하기 전에 PostgreSQL 상태를 보존하세요

PostgreSQL이 중지된 상태에서 저장 공간과 도구가 허용한다면 데이터베이스 데이터 디렉터리의 파일 시스템 스냅샷 또는 전체 복사본을 생성하세요. WAL 디렉터리와 기본값이 아닌 테이블스페이스도 하나의 상태로 함께 포함하세요. 이 안전 복사본이 있으면 다음 복구 시도로 상황이 악화될 경우 장애 발생 시점으로 돌아갈 수 있습니다.

PostgreSQL 디스크 부족 복구 가이드는 핵심 원칙을 명확히 설명합니다. WAL은 일반적인 로그 찌꺼기가 아니라 데이터베이스 일관성의 일부이므로 수동으로 삭제하면 데이터베이스가 손상될 수 있습니다. 대신 볼륨을 확장하거나 이동하거나, 관련 없는 안전한 데이터를 삭제하여 용량을 확보하세요. 현재 상태를 복구할 수 없다고 판단하고 해당 백업 이후의 변경 사항을 잃는 것을 받아들이기로 결정한 경우가 아니라면, 실패한 데이터베이스를 마지막 백업으로 즉시 덮어쓰지 마세요. 공간이 가득 찬 인스턴스를 보존하면 롤백 지점과 용량이 부족해진 원인을 확인할 수 있는 증거를 모두 확보할 수 있습니다.

먼저 PostgreSQL을 복구한 다음 Immich 복구가 필요한지 판단하세요

충분한 공간이 확보되면 PostgreSQL만 실행하거나 필요한 최소한의 스택과 함께 실행하고 복구 로그를 확인하세요. 정상적인 시작, 성공적인 상태 확인, 정상적인 읽기 액세스가 “실행 중”이라는 컨테이너 상태보다 더 강력한 신호입니다. 데이터베이스가 안정적으로 작동할 수 있게 되는 즉시 새로운 데이터베이스 네이티브 백업을 생성하세요.

ZimaSpace의 Immich 데이터베이스 유지 관리와 교체 안내는 다음 판단 기준을 제공합니다. 일반적인 크기 또는 성능 문제만으로는 재구축을 실행해서는 안 되며, 반복적으로 재현되는 무결성 또는 복구 실패가 있을 때 검증된 데이터베이스 복사본의 복원을 고려할 수 있습니다.

PostgreSQL이 계속 정상 상태를 유지하는 것을 확인한 후에만 Immich를 시작하세요.

사용자, 타임라인, 여러 원본 파일, 앨범, 검색 기능 및 통제된 새 업로드 하나를 확인하세요. 데이터베이스는 시작되지만 애플리케이션 쿼리가 지속적으로 실패한다면 새 로그를 보존하고, 이제 문제가 여유 공간이 아니라 스키마/버전 호환성 또는 데이터 무결성에 있는지 확인하세요.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

증가 원인을 해결하고 시스템이 다시 안전하게 채워질 수 있음을 확인하세요

어떤 부분이 증가했는지 측정하세요. 일반 데이터베이스 테이블, WAL 보존 데이터, 같은 볼륨에 저장된 백업, 로그, Docker 레이어 또는 예상하지 못한 경로인지 확인합니다. 장애가 아카이브/복제 작업 실패나 다른 서비스가 데이터베이스 볼륨에 파일을 쓴 것에서 비롯되었다면, 단순히 용량만 늘리지 말고 원인을 해결하세요.

볼륨이 PostgreSQL의 체크포인트 또는 복구를 방해하는 수준에 도달하기 훨씬 전에 알림을 설정하세요. 백분율과 절대 여유 공간을 모두 모니터링하세요. 대용량 볼륨은 여유 비율이 낮아도 작업 공간이 충분할 수 있지만, 작은 데이터베이스 볼륨은 빠르게 위험해질 수 있습니다. 데이터베이스 백업은 보호 대상과 동일한 장애 경계 외부에 보관하세요.

마지막으로 일반적인 업로드와 백그라운드 처리 주기를 다시 수행하고, 새로운 데이터베이스 백업을 생성한 다음, 스택을 재시작하고 호스트를 재부팅하세요. 여유 공간 감소가 안정적이고, WAL/복구 오류가 없으며, 기존 및 새 자산을 읽을 수 있고, 쓰기가 다시 실패하기 전에 조치를 실행하는 문서화된 기준값이 있다면 검증을 통과한 것입니다.