ディザスタ・リカバリ

ディザスタ・リカバリ(災害対策)に関する用語や具体的な方法など

NASバックアップ問題でのトラブルシューティング

NASは、ローカルバックアップの保存先として最も一般的なもののひとつです。しかし、保護対象のPCやサーバーに直接接続されていないため、セットアップ時や、場合によっては数か月後に、いくつかの予測可能な問題が発生することがあります。

ここでは、NASに関する問題やその傾向を紹介し、それぞれの最も可能性の高い原因について解説します。ただしバックアップソフトウェアによっては、異なる特有の不具合や対処法がある場合があります。

Q: NASをバックアップデバイスとして追加しようとしても表示されない、または「バックアップソースを参照できません」というエラーが表示される

➡️ バックアップサービスは通常、ログイン中のWindowsセッションではなく、「ローカル システム」アカウントで実行されます。ユーザー自身としてマッピングしたドライブ文字は、そのアカウントには存在しません。マップされたドライブは使用せず、代わりにデバイスの設定で完全なUNCパス（\server-name\share または \192.168.x.x\share）を指定してください。もう1つのよくある原因は、NASがまだデバイスリストに追加されていないことです。

Q: 他の場所ではログインに問題がないにもかかわらず、デバイスを追加しようとした瞬間に「無効な認証情報」というエラーが表示される

➡️ これは認証情報の問題であることはめったにありません。その同じ共有先を指しているマッピングされたドライブや開いているエクスプローラーのウィンドウが接続を維持しており、それがアクティブな間は、Windows が異なる認証情報での再認証を許可しないためです。マッピングされたドライブの接続を解除し、そのパスを参照しているエクスプローラーのウィンドウをすべて閉じてから、もう一度試してください。

Q: 接続自体は問題なく行えるが、バックアップジョブ自体が、毎日使用しているフォルダに対して「アクセスが拒否されました」というエラーを返す

➡️ あなたのWindowsユーザーにはアクセス権限があります。バックアップジョブが実行されるアカウントにはアクセス権限がない可能性があります。たまたまログインしているユーザーではなく、そのパスに対する明示的な権限を持つ特定のWindowsユーザーとしてジョブを実行するように設定してください。

Q: 数週間はバックアップが正常に動作していたが、設定変更を行っていないにもかかわらず、再起動やWindowsアップデート後に停止してしまった

➡️ マップされたドライブのセッションが終了しました。マップされたドライブは、それを作成したログイン中のセッションにのみ存在するため、そのセッションをリセットする操作（再起動、ログオフ、更新）が行われると、ジョブが依存している接続が切断されます。UNCパスにはそのような依存関係がないため、最初からその方法でNASを追加することを勧めます。

Q: 停電後に「ネットワークパスが見つかりません」または「デバイスがオフラインです」というエラーでジョブが失敗する

➡️ バックアップソフトウェアの設定を変更する前に、2つの点を確認してください。まず、NASは再起動しましたか？多くのNASは、停電後にデフォルトで電源がオフのままになります。NASの管理パネルで電源復旧設定を探し、自動的に電源が入るように設定してください。次に、NASがDHCPからIPアドレスを取得している場合、ルーターまたはNASを再起動することで新しいアドレスが割り当てられることがあります。バックアップデバイスがIPアドレスで追加されていた場合、ソフトウェアは現在、応答のないアドレスを指していることになります。NASに静的IPアドレスを割り当てるか、ルーターでDHCP予約を設定してください。さらに良いのは、ホスト名（\server-name\share）でデバイスを追加することです。そうすれば、IPアドレスが変更されてもジョブが中断されることはありません。

SaaSバックアップについて

SaaSサプライチェーン攻撃とは何ですか？

これは、自社ネットワークに侵入するのではなく、信頼されているサードパーティのSaaSアプリやその認証情報を悪用して、データにアクセスする攻撃です。アプリはすでに正当なアクセス権を持っているため、攻撃者は自社のネットワーク境界に接触したり、多要素認証（MFA）をトリガーしたりすることなく、そのアクセス権を引き継ぐことができます。

なぜSaaSバックアッププラットフォームが標的となるのでしょうか？

SaaSバックアップ製品は、スケジュールに従ってデータを取得できるように、お客様の環境に対する常時有効な、高度な権限を持つ認証情報を保持しています。ベンダー自身のインフラが侵害された場合、その信頼関係は、バックアップ対象となっているすべての顧客テナントへの直接的な侵入経路となってしまいます。

IaaSバックアップとSaaSバックアップの違いは何ですか？

N2WSのようなIaaSバックアッププラットフォームは、ベンダーのクラウドではなく、お客様のクラウドアカウント内で動作します。ベンダーがホストするインフラも、盗まれる可能性のある永続的なサードパーティの認証情報も存在しないため、ベンダーが侵害されても、顧客全体に波及する被害は発生しません。

バックアップベンダーが別のアカウントにコピーを保管している場合、それはエアギャップと言えるでしょうか？

一部のみです。同じクラウド内の別のアカウントやサブスクリプションは、論理的な分離に過ぎません。依然として同じプロバイダーと制御プレーンを共有しており、ベンダーとお客様のテナントとの間の信頼関係が侵害された場合、そのコピーにもアクセス可能になります。真のエアギャップとは、コピーを完全に別のクラウドに配置することです。

エアギャップバックアップについて

不変バックアップとエアギャップバックアップは同じものですか？

いいえ。不変バックアップは、保存期間中は変更や削除ができません。一方、エアギャップバックアップは、ネットワーク経由で一切アクセスできません。これらは相互に補完し合うものであり、最も強固な構成では両方を併用します。注：不変＝イミュータブル

クラウドバックアップをエアギャップ化することはできますか？

はい。コピーを別のアカウントまたはサブスクリプションに分離し、ネットワークおよび認証情報によるアクセスをブロックし、バックアップの書き込み時のみ接続を開きます。この「同一クラウド内での隔離」が一般的なアプローチですが、N2Wでは、コピーが同じプロバイダーとコントロールプレーンを共有しているため、これを「部分的なギャップ」とみなしています。真のエアギャップを実現するには、コピーを完全に別のクラウドに配置し、別のプロバイダー、別の認証情報、別のコントロールプレーンの背後に置く必要があります。これは、クラウドにおいて物理的なエアギャップに最も近い状態と言えます。N2Wはこの手法を採用しており、クラウド間（AWSからWasabiやAzureへ）でバックアップをコピーし、お客様が所有するストレージに保存することで、ほぼ瞬時の復旧を実現しています。

論理的なエアギャップを備えた保管庫とは何ですか？

本番システムがその内容にアクセスしたり削除したりできないよう、隔離・ロック・暗号化されつつ、復旧時には利用可能な状態を維持するバックアップ・ヴォールトのことです。AWS Backupはこれをマネージド機能として提供しており、別のアカウントと不変ストレージを使用することで同様の隔離環境を構築することも可能です。ただし、これらはすべて単一のクラウド内に存在するため、N2WSはこれを真のエアギャップではなく、強力な論理的ギャップと見なしています。真のエアギャップを実現するには、コピーが保護対象のクラウドの外に出る必要があります。

エアギャップはランサムウェアを阻止しますか？

ランサムウェアがそのコピーに到達するのを阻止します。これこそがエアギャップの真の目的です。現在、ランサムウェアはバックアップを直接標的としています（Veeamによると、2025年には被害者の89％がバックアップを標的にされました）。そのため、攻撃者が手を付けられない隔離されたコピーがあるかどうかが、復旧できるか、身代金を支払うかの分かれ目となることが多いのです。

物理的なエアギャップと論理的なエアギャップ、クラウドにはどちらが適しているか？

クラウドの場合、物理テープは避けるべきです。確かにオフラインですが、復元には時間がかかり、管理コストもかかります。クラウドベースのエアギャップなら、隔離性を確保しつつ高速な復元が可能です。ただし、単一のクラウド内での隔離は部分的なエアギャップに過ぎないことを覚えておいてください。最も強力なクラウドエアギャップはクロスクラウド、つまり別のプロバイダーにコピーを置くことであり、これによりテープと同様の隔離性を維持しつつ、復元におけるパフォーマンスの低下を回避できます。


エアギャップは、単に2つ目のバックアップコピーを保持することとどう違うのでしょうか？

同じアカウント内にあり、同じ認証情報でオンライン状態の2つ目のコピーは、オリジナルと共に削除される可能性があります。エアギャップは隔離性を追加します。つまり、別のアカウントを使用し、アクセスを遮断することで、その追加のコピーは実際に攻撃者の手の届かない場所にあるのです。

エアギャップバックアップはどのくらいの頻度で更新すべきでしょうか？

必要なときに隔離されたコピーが最新の状態であるように、十分な頻度で更新する必要があります。あらゆるエアギャップにおける課題は、隔離によってコピーの更新頻度が低下してしまうことです。クラウドではこのギャップを埋めることができます。コピーを自動化することで、攻撃が発生した時点で既に古くなっている週次スナップショットではなく、常に最新かつ隔離されたバージョンが待機している状態を維持できるのです。

MySQLのバックアップのためのヒント

バイナリログを用いた特定時点への復旧（PITR）の実装：特定時点への復旧（PITR）を可能にするため、バイナリログを定期的にアーカイブし、安全に保管してください。これをフルバックアップ戦略と組み合わせることで、データベースを特定の時点に復元できます。

データベースのパーティショニングを活用してバックアップを高速化：mysqldump のような論理バックアップや MySQL Workbench などのツールは、大規模な単一テーブルよりも、小さなパーティションをより効率的に処理します。

サーバーレベルで圧縮を有効にする：ページ圧縮機能を備えた InnoDB テーブルなどの圧縮ストレージエンジンを使用するように MySQL を設定します。これにより、バックアッププロセス中に追加の手順を必要とせずに、バックアップのサイズを縮小し、ストレージコストを削減できます。

負荷管理のために専用のバックアップサーバーを使用する：スレーブサーバーへのMySQLレプリケーションを設定します。レプリカ上でバックアップを実行することで、リソースの競合を最小限に抑え、本番環境のプライマリデータベースへの影響をゼロにすることができます。

スケーラビリティのためにクラウドネイティブなバックアップソリューションを採用する：AWSやAzureなどのクラウドサービスと緊密に統合された、クラウドベースのバックアップサービスを利用します。これらのサービスは、速度とコスト効率に最適化されており、強化された災害復旧オプションを提供します。

バックアップ・プロバイダのストレージがフェイルしたら；バックアップ・データの保存先を管理しよう

ベンダーロックインはもはや過去のものとなりました。今日のサービスプロバイダにとって、コスト削減やより充実したサポートの確保、あるいは市場で優れた製品を見つけ出そうと決意すれば、代替ソリューションを見つけるのは極めて容易です。MSPは、顧客のためのバックアップおよび災害復旧（BDR）戦略を策定する際にも、同様の考え方を適用すべきです。

市場には数え切れないほどのBDRベンダーが存在しているように見えるかもしれませんが、実際にはそうではありません。たとえ市場が飽和状態にあると信じているとしても（私はこの前提には断固として反対しますが）、BDRソリューションはすべて同じというわけではありません。この分野のベンダーは類似した製品を提供していますが、そこには違いがあります。

そして、そうした違いは重要です。サービスプロバイダにとっての課題は、適切な機能を適切な価格で提供するバックアップソリューションを見つけることです。例えば、契約によるロックインはありませんか？評価中のベンダーは24時間365日のサポートを提供していますか？データ復旧についてはどうでしょうか？イメージバックアップから、個々のファイルやフォルダだけでなく、システム全体を復元することはできますか？そして最後に、データのバックアップ先として、希望するパブリッククラウドストレージプロバイダーを自由に選択できますか？

バックアップにおけるパブリッククラウドストレージのメリット

最後の点について少し触れたいと思います。これは、Climb Cloud Backup(CCB)が、今日の市場においてサービスプロバイダ向けの最高のマネージド・バックアップ・ソフトウェアであると考える多くの理由の一つだからです。

簡単に言えば、Climb Cloud Backup(CCB)は「BYOS（Bring-Your-Own-Storage）」の原則を採用しています。つまり、サービスプロバイダは独自のストレージソリューションに縛られることなく、AWS Amazon S3、Microsoft Azure Blob Storage、Wasabiなど、多種多様なサードパーティ製クラウドストレージリソースから自由に選択できるのです。クラウドストレージとバックアップソフトウェアを切り離すことで、Climb Cloud Backup(CCB)はサービスプロバイダがバックアップの保存先を自由に制御できるようにします。これにより、クラウドバックアップストレージの選択肢において自由度が高まります。

BYOSがサービスプロバイダに提供するこの柔軟性により、長期的に見て顧客にとってより良い判断を下すことが可能になります。あるクラウドストレージプロバイダーが競合他社よりも優れた価格設定や機能セットを提供している場合、サービスプロバイダは簡単に切り替えを行うことができます。バックアップソフトウェアがクラウドストレージと紐付けられているという理由だけで、顧客が特定のプロバイダーに縛られることはありません。しかし、多くの場合、クラウドベースのストレージだけでは不十分です。

ローカルバックアップの重要性は依然として高い

もちろん、速度とセキュリティは、データをローカルに保存する主な利点の一部です。Climb Cloud Backup(CCB)を利用すれば、サービスプロバイダは、ネットワーク接続ストレージ（NAS）デバイスやネットワーク共有など、ローカルストレージオプションに顧客データをバックアップできます。これにより、サービスプロバイダにはさらに大きな自由度がもたらされます。繰り返しになりますが、サービスプロバイダは特定の保存場所を強制されることなく、顧客データをローカルで保存する場所を自由に選択できます。

しかし、サービスプロバイダはクラウドとローカルストレージのどちらか一方を選ばなければならないわけではありません。Climb Cloud Backup(CCB)を使用して顧客データをバックアップする際、サービスプロバイダはハイブリッド方式を選択することも可能です。これは、多くのサービスプロバイダが実践している「3-2-1バックアップルール」に従う場合に、当然ながら非常に役立ちます。カスタマイズは顧客満足度の向上にもつながり、ひいては貴社の収益増加にも寄与します。絶えず変化し続けるIT脅威の環境において、顧客のためにBDR戦略をカスタマイズすることは、顧客を保護するための鍵であることに疑いの余地はありません。

選択可能なBDRソリューションは数多く存在します。それならば、顧客のためにより良い意思決定を行うために必要な自由度を提供しないソリューションに、なぜ妥協する必要があるのでしょうか？

バックアップが実際に機能しているかどうか、どうすれば確認できますか？

復元テストを実行してください。バックアップジョブが完了することと、実際にデータを復元できることは別物です。毎月、サンプルファイルを復元して、データが損なわれていないことを確認するテストをスケジュールに組み込んでください。3カ月に1回は、実際の復旧シナリオをシミュレートした本格的なテストを実施してください。その結果を記録に残してください。その記録こそが、保護が機能していることの証拠となります。

「3-2-1バックアップルール」とは何でしょうか？

データを3つのコピーに保存し、2種類の異なるストレージに分散させ、そのうち1つのコピーをオフサイトに保管するというルールです。これは、ハードウェアの故障、ランサムウェア、火災、洪水など、いかなる単一の障害が発生しても、3つのコピーすべてが同時に失われることはないため、基本的な基準となっています。ランサムウェアの脅威にさらされている企業の場合、オフサイトのコピーを不変化しておけば、たとえネットワークが侵害されたとしても、攻撃者がそのコピーにアクセスしたり削除したりすることはできなくなります。

増分バックアップ、差分バックアップ、および「インクリメンタル・フォーエバー」バックアップの違いは何ですか？

これら3つはいずれも、毎回フルバックアップを実行する必要がないという点では共通していますが、バックアップの対象となる内容に違いがあります。増分バックアップは、前回のジョブ以降に変更された部分のみを保存するため、各バックアップのサイズは小さくなりますが、バックアップの連鎖が長くなるにつれて復元にかかる時間が長くなります。差分バックアップは、前回のフルバックアップ以降に変更されたすべてのデータを保存するため、復元には前回のフルバックアップと最新の差分バックアップの2つのファイルだけで済みますが、新しいバックアップを作成するたびにストレージ容量の需要が増加します。インクリメンタル・フォーエバー・バックアップは、これら2つの方式の長所を組み合わせ、短所を排除したものです。これにより、ストレージ容量を最小限に抑えつつ、任意の時点からの高速な復元が可能になります。

バックアップを実行すると、従業員のパソコンの動作が遅くなりますか？

業務時間中にバックアップをスケジュールした場合や、毎回処理に時間がかかるフルバックアップを行う場合は、遅くなる可能性があります。午後2時に実行される大規模なバックアップジョブは、チームが日常的に利用しているネットワーク帯域幅を奪ってしまいます。バックアップを夜間や週末にスケジュールするか、「Incremental Forever」のように毎回バックアップ時間を短く抑える方法を採用すれば、従業員は全く影響を感じることなく利用できます。

ソフトウェアの設定が正しく行われている場合でも、ストレージハードウェア自体の問題によってバックアップが失敗することはありますか？

はい。ソフトウェアの観点からはエラーなくバックアップジョブが完了したように見えても、その裏でストレージデバイスが書き込まれているデータを目立たない形で破損させている可能性があります。老朽化したNASデバイス、性能が低下したディスク、容量限界に近づいているボリュームなどは、いずれもバックアップジョブのログには表れないストレージ層での障害を引き起こす要因となります。定期的なストレージの健全性チェック、デバイスログの確認、利用可能容量の監視は、SP（サービスプロバイダ）が定期的なバックアップレビューに含めるべき項目の一部です。バックアップソフトウェアの信頼性は、書き込み先のハードウェアの信頼性に左右されます。

保存期間が短すぎるポリシーと長すぎるポリシーの違いは何ですか？

保存期間が短すぎると、必要になる前に古い復元ポイントが削除されてしまいます。ランサムウェアへの感染はすぐには発見されないことが多く、攻撃からの復旧には、侵害が発生する前の正常な状態の復元ポイントが必要となります。保存期間が短すぎると、ストレージ容量が予想以上に急速に増加し、容量が不足するとバックアップジョブが失敗したり、ストレージコストが不必要に高くなったりする可能性があります。保存期間は、バックアップソフトウェアのデフォルト設定のままにせず、実際の復旧シナリオや適用されるコンプライアンス要件に基づいて設定する必要があります。

SQLデータベースのバックアップは、通常のファイルのバックアップとはなぜ異なるアプローチが必要なのでしょうか？

SQLデータベースは、絶えずデータの読み取りと書き込みを行っています。稼働中にファイルを直接コピーすると、一貫性のない状態のバックアップが作成される可能性があります。つまり、トランザクションの途中でファイルがキャプチャされてしまい、正常な復旧には使用できなくなるということです。アプリケーション対応のバックアップでは、VSS（ボリュームシャドウコピーサービス）または専用のデータベースエージェントを使用して、書き込みを一時的に停止し、一貫性があり復元可能な状態でデータベースをキャプチャします。これを行わない場合、会計システム、CRM、在庫管理プラットフォームなどの業務アプリケーションのバックアップは、一見完了しているように見えても、復元を試みた際に完全に失敗する可能性があります。

ファイルを新しいフォルダに移動した場合、バックアップされたデータはどうなるのでしょうか？

バックアップジョブは、特定のソースパスを保護します。ファイルサーバーの再編成が行われたり、データが新しい共有フォルダに移動されたり、ユーザーが監視対象のディレクトリ外にファイルを保存したりした場合でも、バックアップジョブは元の場所に対して実行され続けます。新しい場所は決してバックアップの対象にはなりません。ジョブは正常に完了したため、ステータスは緑色で表示されます。しかし、新しい場所にはデータが存在しないのです。ファイルの移動は、その場では些細なことのように感じられ、アラートも発生しないため、これはSMB環境において最も一般的なバックアップ設定ミスの一つとなっています。

認証エラーによって、バックアップが何の前触れもなく失敗するのはなぜですか？

サービスアカウントのパスワードの有効期限が切れたり、ネットワーク共有のアクセス権が変更されたりすると、バックアップジョブは保護対象のディレクトリにアクセスできなくなります。ほとんどの場合、ジョブは完全に停止することはありません。アクセス可能な範囲のバックアップは継続され、ダッシュボード上には明らかなエラーが表示されないまま、部分的なバックアップが生成されます。この欠落は、復元を試みた際に、失われたデータが存在しないことが判明して初めて明らかになります。SP（サービスプロバイダー）は、ローテーションスケジュールが文書化された専用のサービスアカウントを使用し、次回の手動確認を待つのではなく、アクセスエラーが発生した時点で即座にアラートを発信することで、この問題を回避しています。

バックアップジョブが「成功」と表示されていても、復元時に失敗することはありますか？

はい。バックアップジョブは、プロセスが完了したかどうかに基づいて完了を報告するものであり、取得したデータが実際に復元可能かどうかを判断するものではありません。書き込み処理中にファイルが破損したり、データベースが不整合な状態で取得されたり、ソースパスで重要なフォルダが検出されずに見落とされたりしても、ジョブは「成功」ステータスを表示し続ける可能性があります。バックアップが復元可能であることを確認する唯一の確実な方法は、実際に復元テストを実行し、復元されたデータが完全で利用可能であることを検証することです。

不変のバックアップコピーとは何ですか？

不変のバックアップコピーは、設定された保持期間内において、管理者権限を持つユーザーであっても変更や削除を行うことができません。これにより、本番データを暗号化する前にバックアップコピーを破壊しようとするランサムウェアや、誤って、あるいは悪意を持って行われる削除からデータを保護します。不変性は通常、S3互換のクラウドストレージにおけるオブジェクトロックによって実装されます。

「3-2-1のルール」はランサムウェアからデータを保護できるのでしょうか？

オフサイトのバックアップが適切に隔離されていれば、可能です。現在、ランサムウェアはネットワーク全体で暗号化を開始する前に、まずバックアップファイルを標的とするのが常となっています。本番データと同じネットワーク上に保存されたバックアップは、攻撃者からアクセスされてしまいます。一方、ネットワークから隔離され、バージョン管理された状態で維持されているオフサイトのバックアップがあれば、データが完全に暗号化されてしまった場合でも、安全な復元ポイントとして活用できます。

中小企業はどのくらいの頻度で復元テストを実施すべきでしょうか？

少なくとも、最も重要なデータについては四半期に1回は実施してください。復元テストとは、単にバックアップジョブがエラーなく完了したかを確認するだけでなく、実際にデータをテスト用保存先に復元し、データが完全に復元され、利用可能であることを確認することを指します。直近のテストから6ヶ月以上経過している場合は、今すぐ実施するようにスケジュールを組んでください。

クラウドバックアップとクラウド同期の違いは何ですか？:3-2-1バックアップ・ルール

DropboxやOneDriveのようなクラウド同期ツールは、ファイルの現在の状態をそのまま反映します。ファイルが暗号化されたり削除されたりすると、その変更は即座に同期され、以前の状態が上書きされます。一方、クラウドバックアップは、バージョン管理された特定の時点のスナップショットを保持するため、問題が発生する前の状態に復元することができます。「3-2-1のルール」において、要件を満たすのはクラウドバックアップのみです。同期機能では要件を満たしません。

オフィスにあるNASデバイスは、「3-2-1のルール」を満たしているでしょうか？

NASは「2種類のメディア」という要件を満たすことができます。しかし、主要なデータと同じ建物内に設置されている場合、「1つのオフサイトコピー」という要件は満たせません。オフィス内のNASはローカルバックアップであり、オフサイトバックアップではありません。オフサイトコピーを確保するには、物理的に別の場所にあるものが必要です。ほとんどの中小企業の場合、それはクラウドバックアップを意味します。

クラウドストレージはオフサイトバックアップとして扱えますか？:3-2-1バックアップルール

はい、バージョン管理された特定の時点のコピーを保持できる、専用のクラウドバックアップストレージであれば可能です。ファイルをリアルタイムで同期する一般的なクラウドストレージフォルダは該当しません。ランサムウェアによってファイルが暗号化され、同期が有効になっている場合、暗号化されたバージョンがすぐに正常なコピーを上書きしてしまいます。クラウドバックアップには複数の復元ポイントが保持されるため、インシデント発生前の状態から復旧することができます。

適切なWindowsサーバーバックアップと信頼できるWindowsサーバーバックアップ⤵️を分ける2つの仕組み

1. VSS(ボリュームシャドウコピーサービス):開いているファイルやロックされたファイルの一貫したスナップショットを調整します。SQLデータベース、Exchangeストア、Hyper-V VM、アプリケーションが開いているものはすべてです。VSS連携がなければ、バックアップツールはファイルをスキップするか、一貫性のない状態で記録してしまいます。これにより、メンテナンスウィンドウなしでアプリケーションに一貫したリカバリーポイントが得られます。

 

2. ブロックレベルの増分バックアップ:初期のフル以降の変更されたファイル部分のみを転送します。日々の変動が控えめな大規模なデータベースやVMのディスクイメージでは、1日の転送サイズが大幅に小さく、ストレージの増加がより予測可能になります。

 

クライムの製品群は、対応されたワークロードと構成の両方に対応しています。忙しいWindowsサーバーを管理するITチームにとって、これは技術的に実行されるバックアップジョブと効率的に使えるリカバリーポイントを生成するジョブの違いです → https://www.climb.co.jp/soft/

Zerto のLTR(長期保持)について

Zerto LTR(長期保持)は、従来のDRを超えて以下を可能にします:

 

✔ CDPによるほぼリアルタイムのリカバリー
✔ コンプライアンスのための長期バックアップ保持
✔ 不変バックアップオプション
✔ エアギャップされたサイバーリカバリー
✔ クラウドストレージとオブジェクトストレージの統合
✔ グラニュラーファイルまたは完全なVMリカバリー

 

実数値は以下の組み合わせです:

ジャーナルを用いたセカンドレベルロールバック

長期的な関係を使った月・年の保持

DR+バックアップワークフローを横断した統一管理

 

現代のサイバーレジリエンスはもはやバックアップだけにとどまりません。継続的な回復+長期保持+ランサムウェア耐性を一つのプラットフォームに統合することに関するものです。

 

ランサムウェアの脅威が進化する中で、組織は運用のサイロを減らしつつ、回復成果を向上させるプラットフォームをますます求めています。

画像を表示

Object Lock(オブジェクトロック)について

Object Lockとは

Object Lockは、ストレージ内のバックアップデータに時間ベースのロックをかけます。バックアップがそのロックの対象となっている場合、ロック期間が終了するまで変更や削除を行うことはできません。その基盤となる仕組みはWORM（Write Once, Read Many）であり、ロックが有効な間はバックアップデータをいつでも読み取り・復元することはできますが、変更や削除はできないことを意味します。

 

ただし、すべてのバックアップが自動的に不変になるわけではありません。MSP360 Backupでは、各ストレージ先ごとにObject Lockと保存期間の設定を行う必要があります。具体的な要件は、使用しているバックアップフローによって異なります。

 

Object Lockが重要な理由

バックアップの作成は作業の半分に過ぎません。Object Lockは事後的にバックアップを保護し、復旧が必要な際にバックアップデータが信頼性が高く、利用可能な状態であることを保証します。 バックアップデータは、複数の要因によって失われる可能性があります。

 

ランサムウェア

ランサムウェアの攻撃は、必ずしも本番システムだけで止まるわけではありません。バックアップデータも標的となり得ます。不変性（Immutability）は、ランサムウェア、無断アクセス、人的ミスに対する強力な保護層となります。ロック期間中に保護されたバックアップデータが変更または削除できない場合、復旧用に確実に手つかずのコピーが常に確保されます。

 

誤削除

破壊的な事象のすべてが悪意によるものとは限りません。過度に厳格なポリシー、誤ったデータの削除、予期せぬストレージ側の変更など、いずれもバックアップデータを危険にさらす可能性があります。Object Lock は、選択されたバックアップデータを設定された期間保護し続けることで、そのリスクを軽減します。

 

保存期間、法的要件、およびコンプライアンス要件

ポリシー、法的要件、または規制により、一部のバックアップデータは特定の期間、そのままの状態を維持する必要があります。Object Lock はこうしたケースに最適であり、より厳格な適用が求められる環境向けに、さまざまな保存モード（厳格なコンプライアンスモードを含む）をサポートしています。

 

MSP360 Backup with Object Lockによる不変バックアップ保護についてはこちら

3-2-1 バックアップ・ルール

ほとんどのバックアップ戦略が失敗するのは、バックアップを完全にスキップするからではなく、すべてを同じ場所に保存しているからです――一つの場所、一つの媒体、一つの障害点に。

3-2-1バックアップルールはまさにそれを解決するために設計されました。

仕組⤵️みはこうです

✔️ データのコピーは3枚、オリジナルは1枚、バックアップは2枚です。もし1つが失敗しても、さらに2つから回復しなければなりません。

✔️ 例えば、ローカルストレージとクラウドストレージの2種類があります。それぞれの媒体には独自の故障プロファイルがあり、それらを組み合わせることで単一の媒体だけのリスクがなくなります。

✔️ 1つのコピーはオフサイトに、物理的または論理的にあなたのメイン環境から分離されています。これは、火災、洪水、ランサムウェアなど、ローカルネットワーク全体に何かが襲いかかるときの安全網となります。

ルールはシンプルですが、それをスキップした企業は何か問題が起きたときに慌てて対応します。だからこそ、企業のIT管理やクライアントと仕事をする人にとっては、インシデントの前に話し合う価値があるのです。