このコミュニティ向けバックアップ設計がrsyncを使用する理由
作成者は、組み込みのバックアップジョブが読み取り不能なファイルをスキップしていることに気づき、透明性の高いZimaOSからSynologyへのワークフローを構築しました。この事例の中心的な教訓は、特定のツールよりも重要です。成功インジケーターを信頼するのではなく、保存先を確認しましょう。
データバックアップ：CURRENTとサーバー側ハードリンクスナップショット
検証済みの設計では、rsyncを使ってプールをCURRENT/にミラーリングし、その後Synology上でcp -alを使って日付付きスナップショットを作成します。作成者は、SMB経由でハードリンクを作成するよりも、Synology上でスナップショットをローカルに実行する方がはるかに高速であることを発見し、以前の方法を修正しました。
rsyncのフィルター順序の落とし穴
rsyncは、includeとexcludeのルールを順番に適用します。広範なDocker除外をボリュームのincludeより前に配置したため、実行が成功したように見えたにもかかわらず、作成者の永続的なDockerボリュームがひそかに除外されました。公式のrsyncマニュアルには、フィルターの動作が記載されています。必ず保存先を確認し、必要なデータが存在することを検証してください。
データバックアップとOSイメージを分ける
作成者の2つ目のジョブでは、ベアメタル復旧用に、チェックサム付きの圧縮システムディスクイメージを作成します。ddによるディスクイメージ作成は、対象を間違えると誤ったディスクを破壊する可能性があるため、これは高度な手順です。まずは重要でないハードウェアでテストしてください。GNUは、SHA-2ユーティリティのドキュメントでチェックサム検証について説明しています。
ZimaOSでバックアップする対象
すべてのインストールで同じパスが使われていると決めつけず、実際のプール、アプリケーションデータ、コンテナボリュームがどこに保存されているかを確認してください。コミュニティスクリプトを適用する前に、最新のZimaOSストレージガイドとZimaOSアプリのガイダンスを確認しましょう。
