コミュニティソリューション

OfeliaでZimaOS上に再起動に強いrsyncのスケジュールバックアップを構築する

A user moved weekly AppData and NAS backup scheduling into a persistent Portainer stack using Ofelia, rsync, and scripts stored on RAID storage.

永続化されたDocker状態で運用するために必要だったスケジュール

筆者は、AppDataをRAID 1プールに毎週コピーし、さらにそのプールから常時接続された2台目のUSBディスクへコピーしたいと考えていました。しかし、システムのcrontabとコミュニティ製のスケジューリングアプリでは、再起動後もタスクを確実に保持できなかったため、永続化されたZimaOSデータ内に保存した、Portainerで管理するOfeliaスタックへスケジュール処理を移しました。

最終的な構成は、RAIDストレージ上のシェルスクリプト、スケジュールを提供するOfeliaコンテナ、各コピーを実行する短時間稼働のrsyncコンテナという3つの層に分かれていました。

永続ストレージにスクリプトとログを保存する

例では、/media/RAID1/scriptsのようなパスにスクリプトを配置していました。そのディレクトリは、/scriptsとしてスケジューラーに読み書き可能な状態でマウントしました。ログはスクリプトと同じ場所に書き込み、ジョブの完了後にFilesまたはネットワーク共有から確認できるようにしました。

例に登場するすべてのパスは、インストール環境に固有のものです。実際のマウントパスを確認せずに筆者のRAID名をそのままコピーすると、バックアップ先を誤ったり、ジョブが何も表示せずに失敗したりする可能性があります。

Ofeliaが再起動後も保持されるスケジュールを提供した

PortainerスタックではOfeliaイメージを使用し、restart: alwaysを設定して、スクリプトディレクトリをマウントし、スケジュールのラベルをコンテナに保存しました。例では、毎週日曜日の23:30にAppDataを、23:45に一般的なNASデータをスケジュールしました。

ofelia.job-local.appdata.schedule: "0 30 23 * * 0"
ofelia.job-local.appdata.command: "/bin/sh /scripts/backup_appdata.sh"
ofelia.job-local.nas_home.schedule: "0 45 23 * * 0"
ofelia.job-local.nas_home.command: "/bin/sh /scripts/backup_nas_home.sh"

筆者によると、再起動後は別のSSHセッションを開始しなくても、約1分以内にスケジューラーとそのジョブが復帰しました。

AppDataスクリプトはコピー前にPlexを停止した

変更中のPlexデータベースをコピーする可能性を減らすため、スクリプトはPlexを停止し、読み取り専用でマウントしたAppDataソースからrsyncを実行した後、Plexを再起動しました。スケジューラーコンテナは必要に応じてDocker CLIをインストールし、Dockerソケットを通じて兄弟コンテナを制御しました。

/var/run/docker.sockをマウントすると、スケジューラーにDockerホストを広範囲に制御する権限が与えられます。rootとして実行し、さらにprivilegedを有効にすると、その権限は一層強大になります。このスレッドでは、これを筆者が動作させている構成として紹介しており、最小権限のセキュリティモデルとして提示しているわけではありません。

rsync --deleteはバージョン履歴ではなく完全なミラーを作成する

例ではrsync -avH --deleteを使用しました。--deleteオプションは、ソースに存在しなくなった宛先側のファイルを削除します。これにより完全なミラーが作成されますが、誤って削除したファイルや破損も反映される可能性があります。

まずは削除を無効にした状態でテストし、ソースと宛先のマウントを確認してから、無人スケジュールを有効にする前にログを確認してください。常時接続されたUSBディスク上のミラーは、オフラインバックアップやイミュータブルバックアップと同等ではありません。

再起動後もUSBの再接続問題は解決しなかった

筆者は別途、接続したUSBディスクが再起動後に新しいディスクとして表示される問題の解決も求めていました。Ofeliaはジョブ設定を保持しますが、マウントパスが変わったり利用できなくなったりすると、バックアップ先が使えなくなる可能性があります。安定したストレージ識別と、rsync実行前のマウント確認は、引き続き別途必要な要件です。

FAQ

なぜこのスケジュールは再起動後も保持されたのですか?

ジョブ定義が再起動設定の有効なPortainerスタックに保存され、スクリプトも一時的なシステムのcrontabではなく永続ストレージに保存されていたためです。

これにより、過去のバックアップバージョンは作成されますか?

いいえ。記載されているrsyncコマンドはミラーを作成し、--deleteを使用します。バージョン保持には別の設計が必要です。

なぜAppDataのコピー前にPlexを停止するのですか?

変更中のデータベースをコピーするリスクを減らすためです。