リストア

🐾 猫で例えると？

頭に前足を添えて寄り添う、仲良しの2匹。この写真をうっかり消してしまったら、別に保存しておいたコピーから写真ファイルを戻します。コピーを残すのがバックアップ、そこから実際に戻す作業がリストアです。コピーを取った後に加えた加工は、そのコピーからは戻せません。

💻 データ・データベースにおける「リストア」とは？

企業の基幹システムやWebサービスの運用において、データの消失はサービスの停止だけでなく企業の信用失墜に直結する致命的なインシデントです。ハードウェアの物理的な故障、ランサムウェアによるデータの暗号化、開発者のオペレーションミス（SQLの誤実行によるデータ一括削除など）のリスクは常に存在します。これらの非常事態が発生した際、システムを救う最後の砦が「リストア」です。

復元先は元のサーバーとは限りません。別の環境へ復元して、必要なデータがそろうか、アプリから読み出せるかを確かめてから切り替える方法もあります。バックアップファイルが存在するだけでは、復元に成功する保証にはなりません。

⚠️ リストアの仕組みと注意点

データベース（RDBMS）のリストアでは、単純に古いファイルを上書きするだけでは不十分なケースが多々あります。バックアップを取った「その時点」の状態に戻した上で、そこから障害発生直前までの変更履歴（ログ）を順番に適用していく高度な復旧作業が行われます。

完全バックアップとログを用いたロールフォワード（復旧）の例

PostgreSQLなどでは、ベースバックアップと、その後の変更を記録したログを組み合わせて、指定した時点まで復元するPITRが使えます。ログが連続して保存され、必要な設定や暗号鍵もそろっていることが前提です。

日曜 00:00  ベースバックアップを取得
以降        変更ログを継続して保管
水曜 10:00  誤った削除が発生
復元時      削除より前を目標時点に指定
確認        データとアプリの動作を確認して切り替える

戻せる範囲は保存済みのバックアップとログで決まります。障害直前までの記録が失われていれば、その分の更新も戻せません。誤削除の場合は、障害時刻まで再生すると削除も再現されるため、目標時点の選定が重要です。

🛠️ リストアを賢く使うためのポイント

データマネジメントを担当するデータベースエンジニアやインフラ管理者にとって、リストアの運用設計は最も緊迫感のある領域です。

• RTO（目標復旧時間）の設計： データの容量がテラバイト級に巨大化すると、ストレージからの転送だけで何時間もかかってしまいます。ビジネスの許容時間内にリストアが終わるよう、回線帯域や機材のスペックをあらかじめ見積もっておく必要があります。
• 定期的なリストア試験の実施（超重要）： バックアップが壊れていたり、復号鍵が見つからなかったりすると復元できません。本番と分離した検証環境で定期的に復旧を試し、手順書・必要な鍵・復元データがそろっているかを確認します。
• 静止点の確保と整合性チェック： オンラインで激しくデータが書き換わっている最中に中途半端なリストアを行うと、データの整合性が崩れてバグの原因になります。システムをメンテナンスモードにするなど、確実な制御下で実行します。

2匹の写真もシステムのデータも、戻すための材料と手順がそろって初めて復元できます。小さなテスト環境で一度リストアを通し、所要時間と確認項目を記録しておくと、いざというときに判断しやすくなります。