当ブログ訪問者限定!3ヶ月無料+3年間プランが10%オフ! YSBLOG10
取引を掴む

3-2-1バックアップルールとは?定義、メリット、そして重要性について解説します。

最終更新日:September 7、2026 所要時間 YouStable
3-2-1バックアップルール

3-2-1バックアップルールは、実績のあるデータ保護戦略です。データを合計3つのコピーとして保持し、2種類の異なるメディアに保存し、さらに1つのコピーをオフサイトに保管します。この多層的なアプローチにより、単一障害点のリスクを軽減し、ランサムウェアや災害からデータを保護して、復旧の信頼性を向上させます。シンプルでベンダーに依存せず、家庭ユーザー、企業、クラウドワークロードなど、あらゆる環境に対応できるため、ITおよびサイバーセキュリティ分野で最も広く推奨されているバックアップの基本原則となっています。

データ損失は決して計画できるものではありませんが、予測は可能です。ドライブの故障、人為的なミス、ランサムウェアの拡散、クラウドアカウントの侵害など、様々な事象が発生します。3-2-1バックアップルールは、こうした障害を予測し、迅速な復旧を可能にする体系的な方法を提供します。このガイドでは、3-2-1ルールの意味、その有効性、オンプレミス環境とクラウド環境における実装方法、そして今日の脅威からデータを保護する最新のバリエーションについて解説します。


3-2-1バックアップルールとは何ですか?

3つのコピーにより、デバイスの故障やユーザーの操作ミスから保護しつつ、復元作業を複雑化させません。2種類の異なるメディアを使用することで、相関リスクを回避し、オフサイトコピー1つで災害の影響を軽減します。

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

3-2-1バックアップルールの核心は、冗長性と多様性を確保することです。「3つのコピー」とは、本番データと少なくとも2つの追加バックアップを意味します。「2つのメディア」とは、単一の共有障害モードを回避するために、バックアップを異なるストレージ技術(ローカルNASとクラウドオブジェクトストレージなど)に保存することを意味します。「1つのオフサイト」は、火災、洪水、盗難、またはローカルランサムウェア攻撃によって主要な拠点が侵害された場合でも、コピーが安全に保管されることを保証します。


各要素を分解して

3つのコピーは、1つのバックアップが破損しても保護機能を維持できる最低限の冗長性です。最新のバックアップが破損または不完全な場合でも、2番目のバックアップは引き続き使用できます。複数の復元ポイントを維持することで、以前の状態にロールバックすることにより、論理的な破損(誤って大量のデータを削除した場合など)からの復旧もサポートされます。

2種類のメディアを使用することで、システムリスクを軽減できます。例えば、内蔵SSDと外付けHDDの組み合わせ、ローカルNASとLTOテープの組み合わせ、オンプレミスのブロックストレージとS3互換オブジェクトストレージの組み合わせなどが挙げられます。これは、すべてのコピーで同じように障害が発生する可能性のある、単一のベンダー、ファイルシステム、またはプロトコルへの依存を回避することを目的としています。

オフサイトコピーを1つ確保することで、サイト全体のインシデントからデータを保護できます。これは、地理的に離れたデータセンター、クラウドリージョン、または物理的に外部に保管されたテープなど、さまざまな場所に設置できます。クラウド時代においては、「オフサイト」とは通常、異なるプロバイダーのアカウントとリージョンを意味し、理想的には不変性が有効になっていることが望ましいです。


3-2-1ルールが重要な理由

現代の脅威は、中央集権化と利便性を悪用する。バックアップは、バランスと制御を取り戻す。

3-2-1は、ダウンタイムを削減し、経済的損失を抑制し、サイバーセキュリティの回復力を強化します。

運用面から見ると、3-2-1ルールは複数の障害領域におけるリスクを直接的に低減します。ハードウェアの故障、ユーザーによるデータの削除、ソフトウェアのバグによるデータ破損、攻撃者によるデータの暗号化、自然災害による機器の破壊など、様々なリスクが考えられます。データのコピーと保存場所を分散させることで、これらのリスクを抑制し、常に有効な復旧経路を確保できます。これは、事業継続計画と災害復旧計画の根幹をなすものです。

測定可能な主なメリット

復旧時間目標(RTO)の短縮:高速メディアにローカルバックアップを作成することで、一般的なインシデントに対して迅速な復旧が可能になり、一方、低速なオフサイトコピーはサイトレベルの災害からデータを保護します。このバランスにより、コストとパフォーマンスを最適化できます。

リカバリポイント目標(RPO)の改善:複数のコピーと保持ポイントにより、インシデント発生直前の時点に復元できるため、データの再作業や損失を最小限に抑えることができます。増分バックアップスケジュールにより、RPOを数分に短縮できます。

ランサムウェア対策:マルウェアが本番環境やローカルストレージに到達した場合、オフサイトの(理想的には改ざん不可能な)バックアップが攻撃の連鎖を断ち切ります。これは、エンドポイントやネットワーク制御が機能しなくなった場合の最後の防衛線となります。

コンプライアンスへの対応:ISO 27001、SOC 2、HIPAA、GDPRなどのフレームワークでは、適切なバックアップ、オフサイトコピー、暗号化、およびテスト済みの復元が求められます。3-2-1は、これらの要件を満たすための実用的で監査可能な方法です。


3-2-1の実際の仕組み

重要なデータから始め、RPO/RTOを定義し、ソースをストレージとスケジュールにマッピングします。

速度重視で高速なローカルバックアップを1つ、耐障害性重視でオフサイトコピーを1つ使用し、復元が成功することを確認してください。

実装は、簡単なインベントリ作成から始まります。データセット(データベース、仮想マシン、ファイル共有、SaaSエクスポート、WordPressサイトなど)を特定し、重要度を分類し、ワークロードごとに許容可能なRPO/RTOを定義します。次に、これらの目標に適合するツールとストレージを選択します。ほとんどの中小規模環境では、この結果、ハイブリッドアプローチが採用されます。つまり、高速な復元のためにNASにローカルバックアップを作成し、オフサイト保護のためにクラウドコピーを作成します。

例:WordPressと中小企業のウェブサイト

WordPressサイトの場合、3つのコピーを保持してください。本番環境のファイルとデータベース、ホスティングサーバーまたは接続されたNAS上の毎晩のローカルバックアップ、そしてオブジェクトロック付きのS3互換ストレージへのオフサイトバックアップです。UpdraftPlusやJetBackup(ホスティングプロバイダーが提供している場合)などのプラグインを使用して、毎日の増分バックアップと毎週のフルバックアップをスケジュール設定してください。ゆっくりと進行する破損から復旧できるよう、少なくとも14~30日間のデータを保持してください。

もしあなた プロバイダーとホスト ような YouStableプラットフォームのバックアップと独自のオフサイトコピーを組み合わせることができます。cPanelのバックアップをリモートの宛先(S3、Backblaze B2、または別のリージョン)に有効にし、定期的にステージングサブドメインへのテスト復元を実行します。これにより、本番稼働時間を危険にさらすことなく、整合性と手順の両方を検証できます。

例:仮想マシンとデータベース

VM の場合は、ハイパーバイザーに統合されたバックアップ (Veeam、Nakivo、Proxmox Backup Serverなど) を使用して、アプリケーションと整合性のあるスナップショットを取得します。プライマリ バックアップ リポジトリは、高速なリストアのためにローカルの重複排除ストレージに保持し、バックアップは不変性を備えたオブジェクト ストレージにオフサイトで複製します。データベースの場合は、可能な限り、論理ダンプ (mysqldump、pg_dump) とボリューム レベルのスナップショット、および定期的なポイント イン タイム リカバリを組み合わせて使用​​します。

スケジュールは通常、日次増分データと週次フルデータ、ローカルでの30~90日間のデータ保持期間、オフサイトでの90~365日間のデータ保持期間で構成されます。オフサイトでの長期データ保持期間は、コンプライアンスまたはビジネスニーズに合わせて調整してください。まれではあるものの深刻な事態が発生した場合に備え、より多くの復旧ポイントを提供できるよう、週次および月次のフルデータ保持期間をずらすことを検討してください。


3-2-1 vs. 3-2-1-1-0:現代版

脅威が進化するにつれて、このルールには不変性と検証という新たな要素が加わった。

3-2-1-1-0は、オフライン/不変のコピーを1つ追加し、バックアップ検証エラーをゼロにすることを目指します。

3-2-1-1-0モデルは、元のモデルに、1つのコピーを完全にオフラインまたは不変にする必要があるという要件を追加したものです。オフラインとは、オフサイトに保管されたテープなどが考えられます。不変とは、S3 Object Lock、Azure Immutable Blob Storage、Wasabi Object Lockなど、書き込みは一度、読み取りは複数回(WORM)保持期間を持つクラウドオブジェクトストレージなどが考えられます。「0」は検証の重要性を強調しており、バックアップがエラーなく完了し、テスト復元が成功することを確認します。

3-2-1-1-0を採用するタイミング

ランサムウェアのリスク、コンプライアンス要件、または高価値データの漏洩に直面している場合は、今すぐ不変性を導入してください。多くの中小企業にとって、オブジェクトロックを有効にすることは、テープの管理よりも簡単です。多要素認証と個別のクラウドアカウントを組み合わせることで、単一の認証情報が漏洩した場合にすべてのコピーが削除される可能性を低減できます。

定期的な復元テストを実施しましょう。四半期ごとの完全復旧テストと月ごとのスポットチェック復元が現実的な基準となります。結果を記録し、復元の遅延やエラーがあれば修正してください。バックアップの目的は復元であり、検証によってそれが実現します。


バックアップメディアとストレージの選択

各記憶媒体には、コスト、速度、耐久性、運用上のトレードオフがそれぞれ異なる。

迅速なローカル復旧と耐久性の高いオフサイトストレージを組み合わせることで、RTO(目標復旧時間)と耐障害性の両方を満たすことができます。

一般的なメディアオプション

ローカルNASまたはDAS HDD:手頃な価格で大容量を実現し、高速な復元と短いRTOに適しています。可用性を高めるためにRAIDと組み合わせることもできますが、RAIDはバックアップではないことに注意してください。より安全なロールバックには、スナップショットとバックアップを併用してください。3-2-1構成でのオンサイトコピーに適しています。

クラウドオブジェクトストレージ(S3/B2):高い耐久性(9

LTOテープ:エアギャップ、長期保存、コスト効率の高い大規模アーカイブに最適です。アクセス速度が遅く、運用コストが高くなります。大規模なデータセットと厳格な保持ポリシーを持つ組織に最適です。 manage 取り扱いと跳躍。

目的地とアカウントの選択

アカウントを分離してください。オフサイトバックアップは、単に別のバケットではなく、別のクラウドアカウントまたはテナントに保存してください。MFAと限定的なIAMロールを適用してください。オンプレミスからクラウドへのトラフィックはTLS経由でルーティングし、セキュリティ強化のためにクライアント側暗号化を検討してください。

ランサムウェア対策として、オブジェクトロック機能を備えたストレージを優先的に利用しましょう。多くのS3互換プロバイダーはWORM(Worm-Oriented Logistics:ランサムウェア)によるデータ保持をサポートしています。重要なデータセットには法的保留期間を設定し、定期的なバックアップには時間ベースの保持期間を設定することで、コンプライアンスとコストのバランスを取りましょう。


バックアップとスナップショット、RAID、同期の比較

すべてのコピーがバックアップになるわけではありません。誤った安心感を避けるためにも、違いを理解しておきましょう。RAID、スナップショット、同期はすべて役立ちますが、3-2-1バックアップ戦略に取って代わるものではありません。

バックアップとスナップショット、RAID、同期の比較

RAIDはディスク障害に対する耐性を高めることで可用性を向上させますが、データの破損や削除もミラーリングします。スナップショットは同一システム上の特定時点のデータであり、ロールバックには高速ですが、本番環境と同様の脅威にさらされます。ファイル同期(クラウドストレージなど)は、デバイス間で変更内容(ミスやマルウェアを含む)を複製します。バックアップは、保持ポリシーと検証機能を備えた、独立したバージョン管理された、理想的には不変のコピーを作成します。


3-2-1バックアッププランの設計

実践的な計画は、現状把握から始まり、検証済みで文書化された復旧作業で完了する。

メンテナンスはシンプルに。最高のバックアップとは、確実に復元できるバックアップのことです。

ステップバイステップのチェックリスト

  • 在庫データソース: サーバー、データベース、仮想マシン、エンドポイント、SaaSエクスポート、およびウェブサイト。
  • データを分類する: 重要、重大、アーカイブ。各クラスのRPO/RTO目標値にマッピングします。
  • メディアを選択: 速度重視ならローカルNASまたはリポジトリ、オフサイトでの耐久性重視ならクラウド/テープ。
  • ツールを選択してください: VM向けのハイパーバイザー対応バックアップ、データベース向けのアプリケーション対応バックアップ、CMS向けのプラグイン。
  • スケジュールを定義する: 日次増分、週次総額。変化率とリスクに基づいて調整する。
  • セット保持: オンサイトでの作業期間は30~90日間、コンプライアンスおよびロールバック時の安全性確保のため、オフサイトでの作業期間は90~365日以上となります。
  • セキュリティを有効にする: 転送中/保存時の暗号化、オブジェクトロック、多要素認証、アカウントの分離。
  • 検証を自動化: バックアップレポート、チェックサム検証、および復元テスト。
  • 文書化手順: データの保存場所、復元方法、連絡先、認証情報のエスクロー。
  • 四半期ごとのレビュー容量増加、コスト、復旧時間、および新しいデータソース。

スケジュール管理と定着率向上に関するヒント

パフォーマンスへの影響を避けるため、バックアップはピーク時間帯を避けて実行してください。帯域幅とI/Oをスムーズにするため、システム間でジョブのタイミングをずらしてください。変更頻度の高いデータセット(データベースなど)の場合は、ストレージ容量を大幅に増やすことなくRPOを向上させるため、増分バックアップまたはトランザクションログバックアップの頻度を増やすことを検討してください。

データ保持期間はリスク判断です。保持期間を長くすれば、巧妙な攻撃を受けた後の復旧オプションは増えますが、コストも増加します。段階的な保持期間を設定しましょう。例えば、過去1週間は頻繁にバックアップを取り、1か月間は毎日、3か月間は毎週、1年間は毎月、そして規制で義務付けられている場合は7年間は毎年バックアップを取るようにします。

サイジング、パフォーマンス、およびコスト計画

作業の失敗や予期せぬ請求を避けるため、事前に容量と帯域幅を見積もっておきましょう。

重複排除、圧縮、ライフサイクルポリシーを活用して、ストレージコストを最適化しましょう。

キャパシティプランニングの基本

ソースデータのサイズ、日々の変更率、および必要な保持期間を計算します。たとえば、2 TB のデータと 3% の日々の変更率の場合、30 日分の増分データと毎週のフルデータには、およそ 2 TB (フル) + (0.03 × 2 TB × 30) + 週ごとのオーバーヘッドが必要となり、その後、圧縮/重複排除率 (コンテンツに応じて 1.5 ~ 3 倍の削減となることが多い) を適用します。

成長によってジョブが中断されないよう、20~30%の余裕を持たせてください。オフサイトの場合は、初回実行時間が長くなるのを避けるため、シードオプション(出荷済みディスクへの初期バックアップ、または一時的に帯域幅を高くするウィンドウ)を検討してください。

ネットワークとパフォーマンスの復元

バックアップウィンドウは、最も遅いリンクによって制限されます。RTOを短縮するには、LAN速度のバックアップを使用してローカルリポジトリに保存してください。オフサイトレプリケーションは、WANリンクの飽和を避けるために、速度を制限して継続的に実行できます。リストアの際は、まず重要なサービスをリストアすることを優先し、完全なリストアが完了するまでの間、バックアップストレージから直接VMを起動する「インスタントリカバリ」機能の使用を検討してください。

コスト調整のための手段

ライフサイクルポリシーに基づいて、データ保持とコストのバランスを取りましょう。速度を重視して最新のバックアップは標準ストレージに保持し、古いバックアップはより低コストなストレージに移動します。データ転送料金に注意し、必要なものだけを取得するようにリストアを設計します。アップロード前に圧縮し、不要なデータ(キャッシュ、一時ファイルなど)はバックアップから除外します。


セキュリティとコンプライアンスの考慮事項

バックアップは非常に価値の高い標的です。本番環境と同様に、あるいはそれ以上に安全に保護する必要があります。

暗号化を行い、アクセスを最小限に抑え、職務を分離し、すべての情報をエンドツーエンドでログに記録する。

転送中(TLS)と保存時の暗号化を実装します。クラウドバックアップの場合は、顧客設定によるサーバー側暗号化を選択します。 manageより厳格な制御のために、dキーまたはクライアント側暗号化を使用します。IAMロールを最小権限に制限し、MFAを使用し、バックアップ管理を本番環境の管理者から分離することで、内部リスクを軽減します。

バックアップジョブ、削除、保持期間の変更、復元操作に関する監査ログを維持してください。規制対象データについては、保管履歴と保持スケジュールを文書化してください。GDPR(消去権とコンプライアンス保持)、HIPAA(完全性と可用性)、および業界固有の基準に基づく義務を遵守していることを確認してください。

避けるべき一般的な間違い

些細な見落としが積み重なり、復旧作業の失敗につながります。こうしたよくある落とし穴を避けましょう。技術だけでなく手順もテストすることで、人的ミスや複雑な状況にも対応できる設計を心がけましょう。

  • RAIDやスナップショットだけに頼る場合: それらは削除やマルウェアから保護するものではありません。
  • ベンダー1社、アカウント1つ: 認証情報が漏洩すると、すべてのコピーが削除される可能性があります。
  • 復元テストなし: 検証されていないバックアップは、最も必要な時に限って失敗することが多い。
  • 不十分な人材維持計画: 短すぎると復旧の選択肢が失われ、長すぎると予算が無駄になる。
  • すべてをバックアップする: 必要なものだけを含め、キャッシュ、一時ファイル、ログなどの不要なファイルは除外してください。
  • 暗号化されていないバックアップ: 転送中または保存中の機密データは、コンプライアンス違反および情報漏洩のリスクとなる。
  • バックアップをオンラインに残しておくこと: 不変性がなければ、ランサムウェアはバックアップデータも暗号化してしまう可能性があります。

3-2-1に適合するツールとワークフロー

ワークロードを理解し、オフサイトレプリケーションをサポートするツールを選びましょう。

不変性、検証機能、そして容易で文書化された復元機能を備えたソリューションを優先する。

ウェブサイトとWordPress向け

ホスティングネイティブバックアップ(cPanel/WHM or Pleskさらに、より詳細な制御を可能にするプラグインも用意されています。データベースのダンプとファイルのバックアップを毎日スケジュール設定し、オブジェクトロックを使用してS3互換ストレージにレプリケーションを行い、ステージングサイトへの復元テストを実行します。ホスティングプロバイダーがJetBackupなどのバックアップツールを提供している場合は、リモート宛先とメールレポートを有効にして可視性を確保してください。

として ホスティングプロバイダ, YouStable 顧客は、cPanel のバックアップを外部 S3 バケットおよび MFA で保護された認証情報と組み合わせて使用​​することがよくあります。これにより、オーバーヘッドを最小限に抑えながら 3-2-1 に準拠し、復元が簡単になります。 control panel またはプラグインインターフェース。

サーバー、仮想マシン、データベース向け

VM対応ツール(Veeam、Nakivo、Proxmox Backup Serverなど)は、アプリケーション整合性のあるバックアップと即時リカバリを提供します。データベース対応ツール(ネイティブダンプ、WAL/リドゥログバックアップなど)は、特定時点へのリカバリを向上させます。ローカルリポジトリとオブジェクトストレージレプリケーションを組み合わせます。定期的なフルバックアップ、頻繁な増分バックアップ、および自動整合性チェックを有効にします。

オープンソースとCLIワークフロー

BorgBackup、Restic、Duplicatiといったツールは、重複排除、暗号化、S3バックエンドをサポートしています。Rcloneは、暗号化されたアーカイブをクラウドストレージに複製し、チェックサムを検証できます。これらは、移植性と透明性を重視する技術チームにとって非常に優れたツールです。


Linux向けオフサイトバックアップスクリプトのサンプル

暗号化され、バージョン管理されたバックアップを検証機能付きでS3互換ストレージに自動的に保存します。cronを使用して、日次増分バックアップと週次フルバックアップをスケジュール設定し、メールによるレポート機能も利用できます。

# Requires: borg, rclone, gpg (optional), mailx
# Local repo for fast restores
export BORG_REPO=/backup/borg-repo
export BORG_PASSPHRASE='change-me'

# 1) Create incremental backup locally
borg create --stats --compression lz4 
  $BORG_REPO::'{hostname}-{now:%Y-%m-%d_%H-%M}' 
  /var/www /etc /var/lib/mysql --exclude-caches

# 2) Prune retention (keep dailies, weeklies, monthlies)
borg prune -v --list $BORG_REPO --keep-daily=7 --keep-weekly=4 --keep-monthly=6

# 3) Compact repo to reclaim space
borg compact $BORG_REPO

# 4) Sync local repo offsite with rclone to S3 with object lock (bucket policy required)
# Configure 'rclone config' remote named 'offsite' with versioning + lock
rclone sync /backup/borg-repo offsite:my-backups/hostname --checksums --transfers=4 --bwlimit=8M

# 5) Verify a random archive list
borg list $BORG_REPO | shuf -n 1 | while read -r archive _; do borg verify $BORG_REPO::$archive; done

# 6) Send a simple report
echo "Backup completed on $(hostname) at $(date)" | mail -s "Backup Report $(hostname)" [email protected]

この例では、リストア用に高速なローカルリポジトリを保持し、リポジトリをオフサイトに複製します。不変性を確保するには、バケットでオブジェクトロックを有効にし、削除や変更が一定期間ブロックされるように保持ポリシーを設定します。


ユースケースとシナリオ

3-2-1ルールを、業務量のリスク、変化率、およびコンプライアンス要件に合わせて調整する。

フリーランスから大企業まで、ツールや規模は違えど、このパターンは共通している。

フリーランサーとクリエイター

作業ファイルはノートパソコンに保存し、Time Machineなどのツールを使って外付けHDD/SSDにバックアップを取り、さらに暗号化されたバックアップを毎週クラウドストレージまたはオブジェクトストレージにアップロードしてください。これにより、デバイスの紛失や盗難が発生した場合でも、迅速なローカル復旧とオフサイトでの保護が可能になります。

中小企業

定期的なバックアップはNASに一元化し、サーバーとSaaSエクスポート(Microsoft 365/Google Workspace)を毎日バックアップし、オブジェクトロック付きでS3にレプリケーションします。四半期ごとにラボ環境またはステージング環境への完全復元テストを実施します。インシデント発生時の役割とエスカレーション連絡先を文書化します。

企業および規制産業

ポリシー主導のバックアップ、不変のオフサイトコピー、および地域間の地理的冗長性を採用します。キーを使用します。 manage管理システム(KMS/HSM)、厳格なIAM分離、バックアップネットワークのセグメンテーション、SIEM統合ログ、自動化されたDRランブック。データ保持を法的保留および証拠開示要件に合わせる。


よくあるご質問

3-2-1バックアップルールとは、簡単に言うとどういうものですか?

データのコピーを合計3つ作成し、2種類の異なるメディアに保存し、さらに1つのコピーをオフサイトに保管してください。これにより、ベンダーに依存しないシンプルなフレームワークで、冗長性、多様性、および災害対策が確保されます。

3-2-1はまだ有効ですか?それとも3-2-1-1-0を使うべきでしょうか?

3-2-1は依然として強力な基本原則です。ランサムウェアやコンプライアンスが懸念される場合は、不変コピーまたはオフラインコピーを追加し、検証と復元時にエラーをゼロにするためにバックアップを定期的に検証することで、3-2-1-1-0を採用してください。

クラウドストレージはオフサイトストレージとしてカウントされますか?

はい。オンプレミス環境とは別のクラウドリージョンはオフサイトとみなされます。より強力な保護のためには、別のクラウドアカウントを使用し、バージョン管理とオブジェクトロックを有効にし、すべてのバックアップ操作に多要素認証(MFA)を必須にしてください。

データのバックアップはどのくらいの頻度で行うべきですか?

バックアップ頻度は、業務への影響に合わせて調整してください。ほとんどのワークロードでは、日次バックアップが最低限必要です。変更頻度の高いシステムでは、1時間ごとの増分バックアップや継続的なログバックアップが必要になる場合があります。バックアップスケジュールは、常にRPO(目標復旧時点)とRTO(目標復旧時間)の目標値に合わせてください。

RAIDとスナップショットはバックアップとして十分でしょうか?

いいえ。RAIDは可用性を向上させ、スナップショットは迅速なロールバックに役立ちますが、どちらもデータの削除、ランサムウェア攻撃、サイト消失を防ぐものではありません。独立した、バージョン管理された、理想的には不変のバックアップをオフサイトに保管する必要があります。

バックアップはどのくらいの期間保存すべきですか?

リスクと規制によって異なります。一般的な目安としては、オンサイトでの保管期間は30~90日、オフサイトでの保管期間は90~365日以上です。コストと回収オプションのバランスを取るために段階的な保管期間を設定し、法的要件や業界固有の要件を遵守してください。

バックアップが実際に機能しているかどうかを確認するにはどうすればよいですか?

定期的な復元テストを実行します。具体的には、毎月のファイルレベルの復元、四半期ごとのシステム全体または仮想マシンの復旧、およびアプリケーションの整合性の検証を文書化します。達成されたRTO/RPOを追跡し、テスト中に発見されたギャップを修正します。


結論

シンプルさは、奇抜な行動よりも拡張性に優れています。3-2-1はシンプルで実績があり、汎用性も高いです。採用し、自動化し、テストすれば、インシデントを日常的な復旧作業に変えることができます。

3-2-1バックアップルールは、単一のWordPressサイトから複数地域にまたがる企業まで、あらゆる環境に適したフレームワークの中で、冗長性、メディアの多様性、およびオフサイト保護を提供します。

不変性と定期的な検証によってシステムを最新化し、強力なID管理で接続先を保護し、復元が予測可能になるまで訓練を繰り返す。こうした基盤があれば、今日の回復力に関する期待に応え、将来の脅威にも備えることができる。

コメント

あなたのメールアドレスは公開されません。必須項目には*印が付いています。

上へスクロール