シチュエーション別　リストアの行い方　その2

皆様、こんにちは。
株式会社カチカのオフサイト＆コールドバックアップ業務担当の村島です！
私はどこか体が悪いんでしょうか？なんかいま現在体のあちこちがミシミシいってます。
ハードな運動とかしてないんだけどなあ。
では、いつものやつ行きましょうか。

ではお話を始めましょう

昨日は、データ損失と破損について見ていったんでした。では、今日は正しい復旧の仕方について見ていくことにしましょう。
データ復旧は、単にファイルをコピーするだけでなく、計画的かつ段階的なアプローチを必要とします。
その全体像と具体的な方法を詳述します。

復旧プロセスの全体像

効果的なデータ復旧には、事前の準備、的確な実行、そして厳格な検証が不可欠です。

事前準備と初動対応

データ損失やシステム障害が発生した際、冷静かつ迅速な初動対応が被害を最小限に抑える鍵となります。

まず、復旧の可否判断と専門家への相談が重要です。データが失われた原因（論理障害か物理障害か）を特定し、自力での復旧が困難と判断した場合は、速やかに専門のデータ復旧業者に相談することが推奨されます。特に、HDDから異音がする、焦げ臭い匂いがするなど物理障害の兆候がある場合は、電源を入れずに専門業者に依頼すべきです。多くの業者は無料診断を提供しており、復旧の可能性や費用、納期を確認できます。

次に、バックアップの確認と準備（媒体、種類）を行います。失われたデータが別のファイルや外付けHDD、USB、クラウドストレージ、社内サーバー、またはアプリケーションの自動バックアップに残っていないかを確認します。バックアップの種類（フルバックアップ、増分バックアップ、差分バックアップ）によって復旧プロセスと時間が異なります。

また、RPO（目標復旧時点）とRTO（目標復旧時間）の設定は、復旧戦略の根幹をなします。RPOは「許容できるデータ損失量（データの古さ）」を、RTOは「許容できるシステム停止時間」を示します。RPOが短いほどバックアップ頻度を高くする必要があり、RTOが短いほどシステムの冗長化や迅速な復旧プロセスが求められます。これらの目標は、ビジネスの収益創出能力や顧客への影響を考慮して設定され、災害復旧計画（DRP）の指針となります。

RPOとRTOは、単なる数値目標ではなく、企業の事業継続性に対するコミットメントを示す指標です。RPOを短く設定すれば、より頻繁なバックアップが必要となり、ストレージコストが増加する可能性がありますが、データ損失のリスクは最小限に抑えられます。一方、RTOを短く設定するには、システムの冗長化や災害復旧サイトの準備、遠隔地のデータセンターの設立など、より高度なインフラ投資が必要となります。これらの目標設定は、事業の重要性、許容できる損失、そして投資可能なリソースを総合的に評価する戦略的な意思決定プロセスであり、企業のレジリエンスと競争力を直接的に左右します。

最後に、災害復旧計画（DRP）と事業継続計画（BCP）の策定は、組織が予期せぬ事態に直面した際に事業を継続し、ITシステムを復旧させるための不可欠な計画です。BCPは事業全体の継続性を、DRPはITシステムの復旧に焦点を当てますが、両者は相互に補完し合う関係にあります。DRPの策定手順には、計画グループの確立、リスク評価、RPO/RTOの定義、情報システム資産の棚卸し、復旧戦略の策定、コミュニケーション計画、文書化、定期的なテストと更新などが含まれます。

DRPとBCPは、単なる文書ではなく、組織の生存と成長を左右する戦略的な枠組みです。BCPが事業全体の継続性を保証する「上位計画」であるのに対し、DRPはITシステムという特定の領域に特化した「下位計画」として機能し、両者が連携することで災害発生時のビジネス継続性が確保されます。この相互補完的な関係は、企業が直面する多様なリスク（自然災害、サイバー攻撃、人為的ミスなど）に対して、技術的側面（DRP）と組織的・経営的側面（BCP）の両方から包括的に対応することを可能にします。効果的なDRP/BCPの策定と継続的な見直しは、予期せぬ事態が発生した際のダウンタイムを短縮し、復旧コストを削減し、顧客や利害関係者からの信頼を維持し、さらにはサイバー保険料率の引き下げや規制遵守における罰金の減額にも寄与するなど、企業価値を向上させる多大なメリットをもたらします。

復旧作業の実行

復旧作業は、失われたデータの種類やシステムの状況に応じて、適切な手順を踏む必要があります。

データ復旧の基本手順は、まず診断を行い、削除されたデータにアクセスして取り出し、必要に応じてデータを修復する流れとなります。ハードディスクの状態が悪化するのを避けるため、専門業者はハードディスクのクローンディスクを作成してから復旧作業を行うことがあります。

システム復旧の基本手順は、壊れたハードウェアの修復（必要であれば）、インストールメディアからの起動、そしてバックアップデータを用いたシステム回復の実行となります。フルバックアップデータがあれば「イメージでシステムを回復」という簡単なステップでサーバーの復旧が実現できます。

各種システムの復旧方法は以下の通りです。

• ファイル復旧：ゴミ箱から削除されたデータは、ゴミ箱を開いて直接戻すことができます。ゴミ箱からも削除してしまった場合は、Windowsの「ファイル履歴」機能から復元できる場合があります（ただし、事前に設定がオンになっている必要あり）。データ復元ソフトは、比較的安価で、消えたデータを取り戻せる可能性がありますが、データの上書きや物理的な故障がある場合は注意が必要です。多くのソフトは「場所の選択」→「スキャン」→「プレビュー」→「復元」の3〜6ステップで操作できます。

• データベース復旧：SQL Serverなどのデータベースでは、Management Studioを使用して、バックアップからデータベースを復元できます。特定の時点への復元も可能で、フルバックアップとトランザクションログバックアップを組み合わせて行われます。

• 仮想マシン復旧：仮想マシンのバックアップからの復元は、適切な復旧ポイントを選択し、元の環境または別のクラスターにリストアすることで行われます。Amazon EBSボリュームやAmazon EC2インスタンスへの復元も可能です。

• ベアメタルリカバリ（BMR）：ベアメタルリカバリは、OSやアプリケーション、データを含むシステム全体を、ハードウェアが故障した状態から復旧させる方法です。Windowsでは、Windows DVDやBackup Serverを使用して、システムイメージをネットワークフォルダにコピーし、新しいハードウェアに復元する手順が示されています。Linuxでは、dumpコマンドでバックアップを取り、レスキューモードで起動後、パーティション作成、ファイルシステム再作成、マウントしてリストア実行、GRUB2再インストールなどの手順が必要です。

復旧後の検証と改善

復旧作業が完了した後も、データの整合性確認や復旧テストの実施、そしてバックアップ戦略の見直しと改善が不可欠です。

データ整合性の確認は、復旧されたデータが破損していないか、論理的に一貫性があるかを確認するために行われます。Windowsには「Check Disk（chkdsk）」と呼ばれるシステムユーティリティが付属しており、ファイルシステムの整合性をチェックし、論理ファイルのエラーを修復できます。また「sfc /scannow」コマンドやDISMツールもシステムファイルの整合性チェックに利用できます。データベースでは、復旧後に手動でデータ検証を行うことが推奨されています。ファイル整合性チェックには、MD5やSHA1などのハッシュ値を比較するツールも有効です。RAIDシステムでは、整合性チェック（Consistency Check）を定期的に実施することで、データやパリティの不整合を早期に検出・修復できます。

復旧テストの実施とログ確認は、バックアップが実際に機能するか、設定されたRTO/RPOを満たせるかを検証するために重要です。特に重要なデータやリスクの高いデータについては部分リストアテストを月ごとに、全データの完全リストアテストは半期ごとや1年ごとに行うことが推奨されます。テスト結果はログで確認し、問題があれば改善策を講じます。

バックアップテストは、単にバックアップデータが「存在するか」を確認するだけでなく、それが「実際に機能するか」を検証する極めて重要なプロセスです。特に、システムやデータの重要度、更新頻度に応じてテストの頻度と種類（部分リストア、完全リストア）を調整することは、限られたリソースの中で最大限の効果を得るための戦略的な判断となります。この継続的なテストと検証のサイクルは、バックアップ戦略における潜在的な問題点や不足箇所を特定し、復旧プロセスの有効性を保証するために不可欠です。テスト結果を詳細に記録し、それに基づいてバックアップ計画を定期的に見直すことで、組織は変化する脅威やビジネス要件に対応し、データレジリエンスを継続的に向上させることができます。

バックアップ戦略の見直しと改善には、定期的な自動バックアップ、オンサイトとオフサイトでの冗長ストレージの活用（3-2-1ルールなど）、増分バックアップとフルバックアップの組み合わせ、バックアップデータの暗号化、オフサイトバックアップの維持、そしてバックアップおよびリカバリ計画の文書化が含まれます。監視システムとアラート機能を実装し、バックアップの成功を監視することも重要です。

今日はここまでと致します

少々短いですし中途半端なところで区切っていることは重々承知なのですが、文章の長さの都合上今日はここまでと致します。明日はこの続きから書いていきたいと思います。

リストアないしはリカバリという作業は、リストアすべき対象の内容や状態を正確に把握し、どのバックアップからどのようにリストアすべきかという手順を予め定めておき、バックアップの取得方法を勘案した上で作業を行う必要があります。

フルバックアップですとバックアップから直接リストアすることで作業は終了しますが、差分バックアップや増分バックアップの場合、フルバックアップからのリストアを行ったあと、差分や増分をリストアする必要があります。場合によってはベアメタルリカバリを行う必要もあります。

また、バックアップの保存先がどこであるのかも重要な問題です。オンプレミスのバックアップからのリカバリはとても簡単に行うことができるでしょう。しかし、そのオンプレミスバックアップがネットワークに接続されている状態ですと、例えばランサムウェアのようなネットワーク攻撃を受けたら同時にバックアップも使用不可能になってしまう可能性が高いです。また、リストアが必要な理由が災害だった様な場合には、バックアップごと失われてしまうことも十分に考えられます。

現在、大変な勢いで発達し続けているクラウドにバックアップを取った場合、リカバリはオンプレミスに次ぐぐらい容易に行うことができると思います。しかし、場合によってはインターネットへの接続が不可能になる場合があります。例えば、ネットワークのダウンといったことがあり得るでしょうが、マルウェア、特に最近猛威を振るい世界的なセキュリティ問題となっているランサムウェアによりリカバリが必要となったようなケースでは、被害に遭った側であるにもかかわらず加害者になってしまう可能性も十分考えられますので、まずはネットワークから切り離す必要があります。そうなってくると、リカバリはかなり難しくなります。他のバックアップが必要となってくるでしょう。

遠隔地のデータセンターというのも魅力的な選択肢です。データセンターにもオンラインで完全に現在扱っているデータと同期する場合もありますし、オフライン（物理的エアギャップ）で静的に保存しているデータセンターも存在します。ちなみに、弊社が行っている業務は後者となります。遠隔地のデータセンターは、ネットワークで同期を行っている場合にはリストアの作業は楽でしょう。しかし、誤操作などによってデータが失われたり、システムが破壊されたりしてしまったらデータセンターにあるデータが同期してしまっているため、利用することができません。一方、物理的エアギャップを遠隔地のデータセンターに保存している場合には、媒体を運搬する時間が必要がある、またバックアップ時点以降の変更は反映されないなどの欠点はありますが、誤操作・マルウェア・災害など多方面の危機に対して非常に強い備えとなります。

繰り返しになりますが、弊社は物理的エアギャップをお預かりする会社です。遠隔地にデータセンターを置くという情報セキュリティ対策を受託しているとお考えください。単に静的に保存しておくだけではなく、お預かりしている間に様々な作業を行うことも可能です。手動であることを強みとして柔軟な対応が可能となっておりますので、どうぞご遠慮なくリクエストをお寄せください。

というわけで今日もやります

Geminiさんのお手並み拝見シリーズです。昨日はこんな絵を描いてもらったのでした。

これは「金栗四三の絵を描いて？」というリクエストに対するGeminiさんの出力です。
この方に関しては取り上げているサイトも多いですのであまり長々と解説はしませんが、オリンピックのマラソン競技で54年8カ月6日5時間32分20秒3という最長記録を持っている人です。
これ、説明しないとわかりにくいので軽く説明しますと、ストックホルムオリンピックでマラソン競技に出場した金栗さんは、猛暑のなか懸命に走りましたが耐えきれず途中で倒れてしまうんですね。
そうしたらそれを沿道の畑で作業していた夫婦が助けてくれて、金栗さんはそのまま帰国してしまうんです。
オリンピックがまだ大したイベントではなかった時代のことで、選手の状態を把握する手段もあまりありませんでした。というわけで金栗さんが戻ってきていないことに誰も気づかず閉会式が行われてしまいました。
ストックホルムオリンピックから55周年のイベントを行うことになり、当時の記録が改めて確認されるのですが、金栗さんにリタイヤの記録もゴールの記録もないことが判明し「終わってないんじゃないか？」ということになり、イベントに金栗さんが招かれ、スタジアムを走ってゴールテープを切った、その記録が一番遅い記録となります。
このとき、それを中継していたテレビのアナウンサーは「これにてストックホルムオリンピックを終了いたします」と言ったそうです。なかなか粋な人。

というわけで、今回もGeminiさんのお手並み拝見シリーズをやってみようと思ったんですが、初めての夫婦、初めての悪人ということでGeminiさんにリクエストをしたんですね。ところが、描いてもらえなかったんです。Geminiさん的には、悪人のことなど話題に上らせるものではないという考え方なのかなあ？何となく「臭いものに蓋」という感じがするのですが。
というわけで今回は代打としてCopilotさんにご協力いただきました。

Copilotさん、どうも悪人たちであることを知らない感じがしますが…ヒント出しましょう。

1. 夫婦ともイギリス人です

2. いわゆるシリアルキラーです

3. 彼らが何人殺したのか、それは結局迷宮入りになってしまいました

今回は簡単です。夫婦でシリアルキラーと言えばこの夫婦ぐらいしかいませんから。

というわけで今日はこのあたりで終わりたいと思います。
また明日もよろしくお願いします。
目次へのリンクを張っておきます。

目次へのリンクはこうするべきでしたね。
上のリンクから目次だけの記事に行きますのでそちらをご覧ください。
また次回もよろしくお願いいたします。
なお、弊社の業務をご紹介するちゃんとしたWebサイトは現在鋭意作成作業中です。今しばらくお待ちください。