Plexアプリデータを通常のファイルレベルでバックアップする場合は、まずPlexを停止するか、書き込みを一時停止できる状態にします。稼働中のコピーが適切なのは、実行中のデータベースを一貫性のある状態で取得できるよう設計されたバックアップ方式を使い、Plexの残りの状態も互換性のあるセマンティクスで保護できる場合に限られます。
本当の選択肢は「ダウンタイムがあるか、ないか」ではありません。「シンプルで一貫性のあるコピー」か、「アクティブなデータベースへの書き込みを理解するライブ方式」かです。ライブ方式がPlexデータベースを特定時点の有効な状態として保持できる仕組みを説明できないなら、開いているファイルのコピーが安全だと思い込まず、短時間の停止をスケジュールしてバックアップを検証してください。
ダウンタイムを決める前にバックアップ方式を選ぶ
まず、使用するバックアップの基本方式を明確にします。tar、rsync、SMBコピー、クラウド同期クライアント、アクティブなファイルの汎用スナップショットは、データベース対応のバックアップコマンドとは異なる動作をします。安全な運用状態は、コピーコマンドが正常に完了したかどうかではなく、そのツールが何を保証できるかによって決まります。
Plexのアプリデータには、サーバーの実行中に変更されるデータベース、メタデータ、設定が含まれます。Plexのバックアップ概要では、Plexデータディレクトリにメタデータとデータベースが含まれると説明されているため、サーバーの保護はメディアファイル自体を保存するだけでは不十分です。
この判断では、通常のファイルシステムコピーを保守的なケース、アプリケーション対応のデータベースバックアップを別の手法として扱ってください。コピー先に期待どおりの名前とサイズのファイルが届いたからといって、ライブコピーを安全だと判断しないでください。
通常のファイルレベルのアプリデータコピーではPlexを停止する
バックアップジョブがPlexのアプリデータディレクトリを単純にコピーするだけなら、最も安全なデフォルトは、コピー中だけPlexサービスまたはコンテナを停止することです。これにより、データベースや関連する状態を取得している間にアプリケーションが同時に書き込むことを防げます。
Plexコミュニティの議論では、長年活動している技術貢献者が、通常の稼働中ファイルコピーでは一貫性のないデータベースが取得される可能性があると警告し、静的なメタデータファイルと開いているデータベースを区別しています。バックアップツールにデータベースの一貫性を保つ仕組みがない場合は、Plexの書き込みを一時停止するべきだという強い根拠になります。
停止時間は実用上可能な限り短くします。重要なスキャンや録画が進行中でないことを確認し、Plexを停止して、準備済みのコピーを実行し、ジョブが完了したことを確認してから、Plexを再起動します。事前に確認できた保存先の権限や空き容量の問題を、ダウンタイム中に初めて発見することは避けてください。
データベース方式が対応している場合にのみライブバックアップを使う
Plexを停止することは、SQLite自体の決まりではありません。通常のアプリケーションアクセスを継続しながら一貫性のあるデータベーススナップショットを作成する、SQLite対応の機能を使う場合は、ライブバックアップが有効になることがあります。
SQLiteの本番バックアップに関するレビューでは、SQLiteバックアップAPIを使えば、ほかの接続が書き込みを続けている間も稼働中のデータベースをコピーできると説明されています。バックアップは、変化し続けるファイルを盲目的にコピーしたものではなく、定義されたデータベース状態を表します。
ただし、この例外が対象とするのは、アプリケーション対応方式が実際に保護する範囲だけです。データベースにはライブSQLiteバックアップを使い、メタデータや設定は別途コピーする場合は、それらの構成要素が時系列上どのように整合するのかを文書化し、復元をテストしてください。組み合わせたバックアップから期待するサーバー状態を再現できないなら、高可用性に意味はありません。
データベースファイル以外もバックアップする
データベースだけのバックアップでも重要なライブラリ情報は保持できますが、Plexを完全に復旧するには、メタデータ、設定、プラグインデータ、証明書、プラットフォーム固有の設定なども必要になる場合があります。最も簡単なファイルだけをバックアップするのではなく、元のホストが失われた場合に何が必要になるかを判断してください。
メディアファイルの保護は、容量に関する別の判断として扱います。Plexの設定は数GBの場合がある一方、メディアライブラリは数TBに及ぶことがあり、これらのデータセットでは異なるバックアップスケジュールや保存先が必要になることもよくあります。小さなアプリデータのアーカイブだけで、映画や家族のメディアそのものが保護されていると錯覚しないでください。
ZimaSpaceのデータベースコンテナを一貫性のある状態でバックアップするためのガイドは、稼働中のホームサーバースタックでアプリデータ、データベースの状態、永続ボリューム、復元テストを調整する必要がある場合に役立つ参考資料です。
どちらの方式でも、信頼する前にバックアップを検証する
どの方式を選んでも、ライブのPlexディレクトリとは別の場所でバックアップを確認してください。必要なファイルが存在することを確認し、タイムスタンプとサイズを記録してから、バックアップ形式に適したツールでデータベースまたはアーカイブを検証します。その後で、以前の正常なコピーをローテーション対象から外してください。
次に、可能であれば分離したパスまたはテストインスタンスへ復元する訓練を行います。目的は、バックアップソフトウェアが成功を報告したことだけでなく、バックアップから一貫性のあるサーバー状態を開けることを証明することです。最新のバックアップがこのテストに合格するまでは、少なくとも1つ前の復旧ポイントを保持してください。
復元時に、パス、所有者、認証情報、またはどのデータベースコピーがどのメタデータツリーに対応するかについて、文書化されていない推測が必要になるなら、そのバックアップ方式は運用テストに失敗しています。障害が発生してから依存関係に気づくのではなく、Plexが正常に動作しているうちに手順を改善してください。
可用性の要件に応じて、最もリスクの低い手順を選ぶ
ほとんどの家庭用Plexサーバーでは、短時間の定期停止が、アプリデータ全体をファイルコピーするための最もシンプルで信頼できる手順です。利用の少ない時間帯に設定し、保存先を事前に準備して、再起動と検証を自動化すれば、ダウンタイムを予測しやすくなります。
ライブ方式を選ぶのは、可用性によって追加の複雑さが正当化され、その方式が保護対象の実行中の状態に対して、データベース整合性を明示的に提供する場合だけにしてください。ライブバックアップツールが変更されたり、復元テストに失敗したりした場合に備えて、停止してコピーする手順を文書化した代替策として維持してください。
判断基準は実用的です。バックアップがアクティブなPlexファイルの単純なコピーなら、まずサービスを停止します。アプリケーション対応のライブデータベース方式なら、その一貫性と対象範囲を復元テストで証明してください。優れたバックアップとは、ダウンタイムがゼロだと報告するものではなく、繰り返し復元できるものです。
サポートとヒント
もっと読む

Plexは別のDockerコンテナとGPUを共有できますか?
Plexと別のコンテナは同じGPUにアクセスできることが多いですが、ドライバーのサポート、デバイスマッピング、ビデオエンジンの負荷、メモリ、復旧動作をテストする必要があります。

Plexのエラーがクライアント側とサーバー側のどちらに起因するかを見分ける方法
別のクライアントで同じ項目を再現し、セッションパスを比較してから、スコープによって障害の実際の所在が特定された後にのみサーバーの証拠を収集してください。

Plexのキャッシュとトランスコード用一時ストレージを設定する方法
永続的な Plex の状態を保護しつつ、トランスコードの一時ファイルを適切なローカルストレージに配置し、クリーンアップ、空き容量、再起動時の動作を確認します。

