パナマ事業者 · KYCなし · Monero6 か月 −28% 年 −50% · 前払い

運用と復旧

依存する前に出口をリハーサルする。

ポータビリティは復元リハーサルで検証するものです。完全なアプリケーションを棚卸しし、ソースに依存しない復元可能なコピーを準備し、移行をスケジュールする前に分離されたターゲットで再構築します。データベースのエクスポートだけでは、サービスが別の場所で実行できる証拠にはなりません。

レビュー日 · Hosmio リソース

始める前に

使い捨ての宛先と書面によるテスト範囲を選択します。アプリケーションコード、必要なソフトウェアバージョン、承認されたバックアップ資料へのアクセスを確認します。ターゲットを本番環境から分離し、意図的にテストするまで送信通知、スケジュールされたジョブ、外部書き込みを無効にします。

01

移行が必要なものと再作成が必要なものをリストアップします。

ランタイム、データベース、アップロードファイル、構成、スケジュールされたジョブ、証明書、DNS所有権、外部統合を含めます。各依存関係を誰が管理し、現在のVPSが利用できない場合にアクセスをどのように回復できるかを記録します。ファイルコピーではなく代替が必要なサプライヤー固有の機能を特定します。

期待されるバージョンと拡張機能を書き留めます。今日の最新版を取得するインストールコマンドは、運用しているアプリケーションを再現しない可能性があります。認証情報には保護されたシークレットストレージを参照してください。リカバリ計画では、計画自体にシークレットを記載することなく、権限を持つ人がそれらを取得する方法を説明すべきです。

02

データを考慮したエクスポートと復元方法を選択します。

PostgreSQL の場合、pg_dump による論理エクスポートが対象とするのは 1 つのデータベースであり、ロールなどのグローバルオブジェクトには別途の対応が必要です。このツールは、クライアントが対応するメジャーバージョンより新しいサーバーのダンプを拒否します。公式ドキュメントでも、pg_dump を万能な通常運用のバックアップ戦略として扱うべきではないと注意しています。 PostgreSQL: pg_dump ↗

アプリケーションとリカバリの要件に適した方法を、運用担当者とともに選択してください。エクスポートが省略するもの、およびファイルがデータベース参照とどのように整合性を保つかを記録します。コマンドが正常終了することは有用な一次確認ですが、アプリケーション全体が保全された証拠ではありません。

03

明示的に分離されたターゲットに復元します。

リストア前にアーカイブと復元先を検査してください。PostgreSQL のアーカイブ復元は pg_restore を使用します。既存オブジェクトをクリーンアップするオプションはデータを削除する可能性があり、またデフォルトの動作では SQL エラー後も処理を継続することがあります。エラー処理を計画し、すべてのオブジェクトが復元されたと仮定せずに結果を検査してください。 PostgreSQL: pg_restore ↗ 名前がよく知られているというだけの理由で、本番データベースに対してチュートリアルを実行しないでください。

ファイルバックアップの場合、意図したスナップショットと空のテスト復元先を選択してください。Restic のドキュメントでは、復元が既存ファイルを上書きする可能性があること、および中断された上書きは部分的な結果を残す可能性があることが記載されています。 restic: バックアップからの復元 ↗ 演習ノートにソーススナップショットとターゲットパスを記録してください。これらは方法選択のガイドラインであり、Hosmio VPS に対して実行または検証されたコマンドではありません。

04

ユーザータスクと隠れた副作用を確認します。

終了リハーサル受け入れシートの例
確認保持する証拠結果
アプリケーションがドキュメント記載のバージョンで起動するバージョン一覧と起動結果未テスト
代表的なレコードとファイルが一致する合成レコードと添付ファイルのチェック未テスト
権限が正しく動作する2 つのテストロールと期待されるアクセス未テスト
ジョブが外部作業を重複して送信しないアウトバウンドアクションを無効化、または制御されたテスト未テスト
代替の運用担当者がノートに従える独立したウォークスルーとギャップ未テスト

可能な限り合成アカウントと無害なテストレコードを使用してください。読み取りの成功だけでなく、アクセス境界も検証します。起動しても誤った権限を付与するアプリケーションは、成功したリカバリとは言えません。失敗したチェックは、是正の担当者とともに記録に残してください。

05

新しい書き込みが判断を変える時点を計画します。

リハーサルは将来の移行の順序に反映させるべきです。最終整合性ステップ、復元先のチェック、トラフィック切り替え、受け入れ判断、旧サービスの廃止です。誰が操作を停止または巻き戻せるかを決めてください。復元先が新しい書き込みを受け入れている場合、ユーザーを古いコピーに戻すとそれらの書き込みが失われたり分断されたりする可能性があります。ロールバックには DNS 変更だけでなくデータ計画が必要です。

予算には重複期間を考慮してください。2 台目のサーバー、独立したストレージ、トラフィック料金、ライセンス、運用担当者の時間が必要になる場合があります。サプライヤーが VPS を日割り計算すること、または前払い資金が返金可能であると仮定しないでください。Hosmio の公表された期間価格は前払い条件を示すものであり、移行や返金サービスを定義するものではありません。

06

別の運用担当者が使用できる証拠を残します。

演習日、バージョン、コピー識別子、ターゲット、所要工数、結果は、演習が実際に実施された後にのみ記録してください。それまでは「計画済み」または「未テスト」を使用します。受け入れシートはリカバリノートとともに保管し、独立した再構築を妨げている依存関係を列挙してください。

リハーサルが失敗した場合、ギャップを分類してください。データの欠落、ソフトウェアの非互換性、資格情報の利用不可、外部依存関係、または不明確な手順です。最小のブロッキング問題を解決してから、影響を受けるチェックを繰り返します。重要なタスクが未テストのまま、アプリケーションを移植可能と呼んではいけません。

計画を次のものに接続してください 名前を付けた運用責任クライアントの変更承認プロセス。意図する結果は、文書化された範囲内でリカバリできることを実証することであり、無停止を約束したり、移行を自動的に提供したりすることではありません。