ドキュメント、写真、アプリの状態ごとに個別のバックアップジョブを設定する方法

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

How to Set Up Separate Backup Jobs for Documents, Photos, and App State

ドキュメント、写真、アプリケーションの状態について、それぞれ個別のバックアップジョブを設定しましょう。これらのデータセットは、変更パターン、一貫性の要件、保持の必要性、復元手順が異なるためです。

1つの巨大なジョブにまとめるとスケジュール設定は簡単ですが、障害発生時の状況把握が難しくなります。削除したドキュメントにはバージョン履歴が必要で、失われた写真ライブラリには永続性のあるオリジナルとメタデータが必要です。また、データベースを使用するアプリは、起動前に設定と合わせたダンプが必要になる場合があります。ジョブを分けることで、同じNASやオフサイトの保存先を共有しながら、それぞれの復旧経路を個別にテストできます。

バックアップツールを選ぶ前に復旧単位を定義する

まず、何を一緒に復元する必要があるかを一覧にします。ドキュメントフォルダーは通常のファイルとして単独で役立つ場合があります。写真アプリケーションでは、オリジナルとデータベースの状態の両方が必要になることがあります。セルフホストサービスでは、データベースダンプ、設定、シークレット、Composeファイル、選択した永続ボリュームが必要になる場合があります。

2026年のファイル、VM、データベースに関する記事では、復旧に必要な仕組みに応じて、ファイル、仮想マシン、データベースを分けています。ここで役立つ教訓は、選択しやすいトップレベルフォルダー単位ではなく、復元時の意味に基づいてバックアップを整理することです。

データセット、正本となるソース、バックアップ方法、スケジュール、保持期間、一貫性の要件、オフサイトの保存先、復元テストを記載した小さなカバレッジ表を作成します。表に記載できない項目は、まだ完全なバックアップ計画になっていません。

ドキュメントにはバージョン重視の保持ポリシーを設定する

ドキュメントは通常、写真よりも容量が小さく、編集、名前変更、削除によって頻繁に変更されます。主な要件は、最大限の順次バックアップ速度ではなく、以前のバージョンや誤って削除したファイルを復元できることです。

ドキュメント専用の保存先と保持ポリシーを設定し、写真アーカイブの大きな保持コストを引き継ぐことなく、編集、名前変更、誤削除から復元できるようにします。

再作成できるキャッシュや一時ファイルは除外しますが、重要な場合はファイルのメタデータと権限を保持します。テストでは、リポジトリにファイルが存在することだけでなく、変更したオフィスドキュメントと削除したフォルダーを復元します。

再構築可能な派生データとは分けて写真のオリジナルを保護する

写真のオリジナルや個人動画は、通常、大容量で追加中心の構成になっており、再作成が困難または不可能です。バックアップジョブでは、正本となるメディアを完全に保護し、効率的な増分転送、オフサイトでの耐久性、誤削除に耐えられる十分な保持期間を優先します。

2026年のオリジナル、データベース、設定に関する記事では、オリジナルアセットをPostgreSQLの状態、設定、生成された派生データから分けています。この分離はImmich以外にも有効です。写真アプリのサムネイルは再構築できることが多い一方、家族のオリジナル写真は再作成できません。

メディア中心のジョブによって、小規模で重要な設定のバックアップが遅れないようにします。写真の転送に何時間もかかる場合は、ドキュメントとアプリケーション状態のジョブを個別にスケジュールし、新しい復旧ポイントを継続的に作成できるようにします。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

アプリケーション整合性を保ってアプリケーションの状態を取得する

実行中のアプリケーションディレクトリには、トランザクションデータベース、キャッシュ、ロック、キュー、インデックス、生成ファイルが含まれている場合があります。データベースへの書き込み中に取得したファイルシステムコピーは、アプリケーション設定と組み合わせた小容量のデータベースネイティブダンプより信頼性が低くなる可能性があります。

システム間の整合性を考慮した実用的なホームサーバー設計では、写真、組み込みデータベース、サービスの状態を1つの汎用コピー方式で保護する難しさが示されています。

データベース整合性を保ったコンテナバックアップに関するZimaSpaceの関連ガイドでは、具体的な境界が示されています。周囲のボリュームを通常のファイルとして扱う前に、一貫性のあるデータベース状態を保護します。

ジョブをずらしてスケジュールし、3つの復元経路を個別にテストする

可能な場合は、各ジョブに専用のアカウントまたは認証情報、保存先の名前空間、ログ、アラート、再試行ポリシー、メンテナンス時間帯を設定します。大容量の写真バックアップは、リポジトリのチェックやデータベースのメンテナンスと時間をずらし、1つのワークロードがディスク容量やネットワーク帯域を気付かないうちに使い切らないようにします。

分離したバックアップ時間帯について説明した2026年のホームラボ事例では、データベースの取得、ファイルバックアップ、オフサイトへの転送を明示すると、異なるサービスを監視しやすくなる理由が示されています。

3つの復元テストを実施します。1つのドキュメントバージョンを復元し、メタデータを含む小規模な写真セットを再構築し、保存した状態からクリーンな対象環境で1つのアプリケーションを起動します。分離したジョブが成功したと言えるのは、ジョブ間に隠れた依存関係を残さず、復旧時の不確実性を減らせた場合だけです。