Immich 백업·복구 가이드: 3-2-1 전략과 PostgreSQL 복원 절차 (Proxmox/N100)

이 글은 Immich를 운영할 때 가장 중요한 “백업·복구”를 3-2-1 전략 관점에서 정리하고, Proxmox/N100 환경에서 실제로 복원까지 성공시키는 절차를 단계별로 설명한다. 사진/영상은 한 번 꼬이면 복구 비용이 커서, 설치보다 복구 가능성을 먼저 확보하는 것이 핵심이다.

이 글의 목표(성공 기준)

Immich 데이터(업로드 파일)와 DB(PostgreSQL)를 분리해서 백업한다.
백업에서 새 환경으로 복원하고, 로그인/앨범/검색이 정상 동작함을 확인한다.
Proxmox 환경에서는 “스냅샷/백업”과 “애플리케이션 레벨 백업”을 조합해 운영 루틴을 만든다.

Immich 백업 관련 공식 서비스 화면 — 출처: Immich 공식 홈페이지 (https://immich.app/)

Immich를 셀프호스팅으로 운영하다 보면 처음에는 성능과 기능에 눈이 가지만, 시간이 지나면 결국 가장 중요한 주제는 백업과 복구라는 사실을 체감하게 됩니다. 저도 실제 운영 중에 디스크 상태가 불안정해지거나, 컨테이너 업데이트 과정에서 설정이 꼬이는 상황을 겪으면서 “백업 파일이 있느냐”보다 “정확히 복구할 수 있느냐”가 훨씬 중요하다는 걸 배웠습니다. 이 글은 그런 경험을 바탕으로, 초보자도 그대로 따라 할 수 있도록 Immich 백업/복구 절차를 단계별로 설명한 실전 튜토리얼입니다.

이 문서의 목표는 단순합니다. 백업은 자동차의 에어백처럼 평소엔 존재감이 없지만, 사고 순간에 체감 가치가 폭발합니다 😅. 그래서 “나중에 해야지”를 미루면, 장애가 터진 날에는 농담이 아니라 진짜 식은땀이 납니다. 첫째, 원본 사진/영상과 데이터베이스를 함께 보호하는 구조를 만든다. 둘째, 자동화해 매일 같은 품질로 백업을 쌓는다. 셋째, 장애가 났을 때 실제로 복구가 되는지 검증한다. 이 세 가지가 갖춰지면 홈랩 운영 안정성은 확실히 올라갑니다.

Immich 백업에서 가장 먼저 이해해야 할 구조

Immich는 크게 두 종류의 데이터를 사용합니다. 하나는 사진/영상 원본 파일이고, 다른 하나는 PostgreSQL 데이터베이스입니다. 원본 파일에는 실제 미디어가 있고, 데이터베이스에는 앨범 연결 정보, 사용자 자산 관계, 검색/탐색 관련 정보가 저장됩니다. 그래서 파일만 백업하거나 DB만 백업하면 복구 후에 일부 기능이 깨질 수 있습니다. 반드시 파일과 DB를 세트로 다뤄야 합니다.

실무 관점에서 이 부분을 이해하면 백업 설계를 훨씬 쉽게 할 수 있습니다. 예를 들어 “사진 파일은 살아 있는데 앨범이 비정상적으로 보인다” 같은 문제는 대부분 DB 복원 절차가 누락되었거나 시점이 맞지 않아 생깁니다. 반대로 DB는 복원했는데 실제 파일 경로가 달라져 썸네일/미리보기가 깨지는 경우도 있습니다. 즉, 백업은 개별 명령어보다 전체 흐름이 중요합니다.

3-2-1 전략을 Immich 운영에 적용하는 방법

원본 1개: 현재 운영 중인 Immich 스토리지
백업 사본 1개: 로컬 NAS 또는 별도 디스크
백업 사본 1개: 원격지(오프사이트) 서버

여기서 핵심은 “다른 위치”입니다. 같은 장비 안에 백업 파일만 여러 개 둬도 장비 자체가 문제를 일으키면 함께 손실될 수 있습니다. 물리적으로 분리된 원격 백업 1개는 반드시 확보하세요.

백업 방식 비교 표 (초보자 기준)

방식	장점	주의점	추천 상황
DB 덤프 + 파일 rsync	구조가 단순하고 복구 절차가 명확함	시점 관리(파일/DB) 필요	개인 홈랩, 처음 구축
스토리지 스냅샷 단독	복구 속도가 빠름	논리 손상/버전 이슈 대응 약함	보조 수단으로 활용
DB 덤프 + 파일 rsync + 오프사이트	장애 모드 분산, 데이터 생존성 높음	초기 설정/점검 항목이 많음	장기 운영, 가족 사진 보관

처음에는 가장 단순한 조합부터 시작하세요. 백업은 멋진 도구보다 “매일 돌아가는 루틴”이 훨씬 강합니다 🔧.

Immich 백업 아키텍처 참고 화면 — 출처: Immich 공식 홈페이지

사전 준비: 반드시 기록해야 하는 값

UPLOAD_LOCATION 실제 경로
PostgreSQL 컨테이너 이름
DB 사용자/접속 정보
백업 로컬 경로
원격 백업 경로와 SSH 계정
현재 Immich 버전과 compose 파일 위치

초보자분들이 가장 많이 막히는 구간이 이 “기본 정보 미기록”입니다. 평소에는 당연히 알던 경로도 장애 상황에서는 헷갈립니다. 백업 스크립트 상단에 변수로 정리해 두고, 운영 문서에도 동일하게 기록해 두는 습관이 중요합니다.

1단계: PostgreSQL 백업(매일 수행)

이 단계의 목적은 Immich 메타데이터를 안전하게 보관하는 것입니다. 아래 명령은 PostgreSQL 전체 덤프를 생성한 뒤 gzip으로 압축해 저장합니다. 날짜/시간을 파일명에 포함해 복구 지점을 쉽게 고를 수 있게 구성했습니다.

mkdir -p /opt/immich-backup/db
NOW=$(date +%F-%H%M)

docker exec -t immich_postgres pg_dumpall -U postgres   > /opt/immich-backup/db/immich-db-$NOW.sql

gzip -9 /opt/immich-backup/db/immich-db-$NOW.sql
ls -lh /opt/immich-backup/db | tail -n 5

명령 설명을 짧게 정리하면, pg_dumpall은 데이터베이스 전체 내용을 SQL 형태로 내보내고, gzip -9는 용량을 줄여 저장 효율을 높입니다. 마지막 ls는 백업 파일이 정상 생성됐는지 즉시 확인하는 단계입니다. 이 확인 단계를 빼먹지 마세요.

2단계: 원본 파일 백업(rsync 증분)

이 단계의 역할은 실제 사진/영상 원본을 안전하게 복제하는 것입니다. 처음 한 번은 시간이 오래 걸리지만, 이후에는 변경된 파일만 동기화돼 훨씬 빨라집니다. 초보자라면 초기에는 삭제 전파 옵션(--delete)을 끄고 시작하는 편이 안전합니다.

UPLOAD_SRC=/data/immich/upload/
UPLOAD_DST=/backup/local/immich-upload/
mkdir -p "$UPLOAD_DST"

rsync -avh --info=progress2 "$UPLOAD_SRC" "$UPLOAD_DST"

이 명령에서 -a는 권한/시간 정보까지 보존해 복구 품질을 높이고, -v는 로그 확인을 쉽게 하며, -h는 용량 표시를 읽기 좋게 바꿉니다. 운영이 안정된 뒤에는 보존정책을 갖춘 상태에서 --delete를 검토하세요.

3단계: 원격지(오프사이트) 복제

로컬 백업만으로는 화재, 장비 고장, 전원 사고 같은 상황을 완전히 막기 어렵습니다. 그래서 주기적으로 원격 서버로 복제해야 합니다. 아래는 rsync 기반의 단순하고 안정적인 예시입니다.

REMOTE=user@remote-host
REMOTE_BASE=/backup/immich

rsync -avh /backup/local/immich-upload/ $REMOTE:$REMOTE_BASE/upload/
rsync -avh /opt/immich-backup/db/       $REMOTE:$REMOTE_BASE/db/

여기서 중요한 건 전송 성공 여부를 로그로 남기는 것입니다. 자동화 작업은 실패해도 조용히 지나갈 수 있어, 실패 알림이 없으면 실제로는 백업이 멈춘 상태를 몇 주 뒤에 발견하는 일이 생깁니다.

4단계: 자동화 스크립트로 매일 반복

백업은 사람이 기억해서 하는 작업이 되면 반드시 누락됩니다. 그래서 스크립트와 크론 작업으로 고정 루틴을 만드는 것이 핵심입니다. 아래 예시는 DB 덤프 + 파일 동기화 + 오래된 백업 정리를 한 번에 수행합니다.

#!/usr/bin/env bash
set -euo pipefail

NOW=$(date +%F-%H%M)
DB_DIR=/opt/immich-backup/db
UPLOAD_SRC=/data/immich/upload/
UPLOAD_DST=/backup/local/immich-upload/
LOG=/var/log/immich-backup.log

mkdir -p "$DB_DIR" "$UPLOAD_DST"
echo "[$(date)] backup start" >> "$LOG"

docker exec -t immich_postgres pg_dumpall -U postgres > "$DB_DIR/immich-db-$NOW.sql"
gzip -9 "$DB_DIR/immich-db-$NOW.sql"

rsync -avh --delete "$UPLOAD_SRC" "$UPLOAD_DST" >> "$LOG" 2>&1
find "$DB_DIR" -type f -name '*.gz' -mtime +14 -delete

echo "[$(date)] backup done" >> "$LOG"

0 3 * * * /usr/local/bin/immich-backup.sh

위 크론 예시는 매일 새벽 3시에 실행됩니다. 서버 부하가 적은 시간을 선택하는 것이 좋고, 백업 소요 시간이 길면 시작 시간을 더 앞당겨도 됩니다.

공식 복구 절차 원문은 Immich 문서 링크에서 바로 확인하세요: Immich Backup and Restore. 텍스트 위주 문서는 저해상도 캡처보다 원문 링크가 더 선명하고 최신 상태를 유지합니다.

5단계: 복구 절차(가장 중요한 단계)

백업이 잘 되는지 확인하는 유일한 방법은 실제 복구 테스트입니다. 최소 월 1회는 테스트 환경에서 복구 리허설을 실행하세요. 순서는 다음과 같습니다.

Immich 서비스 정지
원본 파일 백업본 복원
DB 덤프를 PostgreSQL에 복원
서비스 재기동
로그인/앨범/검색/모바일 동기화 확인

zcat /opt/immich-backup/db/immich-db-2026-02-14-0300.sql.gz |   docker exec -i immich_postgres psql -U postgres

docker compose up -d

여기서 초보자분들이 자주 놓치는 검증 항목은 “앱이 켜지는지”만 보는 것입니다. 반드시 실제 사진 열람, 최근 업로드, 앨범 연결, 검색 결과, 모바일 동기화까지 확인해야 합니다. 이 확인이 끝나야 복구 성공입니다.

운영 중 자주 발생하는 문제와 해결 팁

문제 1: 백업 파일은 있는데 복구가 실패함
대부분 덤프 시점과 파일 시점이 맞지 않거나, 권한 문제가 원인입니다. 백업 시점 로그를 남기고, 복원 후 파일 권한을 함께 점검하세요.

문제 2: rsync 속도가 너무 느림
초기 전체 동기화는 원래 오래 걸립니다. 첫 작업 이후부터는 증분 전송으로 속도가 크게 개선됩니다. 네트워크 병목이 있으면 야간 시간대로 옮기세요.

문제 3: 원격 백업은 있는데 신뢰가 안 됨
주기적으로 원격 저장소에서 임의 파일을 복원해 열어 보세요. “저장됨”과 “복원됨”은 다릅니다.

문제 4: 업데이트 후 동작 이상
업데이트 전후로 백업 지점을 명확히 분리해 두면 롤백 판단이 빠릅니다. 운영 노트에 버전과 작업 시간을 함께 기록하세요.

초보자를 위한 운영 루틴 제안

매일: DB 덤프 + 파일 증분 백업
매주: 원격지 복제 상태 점검
매월: 복구 리허설 1회
업데이트 전: 수동 백업 + 변경 기록
장애 발생 시: 절차대로 복구 후 원인 기록

이 루틴만 지켜도 데이터 안정성이 눈에 띄게 올라갑니다. 홈랩 운영에서 중요한 것은 화려한 도구보다 반복 가능한 절차입니다.

홈랩 기반 구성 자체가 아직 낯설다면 Proxmox 기반 구축 글을 먼저 보고 오시면 전체 흐름을 이해하는 데 도움이 됩니다.

FAQ

Q1. Immich는 스냅샷만으로 백업해도 되나요?

가능하지만 권장하지 않습니다. 스냅샷은 빠른 복원에 유리하지만, 논리 백업(SQL 덤프)을 함께 보관해야 버전 이슈와 데이터 무결성 문제 대응이 쉽습니다.

Q2. DB 백업 주기는 하루 1회면 충분한가요?

개인 홈랩 기준으로는 하루 1회가 보통의 출발점입니다. 업로드 빈도가 높다면 12시간 또는 6시간 단위로 조정해도 좋습니다.

Q3. 원격 백업은 어떤 방식이 좋나요?

처음에는 rsync가 가장 단순합니다. 백업 세대 관리와 중복 제거가 필요하면 Borg 기반 구성으로 확장하세요.

Q4. 복구 테스트는 얼마나 자주 해야 하나요?

최소 월 1회 권장합니다. 운영 변경이 많았던 달에는 횟수를 늘리는 게 좋습니다.

참고 문서

이 가이드를 따라 했을 때 기대 효과

이 글의 절차를 그대로 적용하면 백업 실패를 늦게 발견하는 리스크를 크게 줄일 수 있습니다. 파일과 DB를 함께 관리하는 습관이 생기고, 복구 리허설을 통해 실제 장애 상황에서도 당황하지 않고 순서대로 대응할 수 있습니다.

또한 자동화 스크립트와 체크리스트를 갖추면 운영 품질이 사람 컨디션에 덜 흔들립니다. 결과적으로 복구 시간 단축, 데이터 손실 확률 감소, 운영 안정성 향상이라는 세 가지 효과를 기대할 수 있습니다. 홈랩 규모에서도 충분히 실현 가능한 방법이니, 오늘 한 단계만 먼저 적용해 보셔도 체감이 큽니다 🚀

운영 관점의 기대 효과 1: 예측 가능한 복구
Immich 백업 루틴을 적용하면 가장 큰 변화는 “불안 감소”입니다. 장애가 났을 때 감으로 대응하지 않고, 이미 정리된 절차대로 Immich 복구를 실행할 수 있기 때문입니다. 특히 Immich 백업 파일과 데이터베이스 덤프의 시점을 맞춰 관리하면 복원 직후 무결성 검증도 훨씬 수월합니다. 즉, Immich 백업은 단순 보관이 아니라, 복구 성공 확률을 높이는 운영 습관입니다.

운영 관점의 기대 효과 2: 장애 대응 시간 단축
평소에 Immich 백업 자동화를 걸어 두면 장애 발생 시 “무엇부터 해야 하지?”라는 공백 시간이 줄어듭니다. 복구 체크리스트를 통해 DB 복원, 파일 마운트 확인, 서비스 재기동, 샘플 검증까지 한 번에 진행할 수 있어 전체 다운타임이 짧아집니다. 홈랩에서는 한 번의 장애가 며칠치 사진 정리에 영향을 줄 수 있는데, Immich 복구 절차를 미리 연습해 두면 이런 2차 불편을 크게 줄일 수 있습니다.

운영 관점의 기대 효과 3: 장기 안정성
Immich 백업 체계를 갖추면 데이터가 쌓일수록 운영이 더 안정됩니다. 초기에는 단순 rsync와 PostgreSQL 덤프만으로도 충분하고, 익숙해지면 원격 오프사이트 복제까지 확장할 수 있습니다. 이렇게 단계적으로 성장하는 방식은 초보자에게 특히 유리합니다. 복잡한 도구를 한 번에 도입하는 것보다, 작게 시작해 꾸준히 반복하는 Immich 백업 방식이 실제 성공률이 높습니다. 결론적으로 이 가이드를 따라 하면 Immich 백업 품질 향상, Immich 복구 신뢰도 개선, 서비스 운영 안정성 강화를 현실적으로 기대할 수 있습니다 ✅

마지막으로, 이 가이드는 “한 번 읽고 끝”이 아니라 운영 체크리스트로 활용할 때 가치가 커집니다. 주간 점검 때 Immich 백업 성공 로그, 파일 개수, DB 덤프 크기를 확인하고 월 1회 Immich 복구 리허설을 실행해 보세요. 이 루틴을 유지하면 Immich 백업의 신뢰도가 올라가고, 실제 장애 시 Immich 복구 절차를 빠르게 재현할 수 있습니다. 결국 핵심은 복잡한 기술보다 반복 가능한 습관입니다. 오늘 한 번의 Immich 백업 점검이 내일의 복구 시간을 줄여 줍니다.

짧은 요약: Immich 백업은 파일+DB를 함께 지키는 절차이고, Immich 복구는 그 절차가 실제로 동작하는지 검증하는 과정입니다. 정기적인 Immich 백업과 반복적인 Immich 복구 연습을 병행하면 운영 안정성이 눈에 띄게 좋아집니다.

함께 보면 좋은 글

아래 글을 함께 보면 설치부터 운영까지 흐름을 더 빠르게 잡을 수 있습니다.

FAQ: Immich 후기 관련 질문

Q. 실제로 써본 Immich 후기는 어떤가요?
초기 구축 난이도는 있지만, 한 번 안정화하면 사진 백업/검색/앨범 관리가 매우 편해집니다. 다만 운영 품질은 백업·복구 루틴을 갖췄는지에 따라 크게 갈립니다.