AEON Advent Calendar 2025

AEON

バックアップについて振り返る

Posted at 2025-12-15

本記事は AEON Advent Calendar 2025の15日目の記事です。

こんにちは。イオンスマートテクノロジー株式会社（AST）DX基盤チームのDBRNです。
シャイなので本名は勘弁してくだしあ。

ASTにJOINして早3か月（2025/12時点）。お誘いいただき、いい機会だと思ったので記事を書いてみます。

はじめに

もしもの時に備えてバックアップとってませんか？
障害や誤操作、そして近年猛威を振るうランサムウェア攻撃に対して、バックアップの重要性はますます高まっています。
「ランサム流行ってますよね？」という言葉が冗談にならないほど、攻撃は日常化し、企業の存続を脅かす事態も珍しくありません。

ここ数年、バックアップシステムの提案や導入を数多く経験してきました。
ASTにJOINし、利用しているプラットフォームも変わった今がいい機会だと思い、改めてバックアップの基本的な考えを振り替えつつ、Azureを活用した構成例を考えてみます。

✅ この記事のポイント

バックアップあっても憂いあり
3・2・1ルール＋ランサム対策で「3・2・1・1・0」
意味あるバックアップ＝シンプルに取得し、堅牢に守り、日々運用

バックアップの必要性

なぜバックアップが必要なのか？
「データは失われる可能性がある」からです。ハードウェア障害、ヒューマンエラー、サイバー攻撃、自然災害…。
どれも予測不能で、完全に防ぐことはできません。
バックアップは、こうしたリスクに備えるための手段であり、事業継続のための命綱です。

バックアップを取るうえでの3・2・1ルール

バックアップの世界で有名な原則が 3・2・1ルール です。

3：データのコピーを3つ保持する（本番＋バックアップ2つ）
2：異なるメディアに保存する（例：ディスク＋クラウド）
1：1つはオフサイトに保管する（物理的に離れた場所）

ただ、ランサムウェアの脅威が高まる中、このルールだけでは不十分です。そこで新たに提唱されたのが、

3・2・1・1・0ルール。

元々の3・2・1の考えは非常に重要です。ただ、物理的な障害や災害には強いのですが、最近はバックアップデータを狙った攻撃も多くあります。
また、バックアップを取るだけ取って復旧が試されていないケースもあります。

備えあっても憂いあり ということですね。
こうした背景から 3・2・1・1・0ルール が提唱されました。

+1：不変化（Immutable）なコピーを保持する
+0：復旧テストを行い、エラーゼロを確認する

この追加要素により、バックアップの「信頼性」と「耐攻撃性」が大幅に向上します。

Azureでの3・2・1・1・0構成"例"

Azureはバックアップを取るうえでいいサービスを沢山提供しています。
Azureでこのルールを実現するどうすればいいのかをAI様（Copilot）に聞いてみました。

以下の構成は例ですので、それぞれの要件をもとに適切なバックアップ方針を検討してください。

パターン1：

Azure Backup を利用し、VMやSQL Databaseをバックアップ → （3） データコピー数確保
Recovery Services Vaultで保持 → （2） 異なるメディア（クラウド）
オフサイト要件はAzureリージョン冗長（GRS）で対応 → （1） オフサイト保管
定期的なリストア試験を自動化 → （+0） 復旧テスト

メリット：構成がシンプル、コスト低
デメリット：不変化はVaultの設定次第（+1 はオプション）

パターン2：

Azure Backupに加え、Immutable Blob Storageを利用 → （+1） 不変化（改ざん防止）
バックアップデータをストレージにコピーし、WORMポリシーで改ざん防止 → （+1） 強化
別リージョンにセカンダリコピー → （1） オフサイト保管
定期的なリストア試験を自動化 → （+0） 復旧テスト

メリット：ランサムウェア耐性強化
デメリット：運用設計が必要

パターン3：

Azure Backup＋Immutable Blob＋Azure Site Recovery → （3） 複数コピー、（+1） 不変化
DRサイトを構築し、システム全体のフェイルオーバーを可能に → （1） オフサイト保管
定期的なリストア試験を自動化

メリット：事業継続計画（BCP）に対応
デメリット：コスト・設計負荷が大きい

大好きサマリ

バックアップにかけられる予算やバックアップに求めるレベルによって採用する構成は変わります。
まずは、パターン1をベースに、Resource Guardや不変コンテナを組み合わせて運用するのがよさそうかなと思いました。
この辺りはもっと深堀していきたいですね。

バックアップ構成の比較

パターン	3（コピー数）	2（異なるメディア）	1（オフサイト）	+1（不変化）	+0（リストア試験）	コスト	運用負荷
1	○	○	○	△（Vault設定次第）	〇	★	★
2	○	○	○	○（Immutable Blob＋WORM）	〇	★★	★★
3	○	○	○	○	○	★★★	★★★

凡例

○：対応済み
△：オプション設定で対応可能
×：未対応
コスト／運用負荷：★（低）～★★★（高）

バックアップには「意味」があるべきだ

バックアップは「取ること」が目的ではありません。「復旧できること」が目的です。
そのためには、以下を満たす必要があります。

データが改ざんされていないこと
実際に復旧可能であること
RPO/RTOなどの業務要件を満たすこと

意味を保つためにやるべきこと

1. バックアップ取得の自動化

ベースラインを設定し、スケジュール化
カスタマイズは必要に応じて

2. 改ざん防止（不変化）

不変コンテナ、ImmutableストレージやVaultのロック機能を活用
WORMポリシーでランサムウェア対策

3. 定期的な復旧試験

ファイル単体 → サーバ単体 → システム全体と段階的に
RPO/RTOなどバックアップの要件は求めていた水準を保てていますか？
理想は「リストア（復旧）を考慮したアーキテクチャ設計」

おふぁり

バックアップは最後の命綱です。
複雑すぎる仕組みは運用を阻害し、計画性のないバックアップは形骸化します。
だからこそ、シンプルに取得し、堅牢に守り、日々の運用を大切にすることが重要です。

また、バックアップデータが汚染されていないことも重要です。
復旧したデータに脅威が眠っているのはよくないですよね。

機会があれば汚染の話や、今回紹介した各パターンの検証についても記事にしようと思います。

おふぁり～。

参考資料

イオングループで、一緒に働きませんか？

イオングループでは、エンジニアを積極採用中です。少しでもご興味をもった方は、キャリア登録やカジュアル面談登録などもしていただけると嬉しいです。
皆さまとお話できるのを楽しみにしています！

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up