Plex ユーザーなら誰でもよく知っている、特定の沈み込むような感覚があります。あなたはサーバーにログインし、細心の注意を払って厳選されたメディア ライブラリでくつろぐ準備ができています。すると、見慣れた映画ポスターのグリッドではなく、無菌のオレンジ色のスクリーンが迎えてくれます。データベースは破損し、何週間もかけて構築した慎重に厳選されたコレクションはデジタル エーテルに消えてしまいました。
Plex は素晴らしいソフトウェアですが、そのアキレス腱は常に、その基盤となるデータベースと構成ファイルの脆弱さでした。私たちはメディア ファイル用の冗長ストレージ アレイの構築に数え切れないほどの時間を費やし、Linux ISO が 1 つも失われないようにしながら、スタック全体の中で最もかけがえのない唯一のコンポーネントである Plex アプリケーション データ自体を盲目的に無視しています。ここで、Proxmox が VM スナップショットを使用します。これは、コミュニティの大部分がこの特定のユースケースにまだ採用していない、目立たないソリューションです。
Plex が壊れたときに実際に失うもの
ほとんどの人がホーム メディアのバックアップにどのように取り組むかを決定している根本的な誤解があります。最も明白なことは、テラバイト、4K リマックス、無名な外国映画を保護することですが、適切に構成された自動メディア スタックの中で本当にかけがえのないものは何なのか、正直に自問してみてください。

Plex サーバーには 70TB は必要ありません: 4K リマックスの溜め込みが巨大なストレージの罠になる理由
これら 3 つの素人の間違いで Plex ストレージを無駄にするのはやめましょう
*arr スタックでは、ほとんどの場合、メディア ファイルは貴重な固有の成果物ではありません。動作する構成とインターネット接続があれば、*arr スタックは、これまでに所有していたすべてのメディア ファイルを体系的かつ自動的に再取得できます。これはすぐには実行されませんが、ある程度完全に自動化されたプロセスであり、一度構成されれば創造的な人間の入力は必要ありません。
*arr スタックがダウンロードできないのはメタデータです。デフォルトのポスターのフレームが適切でなかったため、長年の視聴履歴や手動で選択したカスタム ポスターを再ダウンロードすることはできません。また、ジェームズ・ボンド映画をアルファベット順ではなく時系列順にグループ化する手作業で調整されたコレクション ルールを再ダウンロードすることもできません。このデータは、Plex アプリケーション データ ディレクトリ、主に SQLite データベースに存在します。
SQLite と停電は天敵であるため、データベースが破損すると、最終的には破損することになり、どんなにギガビット インターネットを使っても回復できないものを失うことになります。
Proxmox スナップショット
ポイントインタイムステートマシン
皆さんの中には、特に Docker ユーザーなど、すぐに指摘するかもしれません。 /config ディレクトリを永続ボリュームにコピーします。これは、夜間に tarball ジョブを実行していると仮定して、単純なファイル レベルの復元には機能しますが、実行中のデータベースのファイル レベルのコピーはロシアン ルーレットのようなものです。書き込みロックが進行中の状態で SQLite データベースをコピーすると、「バックアップ」は破損が起こるのを待っていることになります。確実にバックアップする唯一の方法は、データベース エンジンを停止し、ファイルをコピーして再起動することです。 Plex を毎晩 30 分間手動で停止することは、ほとんどの人が行うことではなく、現実的ではありません。 Proxmox VM スナップショットは、ファイル レベルではなくブロック レベルとメモリ状態レベルで動作するため、根本的に異なるカテゴリのバックアップとなります。
実行中の仮想マシンの Proxmox スナップショットをトリガーすると、すべての書き込み操作が一時停止され、ファイル システム バッファがディスクにフラッシュされ、そのナノ秒における仮想ディスク上のすべてのビットの正確な状態がキャプチャされます。また、RAM の状態をキャプチャし、VM の一時停止を解除します。このプロセス全体の所要時間は 1 秒未満であり、サービス ブリップは多くの場合最小限であるため、継続的な ping では 1 つのパケットもドロップされない可能性があります。
これにより、仮想ディスクとメモリ全体の完全に整合性があり、クラッシュ整合性のあるコピーが得られます。 Plex が実行されている場合、スナップショットには、トランザクション中ではなく、データベース エンジンによって認識された、存在していたとおりの SQLite データベースのイメージが含まれています。
壊れたプレックス更新を数秒でロールバック
タイムトラベルのようなレストア
これは、ほとんどの人が危機で経験するまでは理解できない、「うまくいく」魔法です。 Plex チームがアップデートをプッシュすると想像してください。何も考えずにインストールしてしまうのは、私たちの多くが罪を犯していることです。致命的な問題が発生し、データベース移行スクリプトによってライブラリが破損し、視聴履歴が消去され、一致しないメディアがあちこちに散らばった状態になります。
ベアメタルまたは Docker セットアップでは、回復パスにはファイル システムのバックアップを掘り下げて、できれば更新前のデータベースのコピーを見つけることが含まれます。 Plex を停止し、破損したデータベースを古いデータベースに置き換え、Plex を再起動して、すべてがうまくいくことを祈りますが、ほとんどの場合、最後のバックアップから現在までの数日間の監視データが失われることは避けられません。
Proxmox では、回復パスは 3 回のクリックです。 Web インターフェイスで Plex VM に移動します。 VM を停止します。 「スナップショット」タブを選択します。 Proxmox を使用すると、外部スクリプトを 1 行も書かずにネイティブにスナップショットをスケジュールできるため、タイムスタンプ付きのスナップショットのリストが表示され、毎日自動的にスナップショットが取得されます。からスナップショットを選択し、「ロールバック」をクリックします。 5 秒後、VM を起動します。 Plex が起動すると、データベースはすべてがそのままの状態とビットごとに同一になります。これは従来の意味でのバックアップではなく、サーバー全体のクリーンな「元に戻す」ボタンです。
これでストレージが消費されませんか?
シンプロビジョニングとCoWメカニズム
このアプローチに対する一般的かつ正当な反対意見は、ディスク容量です。 「Plex VM のスナップショットを毎日保存すると、高価な SSD ストレージがテラバイト単位で消費されてしまうのではありませんか?」これは、Proxmox の実装のアーキテクチャ、特に ZFS または LVM-thin を使用する場合に役立ちます。 Proxmox スナップショットは完全なクローンではありませんが、コピーオンライト メカニズムを使用します。

Plex メディア サーバーのホストについて誰も教えてくれない 7 つのこと
Plex サーバーを適切に起動する準備はできていますか?
これが実際に意味するのは、ベース スナップショットを取得すると、システムが新しい空の差分ファイルを作成するということです。 24 時間の間、変更されたデータ ブロックのみがそのデルタに書き込まれます。 Plex データベースが 500MB で、いくつかの番組を視聴する場合、スナップショットに書き込まれるブロックは、実際に変更されたデータベース ファイルの特定の 50MB だけです。スナップショット自体は小さいままで、基本イメージにリンクされています。
完全なクローンを保存するために必要な生のディスク領域を消費することなく、最終日の 3 時間ごとのスナップショットのローリング チェーンと、毎日のスナップショットの数を維持できます。 1 週間分の詳細な Plex スナップショットを作成すると、単一の 4K ムービー ファイルよりも容量が少なくなる可能性があります。
限界
メディア ファイルはここに属しません
この戦略には、多くの場合、賢明なホームラバーと火傷を負う人々を分けるアーキテクチャの明確化が必要です。 VM スナップショットは優れていますが、VM 内のすべてに対する包括的なソリューションとして使用してはなりません。これは、この設計で最も一般的な故障モードです。
メディア ファイルを Proxmox VM 内に保存しないでください。 Plex VM にメディアがいっぱいの 12 TB 仮想ディスクがある場合、スナップショット デルタ ファイルはすぐに管理できなくなります。
また、データベースの破損から回復するために VM をロールバックする必要がある場合は、メディア コレクションもロールバックすることになります。月曜日に追加したファイルは日曜日にロールバックすると消えてしまいますが、それは望ましくないことです。

このアプリは私の Plex サーバーを即座にケーブル TV の代替品に変えました
これらの昔ながらのテレビの雰囲気は、Plex ライブラリをより見つけやすくするのに役立ちます。
これがまだ標準的な慣行ではない理由
このアプローチが未だに議論されていない理由は文化的なものです。 Plex コミュニティは歴史的に 2 つの陣営に分かれてきました。シンプルさを重視するターンキー OS ユーザー (Windows、Unraid、Synology) と、ステートレス コンテナを優先するが永続層を無視することが多い Docker 群です。 Proxmox は 3 番目のパスを表しており、通常はサーバー管理に関連付けられており、恐ろしい認識障壁を作り出します。
しかし実際には、単一の Plex VM を備えた基本的な Proxmox インスタンスは、Unraid サーバーほど保守が複雑ではありません。 Web インターフェイスはポイント アンド クリックで操作でき、その適度な学習曲線により、存在する最も壊滅的な Plex 障害モードに対する保険が得られます。
関連情報は以下のリンクからご確認いただけます