スナップショットは、その実装によって保護が決まる時点の表現です。バックアップ戦略は、意図的な保持、アクセスの分離、テスト済みのリカバリを追加します。スナップショットの中にはバックアップであるものもあれば、元のストレージに依存するものもあります。削除、侵害、プライマリ環境の喪失に何が耐えるかを問いましょう。
名前を付ける前にコピーを説明する
スナップショットという言葉は、ある時点が表現されたことを示しますが、復元可能なデータがどこに保持されているか、誰がそれを削除できるかは示しません。元のストレージ上のファイルシステムスナップショットと、プロバイダー管理のブロックスナップショットでは、障害境界が異なる場合があります。ラベルを普遍的な約束として扱うのではなく、実装から始めましょう。
AWS は EBS スナップショットを、そのボリュームの増分時点バックアップとして文書化しています。それは特定の実装であり、すべてのスナップショットオプションが同じように動作する証拠ではありません。どのサービスについても、復元が元のボリュームに依存するか、コピーがプライマリ障害ドメインの外に出るか、ソースが削除されたときに何が起こるかを問いましょう。
生き残ると想定する障害を比較する
更新後の迅速なロールバックと、アカウント喪失後のリカバリは別の問題です。ローカルスナップショットは前者には便利でも、後者にはほとんど分離を提供しない場合があります。独立したコピーは保護を追加できますが、そのストレージ、アクセス、削除の経路が、備えているインシデントから十分に分離されている場合に限ります。
障害と必要な結果を書き留めましょう。この例示的な比較は意思決定の補助であり、SwissOctet の機能一覧ではありません。ある技術が常に優れているという主張ではなく、コピーと制御についての問いを促すものです。実際の結果は、構成とオペレーターの文書化されたリカバリプロセスに依存します。
| シナリオ | スナップショットへの問い | バックアップへの問い |
|---|---|---|
| アプリケーション更新の失敗 | 意図した時点に戻せるか？ | 使用可能な復元にはどれくらいかかるか？ |
| プライマリディスクの喪失 | コピーはそのディスクに依存しているか？ | 新しいストレージに復元できるか？ |
| 管理者アカウントの侵害 | このアカウントはすべてのコピーを削除できるか？ | 削除権限は分離されているか？ |
| 数週間後に発覚したエラー | その時点はまだ保持されているか？ | 保持は発覚の遅れをカバーしているか？ |
アプリケーションの整合性を確認する
ディスクは、アプリケーションがまだファイルを変更している間にそれらをキャプチャすることがあります。ソフトウェアとスナップショットプロセスによっては、結果は調整されたアプリケーション状態ではなく、クラッシュ整合性のある状態を表す場合があります。読み取り可能なファイルがあるからといって、データベースと関連するアップロードが一致していると仮定してはいけません。アプリケーションまたはデータベースが文書化したバックアップ方法を使いましょう。
PostgreSQL の継続的アーカイブ設計はその違いを示しています。リカバリには適切なベースバックアップと、必要な先行書き込みログファイルの連続したシーケンスが必要です。データベースの稼働中に場当たり的にコピーされたディレクトリは、同等の手順ではありません。アプリケーションがデータベース外にもファイルを保存している場合は、それら2つのデータセットをどのように一緒に復元するかを計画しましょう。
保持をリカバリウィンドウとして扱う
保持は、エラーがどのくらいの期間気づかれずに残りうるかを考慮すべきです。10日間のウィンドウは、1か月後に発覚した偶発的な削除には役立ちません。すべてのコピーを無期限に保持すると、別の問題が生じます。コスト、機密データ露出の増大、不明確な削除ポリシーです。保持は、具体的な運用上およびデータ取り扱い上の要件から選びましょう。
リカバリポイントには、アプリケーションのバージョンや完了したジョブの時刻など、有用な文脈をラベル付けしましょう。ただし秘密情報を埋め込まないようにします。良好な状態と損傷した状態を区別できるだけの履歴を保持しましょう。プルーニングの前に、選択したシステムが共有データや増分データをどう扱うかを確認しましょう。ラベル付けされたポイントの削除は、単純なスタンドアロンファイルの削除とは対応しない場合があります。
成功したジョブと検証済みデータを分ける
バックアップツールが成功を報告することは、そのプロセスがそのルールの下で完了したことを示します。重要なアプリケーションデータがすべて選択されたこと、保存されたすべてのバイトが無傷であること、新しいサーバーがその結果を使えることを自動的に証明するものではありません。それらは別のチェックです。リポジトリの健全性、選択内容のレビュー、代表的な復元を運用計画に含めましょう。
Restic は、デフォルトのリポジトリチェックと、保存されたパックデータを読み取る検証との違いを文書化しています。完全なデータ読み取りチェックは、より多くの時間と帯域幅を消費する場合があります。その例は計画上の要点を具体的にします。検証が実際に何を読むかを決め、作業を予算化しましょう。check という名前のすべてのコマンドが同じカバレッジを持つと仮定せず、ツールのドキュメントを使いましょう。
小規模で完全なリカバリをテストする
データベース、アップロードされた画像、構成を持つ出版物を想像してみましょう。3つすべてをプライベートなテスト環境に復元し、その後、記事を開いて添付ファイルを検証します。演習中は、スケジュールされたメール、決済、公開の統合を無効にしておきましょう。ランダムなテキストファイルだけをテストすると、アプリケーションを有用にしている関係性を見逃します。
所要時間を測定し、どの認証情報、パッケージバージョン、外部依存関係が欠けていたかを記録しましょう。復元されたファイルの内容だけでなく、権限も確認しましょう。リカバリ演習では、データは存在するものの、それを使うために必要な手順やアクセスが運用計画とともに保存されたことが一度もない、と判明することがよくあります。
オプションのバックアップを特定のサービスとして読む
SwissOctet を構成するときは、ファミリーの正確なバックアップオプションと保持期間を確認しましょう。どのボリュームとアプリケーションデータをカバーするか、リカバリがセルフサービスか、プライマリ構成が変更されたときに何が起こるかを問いましょう。オプションのラベルだけでは、独立したコピー、不変リポジトリ、データベース整合性のあるリカバリポイントを確立できません。
スナップショットはワークロードに合う場所で使い、カバーしない障害にはより広いバックアップ戦略を維持しましょう。重要なデータには独立したリカバリ経路を記録し、コピーを消去できる認証情報を保護し、手順をテストしましょう。最も強い選択は、定義したシナリオに耐えるものであり、最も安心させる名前のものではありません。
実践チェックリスト。
- 復元可能なデータがどこにあるかを特定する。
- コピーが耐えるべき障害を列挙する。
- アプリケーションがサポートする整合性方法を使う。
- 発覚ウィンドウに合わせて保持を選ぶ。
- 削除権限を別途保護する。
- 完全なアプリケーションを分離環境で復元する。
重要な詳細。
スナップショットは決してバックアップではないのですか？+
スナップショット実装の中にはバックアップであるものもあります。有用な区別は、ラベルだけでなく、ストレージ依存性、保持、アクセスモデル、テスト済みのリカバリです。
整合性チェックの成功は、アプリケーションが動作することを証明しますか？+
それはそのチェックがカバーするものだけを証明します。アプリケーションの復元、構成、権限、データ関係を別々にテストしましょう。
バックアップを同じサーバーに保持すべきですか？+
同一サーバー上のコピーは限定的なミスには役立つかもしれませんが、重要な障害を共有します。重要なデータには、生き残るつもりの障害境界の外にあるリカバリ経路が必要です。
出典へ。
これらの参考文献は、このガイドの技術的概念をサポートしています。本番システムを変更する前に最新のドキュメントを確認してください。
- Amazon EBS: スナップショット docs.aws.amazon.com
- PostgreSQL: 継続的アーカイブとポイントインタイムリカバリ www.postgresql.org
- Restic: リポジトリと整合性チェックの扱い restic.readthedocs.io
SwissOctetによる編集ガイダンス。例は例示目的です。サービス仕様、利用可能なオプション、契約条件は別途確認する必要があります。