Jellyfin을 실행한 채로 백업해야 할까요, 아니면 먼저 서비스를 중지해야 할까요?
스냅샷 방식이 서비스가 데이터를 기록하는 동안에도 애플리케이션 상태를 일관되게 캡처할 수 있는 경우가 아니라면, 간단하고 완전한 백업을 위해 Jellyfin을 중지하세요.
핵심적인 절충점은 서비스 중단과 일관성입니다. 중지된 서비스의 아카이브는 복사하는 동안 데이터베이스, 구성, 메타데이터의 변경이 멈추므로 이해하고 관리하기 쉽습니다. 데이터베이스 백업 메커니즘이나 파일 시스템 스냅샷이 특정 시점의 일관된 상태를 생성한다면 라이브 백업도 유효할 수 있지만, 서비스가 쓰기 작업을 수행하는 동안 일반적인 재귀 복사를 실행하는 방식은 신뢰하기 어렵습니다.
서비스 중지 복사는 간단하고 안전한 기본 방법입니다
Jellyfin을 잠시 중지하면 백업 도구가 구성 디렉터리 트리를 순회하는 동안 새로운 데이터베이스 및 메타데이터 쓰기가 발생하지 않습니다. 따라서 소규모 홈 서버에서 발생하는 많은 일관성 관련 문제를 없앨 수 있습니다.
라이브 파일 복사에서는 WAL에 기록된 트랜잭션을 놓칠 수 있습니다. 트랜잭션을 인식하는 SQLite 백업은 열려 있는 데이터베이스를 일반적인 정적 파일처럼 복사하는 문제를 피합니다.
사용량이 적은 시간대에 일시 중지 일정을 잡고, 프로세스가 중지되었는지 확인한 다음 영구 상태 데이터를 복사하고 서비스를 다시 시작하세요. 중단 시간을 측정해 실제 운영 비용을 파악하세요.
라이브 백업에는 일관된 스냅샷 메커니즘이 필요합니다
파일 시스템 스냅샷은 라이브 서비스가 이후에도 계속 실행되는 동안에도 특정 한순간의 여러 파일 상태를 고정할 수 있습니다. 이는 변경 중인 파일을 하나씩 천천히 복사하는 것과는 다릅니다.
백업 중에도 활성 데이터 세트는 변경되므로, 캡처에 시간이 걸릴 때는 변경량이 중요합니다.
ZFS, Btrfs 또는 데이터베이스 인식 백업을 사용한다면 어떤 일관성 보장을 제공하는지 문서화하세요. 테스트 없이 단순한 라이브 파일 복사가 동등한 방식이라고 간주하지 마세요.
백업 완료보다 데이터베이스 무결성이 중요합니다
백업 작업이 성공을 반환하더라도 캡처된 데이터베이스가 실제 복구 지점으로 사용할 수 없는 상태일 수 있습니다. 검증 과정에서는 데이터베이스와 애플리케이션 상태를 함께 검사해야 합니다.
신뢰할 수 있는 복구 세트는 쓰기 작업이 진행 중일 때 제어되지 않은 데이터베이스 복사를 피해야 합니다. SQLite 일관성은 일관된 데이터베이스 상태를 보존하는 데 달려 있습니다.
백업을 바로 신뢰하기 전에 일회성 테스트 경로에 복원하고 무결성 검사를 실행하세요. 영구 앱 데이터 레이아웃은 상태 데이터가 교체 가능한 컨테이너와 분리되어 있으므로 이 테스트를 더 쉽게 만들어 줍니다.
복구 목표에 따라 방법을 선택하세요
2분간의 유지 관리 시간을 감당할 수 있는 가정이라면 복잡한 라이브 백업 시스템을 도입해도 얻는 이점이 거의 없을 수 있습니다. 엄격한 가동 시간 목표가 있는 서버라면 스냅샷을 사용하는 것이 타당할 수 있지만, 복원이 계속 예측 가능할 때만 그렇습니다.
적절한 재해 복구 테스트는 선택한 백업이 실제로 서비스를 사용 가능한 상태로 되돌리는지 측정합니다.
백업 중단 시간, 복원 시간, 장애 발생 시 복잡성을 비교하세요. 가정의 복구 목표를 충족하고 실제 복원 리허설을 통과할 수 있는 가장 단순한 방법을 사용하세요.
추천 제품
지원 및 팁
더 읽어보기
잠금 충돌 없이 Restic 백업, Forget 및 Prune 작업을 예약하는 방법
빈번한 백업, 범위가 지정된 보존, 실제 정리, 검사, 재시도 및 복원 검증을 분리한 완전한 다중 호스트 Restic 일정입니다.
Restic 정리 작업이 예약된 백업을 차단하지 않도록 하는 방법
공유 Restic 저장소를 위한 예방 계획으로, 백업 기간과 정리 작업을 분리하면서 잠금, 재시도 및 알림을 그대로 유지합니다.
활성 백업을 중단하지 않고 오래된 Restic 잠금 해제하는 방법
활성 백업을 보호하고 오래된 상태만 제거하며 정상 일정에 따라 복구를 확인하는 최소 개입형 Restic 잠금 해제 워크플로입니다.
