홈 NAS에서 실행 중인 데이터베이스 컨테이너를 일관성 있게 유지하는 백업 방법은 무엇인가요?

대부분의 홈 NAS 및 셀프 호스팅 서버 사용자에게 가장 안전한 기본값은 데이터베이스가 실행 중일 때 생성된 데이터베이스 네이티브 논리 백업이며, 그 덤프와 컨테이너 구성 및 애플리케이션 파일을 함께 일반 백업하는 것입니다. 다운타임이 허용될 때는 짧게 중지된 컨테이너 복사를 사용하고, 데이터베이스가 플러시, 잠금, 체크포인트 또는 스냅샷 준비가 된 경우에만 조정된 파일시스템 스냅샷을 사용하세요. 실행 중인 데이터베이스 볼륨의 단순 복사는 일관된 백업 방법이 아닙니다.

“일관성”을 데이터베이스가 수용하는 복원으로 정의하세요

일관된 백업은 단순히 완전한 폴더 트리가 아닙니다. 복원 후 데이터베이스 엔진은 시작하고, 트랜잭션을 올바르게 복구하며, 무결성 검사를 통과하고, 애플리케이션이 사용할 수 있는 시점 상태를 제공해야 합니다. Immich, Nextcloud, Paperless-ngx, Home Assistant 또는 다른 셀프 호스팅 앱을 실행하는 홈 서버에서는 데이터베이스, 업로드, 구성 및 비밀 정보가 서로 일치해야 합니다.

컨테이너 지속성은 파일이 어디에 저장되는지만 설명합니다. 실행 중인 데이터베이스를 안전하게 복사하지는 않습니다. 데이터베이스에는 활성 트랜잭션, 캐시된 페이지, 선행 기록 로그, 임시 파일 또는 NAS 백업 소프트웨어가 볼륨을 읽는 동안 변경되는 메타데이터가 있을 수 있습니다.

방법 1: 홈 NAS 기본값으로 데이터베이스 네이티브 논리 덤프 사용

논리 덤프는 데이터베이스 엔진에 스키마와 레코드의 일관된 표현을 내보내도록 요청합니다. 가족용 NAS에서 실행되는 적당한 PostgreSQL 또는 MariaDB 컨테이너의 경우, 이는 일반적으로 예약, 검사, 오프사이트 복사 및 깨끗한 교체 컨테이너로 복원하는 가장 쉬운 방법입니다. 최신 Docker 백업 가이드는 예약된 백업 컨테이너에서 데이터베이스 네이티브 덤프 실행을 통해 이 패턴을 보여줍니다.

덤프를 라이브 데이터 볼륨 외부의 전용 백업 디렉터리에 작성하세요. 그런 다음 NAS 백업 작업이 덤프, Compose 파일, 환경 템플릿, 애플리케이션 구성 및 업로드된 데이터를 보호하도록 하세요. 덤프 파일 이름이나 보호되지 않은 로그에 프로덕션 비밀번호를 노출하지 마세요.

방법 2: 데이터베이스 볼륨을 복사하기 전에 잠시 데이터베이스 중지하기

중지된 컨테이너 복사는 간단하고 물리적으로 완전합니다. 먼저 애플리케이션 쓰기 작업을 중지하고, 데이터베이스를 깨끗이 중지한 후 프로세스가 종료되었는지 확인하고, 전체 영구 볼륨 또는 바인드 마운트된 데이터베이스 디렉터리를 복사한 다음 스택을 재시작합니다. Docker와 MariaDB 가이드는 물리적 볼륨 복사를 빠르지만 버전 의존적이며 일반적으로 다운타임과 연관된다고 설명합니다.

이 방법은 몇 분간의 유지보수가 허용되고 복원 시 호환되는 데이터베이스 버전을 사용하는 작은 홈 NAS에 적합합니다. 논리적 덤프보다 이식성이 떨어지고, 볼륨이 클 경우 다운타임이 길어질 수 있습니다. 백업 시 데이터베이스 이미지 태그와 저장소 레이아웃을 함께 보관하여 물리적 파일을 호환되지 않는 엔진 버전에 복원하지 않도록 하십시오.

방법 3: 데이터베이스와 빠른 스냅샷 조율하기

ZFS, Btrfs, LVM, NAS 스냅샷 시스템은 대용량 데이터베이스 볼륨을 빠르게 캡처할 수 있지만, 스냅샷은 데이터베이스와 조율되어야 합니다. MariaDB나 MySQL의 경우 짧은 잠금 또는 플러시 창이 필요할 수 있고, PostgreSQL은 데이터베이스가 지원하는 백업 또는 체크포인트 프로세스가 필요할 수 있으며, 애플리케이션 관리 데이터베이스는 스냅샷 전 훅이 필요할 수 있습니다.

데이터베이스 스냅샷 논의에서는 데이터베이스가 정지되거나 스냅샷이 원자적으로 찍히지 않으면 라이브 디스크 복사본이 내부적으로 일관되지 않을 수 있다고 설명합니다. 잠금 또는 정지 간격은 짧아야 하며, 데이터베이스를 준비하고 스냅샷을 생성한 후 쓰기를 해제하고 나중에 스냅샷을 복사해야 합니다.

이 방법은 데이터베이스가 너무 커서 자주 논리적 덤프를 할 수 없거나 더 짧은 복구 지점 간격이 필요할 때 유용합니다. 기본 홈 서버 덤프 작업보다 더 신중한 스크립팅과 복원 테스트가 필요합니다.

Docker 이미지나 컨테이너 내보내기를 데이터베이스 백업으로 간주하지 마십시오

컨테이너 이미지는 애플리케이션 런타임을 포함하며, 반드시 실시간 영구 데이터를 포함하지는 않습니다. 컨테이너를 내보내거나 커밋할 때는 명명된 볼륨이 생략될 수 있으며, 데이터베이스에 일관된 복구 지점을 생성하도록 요청하지 않습니다. PostgreSQL 컨테이너 백업 계정은 Docker save와 commit이 PostgreSQL 전용 백업 기법을 대체하지 못한다고 결론지었습니다.

ZimaOS 또는 Docker 홈 서버의 경우 배포 정의와 데이터 보호 계획을 분리하세요: Compose 파일과 이미지 태그를 보존하여 서비스를 재구성할 수 있게 하고, 데이터베이스는 데이터베이스 일관성 방법으로 보존하여 상태를 복원할 수 있게 하세요.

활성으로 쓰이는 데이터베이스 볼륨을 평범하게 복사하지 마세요

NAS 백업 소프트웨어는 서로 다른 시점에 서로 다른 데이터베이스 파일을 읽을 수 있습니다. 결과 아카이브는 한 트랜잭션 상태의 데이터 파일, 다른 상태의 로그, 또 다른 상태의 메타데이터를 포함할 수 있습니다. 오픈소스 SQL 백업 방법 개요는 중요한 상태가 메모리에 남아 있는 동안 데이터베이스가 일관성 없는 순간에 캡처될 수 있음을 경고합니다.

충돌 복구는 일부 원자적 스냅샷을 복구할 수 있지만 일반적인 재귀적 파일 복사는 원자적이지 않습니다. 앱이 다운타임을 허용하지 않는다면 논리적 덤프, 지원되는 물리적 백업 도구 또는 조정된 스냅샷을 사용하세요.

SQLite 컨테이너를 일반 파일이 아닌 데이터베이스로 취급하세요

많은 홈 서버 앱이 SQLite를 사용하는 이유는 작고 배포가 쉽기 때문입니다. 위험은 관리자가 .db 파일 하나만 보고 앱이 쓰는 동안 복사해도 된다고 착각하는 것입니다. WAL 모드에서는 최근 커밋된 변경 사항이 메인 파일 밖에 있을 수 있습니다. 실용적인 SQLite 복구 문서는 라이브 데이터베이스 파일 복사 대신 온라인 백업 메커니즘이나 정상 종료 후 복사를 권장합니다.

애플리케이션에 내장된 백업 기능이 있으면 사용하세요. 그렇지 않으면 SQLite 자체 온라인 백업 기능을 사용하거나 애플리케이션을 정상 종료한 후 전체 데이터베이스 디렉터리를 복사하세요. 저널이나 WAL 상태를 남겨두고 메인 데이터베이스 파일만 복사하지 마세요.

다운타임, 데이터베이스 크기 및 복원 이식성에 따라 방법 선택

데이터베이스뿐만 아니라 전체 셀프 호스팅 애플리케이션을 백업하세요

사용 가능한 복구 패키지에는 데이터베이스 백업, Docker Compose 파일, 이미지 버전, 환경 변수 또는 복구 가능한 비밀 패키지, 리버스 프록시 설정, 애플리케이션 구성, 업로드된 파일, 그리고 모든 암호화 키가 포함되어야 합니다. SQL 덤프만 백업하면 기록은 복원되지만 앱이 사진, 문서, 썸네일, 인증서 또는 스토리지 경로를 찾지 못할 수 있습니다.

홈 서버 복구 계획을 위해 ZimaSpace의 바인드 마운트 및 명명된 볼륨 가이드는 가시적인 스토리지 경로가 복구에 도움이 되지만 애플리케이션 일관성 데이터베이스 백업을 대체하지 못하는 이유를 설명합니다.

새 컨테이너에 복원하여 방법을 검증하세요

새 프로젝트 이름, 다른 호스트 포트, 임시 데이터 디렉터리를 사용해 격리된 테스트 스택을 만드세요. 덤프나 스냅샷을 복원하고 데이터베이스를 시작한 후 무결성 또는 일관성 검사를 실행하고, 테스트용 애플리케이션 복사본에 연결하세요. 사용자, 기록, 첨부 파일, 최근 거래가 모두 있는지 확인하세요.

복구 시점과 복구 시간을 모두 측정하세요. 논리 덤프가 일관성이 있지만 복원하는 데 너무 오래 걸리면 휴대 가능한 복구 계층으로 유지하고 더 빠른 조정된 스냅샷을 추가하세요. 정지된 볼륨 복사가 빠르게 복원되지만 동일한 데이터베이스 버전으로만 복원된다면, 마이그레이션 대비책으로 논리 덤프를 보관하세요.

자주 묻는 질문

볼륨 복사 전에 데이터베이스 컨테이너를 일시 중지하는 것만으로 충분한가요?

일반적인 규칙으로는 아닙니다. 일시 중지는 프로세스를 멈추지만 데이터베이스가 휴대 가능한 백업을 위해 올바른 상태를 플러시했음을 증명하지 않습니다. 데이터베이스 고유 덤프, 정상 종료, 또는 문서화된 정지 및 스냅샷 절차를 사용하세요.

PostgreSQL 또는 MariaDB에 NAS 스냅샷만으로 충분한가요?

스냅샷이 원자적이고 데이터베이스가 지원하는 일관성 프로세스와 조정된 경우에만 가능합니다. 조정되지 않은 스냅샷은 단순히 충돌 일관성만 보장할 수 있으며, 원자적이지 않은 파일 복사는 더 나쁠 수 있습니다.

SQLite 기반 홈 서버 앱에서 무엇을 백업해야 하나요?

가능할 경우 앱의 내보내기 또는 SQLite 온라인 백업을 사용하세요. 또한 앱 구성, Compose 파일, 비밀 정보, 첨부 파일, 그리고 데이터베이스가 포함된 디렉터리를 보존하세요. 메인 파일만 가정하지 마세요. .db 파일은 전체 애플리케이션입니다.

최종 권장 사항

대부분의 PostgreSQL 및 MariaDB 컨테이너에 대해 홈 NAS에서 기본값으로 예약된 논리 덤프를 사용하세요. 짧은 다운타임이 허용될 때는 정지된 볼륨의 깨끗한 복사본을 사용하고, 데이터베이스가 크거나 복구 시점 창이 좁을 때는 조정된 스냅샷이나 데이터베이스 고유의 물리적 도구를 사용하세요. 어떤 방법을 선택하든 신뢰하기 전에 새 컨테이너에 복원하세요.