冗長化したのにデータを消したら戻せなかった…複製とバックアップの違いと、発注時に決める4つのこと

2026年10月7日

「サーバーを二重にしているから安心」と聞いていたのに、担当者が誤ってデータを消した途端、二重にしていた両方から同時に消えてしまった。クラウドで業務システムを運用していると、こうした話は決して珍しくありません。

「冗長化したのにデータを誤って消したら元に戻せなかった。複製とバックアップは何が違うのか分からない」

先に結論をお伝えします。冗長化（複製）は「機械が壊れても止まらない」ための仕組みで、バックアップは「データが消えても過去の状態に戻せる」ための仕組みです。目的が違うので、どちらか一方では守れません。複製は消した内容もすぐ相手側に反映されてしまうため、誤操作や不正な書き換えには無力なことがあります。

この記事では、複製とバックアップの違いを発注者向けにやさしく整理し、AWS（アマゾンのクラウドサービス）での代表的な戻し方、開発会社と決めておきたい4つのこと、そのまま使える質問例を紹介します（執筆時点：2026年10月）。なお、冗長化にどこまで費用をかけるかは、システムを止めたくない…冗長化にどこまでお金をかける？AWSの障害対策を3段階で決める方法で解説しています。

複製（冗長化）とバックアップは何が違うのか

まず言葉を整理します。複製（レプリケーション）とは、データをほぼリアルタイムで別の場所へコピーし続けることです。冗長化（＝同じ役割の部品を複数用意しておくこと）の一部として使われます。バックアップは、ある時点のデータを「別に保管しておく」ことで、あとからその時点に戻すための仕組みです。

	複製（冗長化）	バックアップ
主な目的	機械・設備の故障でも止まらないようにする	消えた・壊れたデータを過去の状態に戻す
変更の扱い	変更も削除もすぐ相手側に反映される	ある時点の状態が残る（変更後も昔の状態が残る）
守れる事故	サーバー故障、設備の障害	誤削除、誤った上書き、不正な書き換え、ソフトの不具合
守りにくい事故	誤削除、データの破損、不正な書き換え	「止まらない」ことの保証（復元に時間がかかる）

たとえば、書類を2台のコピー機で同時に印刷し続けている状態が複製、毎晩キャビネットに1部ずつ保管していくのがバックアップ、とイメージすると分かりやすいでしょう。コピー機が1台壊れても印刷は続けられますが、元の書類に誤った書き込みをすると、両方のコピー機が誤った内容を印刷します。

この違いは、AWSの設計指針でも明確に述べられています。

📰 出典：AWS Well-Architected Framework 信頼性の柱「REL13-BP02 定義済みの復旧戦略を使用して、復旧目標を達成する」

この資料では、継続的なデータ複製は一部の災害には有効ですが、保存データのバージョン管理や特定時点への復旧（ポイントインタイムリカバリ）の仕組みがなければ、データの破損や破壊は防げない可能性があると説明されています。あわせて、複製先のデータについても、複製とは別に時点ごとのバックアップを取ることが推奨されています。

なぜ「冗長化したのに戻せない」ことが起きるのか

開発会社の側から見ると、発注時に求められた「止まらないシステム」の要望に対して、冗長化の構成を提案するのは自然な流れです。一方で、「消えたデータを戻したい」という要望は、発注者から明確に言葉にされないことが多く、見積もりや設計書に含まれないまま進むことがあります。

つまり、悪意や手抜きではなく、「止まらない」と「戻せる」が別の要件であることが、お互いに言葉にされていないことが原因になりやすいのです。

よくあるすれ違いのパターンは次のとおりです。

発注者は「冗長化＝データも安全」と受け取っている
開発会社は「冗長化は止めないための設計、バックアップは別の相談」と考えている
見積書に「バックアップ」の項目がなく、誰も確認しないまま稼働する

開発会社と決めておきたい4つのこと

戻せるシステムにするために、発注者の側で決めておきたいのは次の4つです。細かい設定は開発会社に任せて構いませんが、「何をどこまで戻したいか」は事業の判断なので、発注者が答える必要があります。

1. 何のデータを守るか（顧客情報・受注履歴・ファイルなど）

データの種類ごとに重要度は違います。顧客情報や受注履歴のように失うと業務が止まるものは優先度が高く、再作成できるデータ（画面表示用の加工済みデータなど）は優先度を下げられます。まずは「消えたら困るデータの一覧」を作りましょう。

2. どの時点まで戻したいか（データ損失をどこまで許せるか）

「毎晩の状態に戻れれば十分」なのか、「消える直前の数分前まで戻したい」のかで、仕組みも費用も変わります。この「どこまでのデータ損失なら許せるか」を表す目標を、RPO（＝戻せる時点の目標。例：直前の5分前まで）と呼びます。

AWSでは、データベースサービスのAmazon RDSは取引の記録（ログ）を5分ごとに保存し、保持期間内であれば任意の時点に戻せる機能（ポイントインタイムリカバリ）があります。

📰 出典：Amazon RDS ユーザーガイド「Restoring a DB instance to a specified time」

ここで知っておきたいのは、戻した結果は元のデータベースを上書きするのではなく、新しいデータベースとして作られる点です。復元後に、必要なデータを取り出して戻すか、接続先を切り替える作業が別途必要になります。

3. どのくらいの時間で戻したいか（復旧にかけられる時間）

データを戻すのにかかる時間の目標をRTO（＝システムを元に戻すまでにかけられる時間の目標）と呼びます。大量のデータは復元に時間がかかるため、「戻せる」ことと「すぐ戻せる」ことは別です。「半日止まっても業務は回るのか」「1時間以内に戻す必要があるのか」を、業務の実態に合わせて決めます。

4. どのくらいの期間さかのぼれるようにするか（保管期間）

誤削除はその場で気づくとは限りません。月次の締め処理のときに初めて「先月のデータがおかしい」と気づく場合もあります。保管期間を長くするほど戻せる範囲は広がりますが、保管するデータが増える分、費用も増えます。

ファイルの保管サービスであるAmazon S3では、「バージョニング」という機能を有効にすると、削除や上書きをしても過去の版が残ります。削除した場合も実際には消えず「削除マーカー」が付くだけなので、以前の版を戻せます。

📰 出典：Amazon S3 ユーザーガイド「Retaining multiple versions of objects with S3 Versioning」

ただし、この機能は初期状態では無効で、有効にする設定が必要です。また、公式ドキュメントによると、保存された各版はそれぞれ通常の保管料金の対象です。たとえば同じファイルを3回上書きすれば3つ分の容量として課金されるため、「古い版を何日たったら自動削除するか」というルールもあわせて決めておくと、費用が膨らみにくくなります。