バックアップとレプリケーションの違いとは？初心者向けに目的・使い分け・復旧方法を解説
バックアップはデータを過去の状態へ戻すためのコピー、レプリケーションはシステムを継続稼働させるための複製です。
どちらもデータを守る仕組みですが、目的は同じではありません。バックアップは誤削除、ランサムウェア、データ破損などからの復旧に向いています。一方、レプリケーションはサーバー障害や拠点障害が発生した際に、別の環境へ切り替えて業務を継続するために利用されます。
レプリケーションを導入していても、バックアップが不要になるわけではありません。IT現場では、両方を組み合わせてデータ保護とシステム継続を実現することが基本です。
- バックアップとは
- レプリケーションとは
- バックアップとレプリケーションの違い
- 最も重要な違いは「過去へ戻せるか」
- レプリケーションはバックアップの代わりにならない
- 実際のIT現場での利用例
- バックアップの主な種類
- レプリケーションの主な種類
- RPOとRTOの違い
- 業務でよくあるトラブル
- 障害発生時の確認順序
- ユーザー側・サーバー側・ネットワーク側の切り分け
- Windowsでバックアップ状況を確認する方法
- CUIで確認する方法
- 確認結果の見方
- 初心者がやりがちなミス
- バックアップ運用で覚えておきたい3-2-1ルール
- 上司へ報告するポイント
- エスカレーションするタイミング
- 筆者が現場で経験した失敗例
- バックアップとレプリケーションの選び方
- 関連するIT用語
- よくある質問
- まとめ
バックアップとは
バックアップとは、ファイル、データベース、システム設定、仮想マシンなどを別の保存先へコピーし、必要なときに復元できるようにする仕組みです。
現在のデータだけでなく、昨日、1週間前、1か月前といった複数の世代を保存できます。誤ってファイルを削除した場合や、データが壊れた場合に、正常だった時点へ戻すことが主な目的です。
バックアップが使われる場面
- 利用者が共有フォルダのファイルを削除した
- データベースのデータを誤更新した
- Windows Update後にシステムが起動しなくなった
- ランサムウェアによってファイルが暗号化された
- サーバーのディスクが故障した
- 設定変更後に障害が発生した
レプリケーションとは
レプリケーションとは、稼働中のサーバーやデータを別のサーバー、ストレージ、拠点へ複製する仕組みです。
元の環境をプライマリ、複製先をセカンダリやレプリカと呼ぶことがあります。プライマリ側で障害が発生した場合、セカンダリ側へ切り替えることで、システム停止時間を短くできます。
レプリケーションが使われる場面
- 本番サーバー障害時に待機系へ切り替える
- データベースを複数台構成にする
- 別拠点へデータを複製する
- 災害時に遠隔地のシステムを起動する
- 読み取り処理を複数のサーバーへ分散する
バックアップとレプリケーションの違い
| 比較項目 | バックアップ | レプリケーション |
|---|---|---|
| 主な目的 | データを復元する | システムを継続する |
| 保存内容 | 過去時点のデータ | 現在に近いデータの複製 |
| 世代管理 | 複数世代を保存できる | 基本的に最新状態を同期する |
| 誤削除への対応 | 削除前の世代から復元できる | 削除内容も複製される可能性がある |
| 障害時の切り替え | 復元作業が必要 | 待機系へ切り替えられる |
| 復旧速度 | 復元量によって時間がかかる | 比較的短時間で切り替えやすい |
| 主な対策 | 誤操作、破損、マルウェア | 機器故障、拠点障害、停止対策 |
最も重要な違いは「過去へ戻せるか」
バックアップは複数の保存時点を持てるため、問題が起きる前の状態へ戻せます。
レプリケーションは最新データを複製する仕組みです。そのため、元のサーバーでファイルを削除すると、削除操作まで複製先へ反映される場合があります。
例えば、午前10時に重要なファイルを誤削除し、その操作が即座にレプリカへ同期された場合、複製先にもファイルは残りません。しかし、前日のバックアップがあれば、そこから復元できます。
レプリケーションはバックアップの代わりにならない
初心者が特に注意したいのは、レプリケーションがあるだけではデータ保護が不十分な点です。
次のような問題は、複製先にも反映される可能性があります。
- 誤削除
- 誤更新
- データベースの論理破損
- ランサムウェアによる暗号化
- 不正操作
- アプリケーションの不具合
障害時の切り替えにはレプリケーション、過去データの復元にはバックアップと考えると理解しやすくなります。
実際のIT現場での利用例
| 状況 | 使用する仕組み | 対応内容 |
|---|---|---|
| 共有ファイルを誤って削除した | バックアップ | 削除前の世代から復元する |
| 本番サーバーが故障した | レプリケーション | 待機系サーバーへ切り替える |
| データベースを誤更新した | バックアップ | 更新前の状態を確認して復旧する |
| データセンターが停止した | 遠隔地レプリケーション | 別拠点の環境へ切り替える |
| ランサムウェア被害が発生した | 隔離されたバックアップ | 感染前の正常なデータを復元する |
バックアップの主な種類
フルバックアップ
対象データをすべて保存する方式です。復元は分かりやすい一方、保存容量と実行時間が多く必要になります。
差分バックアップ
最後のフルバックアップ以降に変更されたデータを保存します。復元時は、フルバックアップと最新の差分バックアップを使用します。
増分バックアップ
前回のバックアップ以降に変更されたデータだけを保存します。保存容量を抑えやすい一方、復元時に複数のバックアップが必要になる場合があります。
レプリケーションの主な種類
同期レプリケーション
元のデータと複製先の両方へ書き込みが完了してから処理を完了する方式です。データ差分を小さくできますが、通信遅延が性能へ影響しやすくなります。
非同期レプリケーション
元の環境への書き込み完了後、少し遅れて複製先へ反映する方式です。遠隔地への複製に向いていますが、障害発生時に直前のデータが失われる可能性があります。
RPOとRTOの違い
バックアップやレプリケーションを設計する際は、RPOとRTOを確認します。
| 用語 | 正式名称 | 意味 |
|---|---|---|
| RPO | Recovery Point Objective | どの時点までデータを戻せればよいか |
| RTO | Recovery Time Objective | どのくらいの時間で復旧する必要があるか |
例えば、RPOが1時間であれば、最大1時間分のデータ損失を許容する設計です。RTOが4時間であれば、障害発生後4時間以内の復旧を目標とします。
一般的に、短いRTOを求めるシステムではレプリケーションが有効です。過去時点への復元が必要な場合は、バックアップの世代管理が欠かせません。
業務でよくあるトラブル
バックアップが正常終了していない
- 保存先の容量が不足している
- バックアップ対象へアクセスする権限がない
- ネットワークが切断された
- 対象ファイルが使用中だった
- バックアップサービスが停止していた
レプリケーションが停止している
- 複製先へ通信できない
- 認証情報や証明書に問題がある
- ディスク容量が不足している
- 複製処理が遅延している
- プライマリとセカンダリの設定が一致していない
バックアップはあるが復元できない
バックアップジョブが成功していても、実際に復元できるとは限りません。データ破損、暗号化キーの紛失、復元手順の不備などが原因になることがあります。
バックアップは取得するだけでなく、定期的な復元テストまで実施して初めて有効です。
障害発生時の確認順序
- 影響を受けているシステムと利用者を確認する
- 発生時刻と直前の変更作業を確認する
- 誤削除、機器故障、通信障害など原因を分類する
- バックアップとレプリケーションの稼働状況を確認する
- 最新の正常なバックアップ時刻を確認する
- レプリケーションの遅延や停止を確認する
- RPOとRTOに基づいて復旧方法を決める
- 承認後に復元または切り替えを実施する
ユーザー側・サーバー側・ネットワーク側の切り分け
ユーザー側
- ファイルを削除したユーザーと時刻を確認する
- ごみ箱や以前のバージョンに残っていないか確認する
- 別のユーザーでも同じ問題が発生するか確認する
- アクセス権限の問題ではないか確認する
サーバー側
- バックアップサービスが起動しているか
- 保存先の空き容量があるか
- 対象ボリュームやデータベースが正常か
- レプリケーションの状態が正常か
- エラーログが記録されていないか
ネットワーク側
- バックアップ先へ通信できるか
- 複製先サーバーへ接続できるか
- DNSの名前解決が正常か
- ファイアウォールで通信が拒否されていないか
- 回線遅延やパケットロスがないか
Windowsでバックアップ状況を確認する方法
GUIで確認する方法
- スタートメニューを開く
- 利用しているバックアップ製品や管理ツールを起動する
- ジョブ履歴または実行履歴を開く
- 最終成功日時とエラーの有無を確認する
- バックアップ保存先の空き容量を確認する
Windows Server Backupを使用している場合は、「サーバーマネージャー」から「ツール」を開き、「Windows Server Backup」を選択します。
イベントビューアーで確認する方法
- Windowsキー＋Rを押す
- 「eventvwr.msc」と入力してEnterキーを押す
- 「アプリケーションとサービスログ」を開く
- Microsoft配下のバックアップ関連ログを確認する
- 障害発生時刻付近のエラーと警告を確認する
製品によってログの保存場所は異なります。イベントID、ソース、発生日時、エラーコードを記録してください。
CUIで確認する方法
コマンドプロンプト
wbadmin get status
Windows Server Backupの実行状態を確認できます。
wbadmin get versions
利用可能なバックアップの世代を確認できます。
ping バックアップ先のホスト名
バックアップ先や複製先との基本的な通信確認に使用します。ただし、pingが成功しても、必要なポートで通信できるとは限りません。
nslookup バックアップ先のホスト名
DNSによる名前解決が正常か確認できます。
PowerShell
Get-Service
バックアップ製品やレプリケーション機能に関連するサービスの状態を確認できます。
Get-Volume
ドライブの空き容量やファイルシステムを確認できます。
Test-NetConnection バックアップ先のホスト名 -Port ポート番号
複製先やバックアップ先の特定ポートへ接続できるか確認できます。
確認結果の見方
| 確認結果 | 考えられる原因 | 次の対応 |
|---|---|---|
| バックアップが失敗している | 容量不足、権限不足、通信障害 | エラーコードと保存先を確認する |
| バックアップは成功している | 復元対象や世代選択に問題がある可能性 | 復元可能な日時と対象を確認する |
| レプリケーションが遅延している | 回線負荷、処理負荷、容量不足 | 遅延時間と未同期データ量を確認する |
| 複製先へ接続できない | DNS、ファイアウォール、ネットワーク障害 | 名前解決とポート疎通を確認する |
| 両方のデータが破損している | 破損や誤操作も複製された | 正常なバックアップ世代から復元する |
初心者がやりがちなミス
- レプリケーションがあればバックアップは不要だと考える
- バックアップジョブの成功だけを確認し、復元テストをしない
- 保存先の空き容量を確認しない
- 正常なバックアップ世代を確認せず復元する
- 本番環境でいきなりフェイルオーバーする
- 復元によって現在のデータが上書きされることを見落とす
- バックアップと本番データを同じ場所だけに保存する
- 暗号化キーや管理者情報を別途保管していない
バックアップ運用で覚えておきたい3-2-1ルール
3-2-1ルールは、データ消失のリスクを減らすための代表的な考え方です。
- データを合計3つ保持する
- 2種類の異なる媒体へ保存する
- 1つは別拠点やクラウドなど離れた場所へ保管する
ランサムウェア対策では、通常の管理者権限から変更や削除ができないイミュータブルバックアップも有効です。イミュータブルとは、一定期間データを書き換えられない状態を意味します。
上司へ報告するポイント
- 障害や誤操作が発生した日時
- 対象システム、サーバー、ファイル名
- 影響を受けている利用者と業務
- 最新の正常なバックアップ日時
- レプリケーションの同期状態と遅延時間
- 復元した場合に失われる可能性があるデータ
- 想定される復旧時間
- 切り替えや復元に必要な承認
- 実施予定の手順と切り戻し方法
「バックアップがあります」だけでなく、「前日23時のバックアップが正常で、復元すると最大8時間分の更新が失われる可能性があります」のように具体的に報告します。
エスカレーションするタイミング
- 本番データを上書きする復元が必要
- レプリカへの切り替えが必要
- 最新バックアップが失敗している
- ランサムウェア感染の可能性がある
- 複数システムや複数拠点へ影響している
- RPOまたはRTOを満たせない可能性がある
- 復旧手順や影響範囲が判断できない
- データ消失や情報漏えいの可能性がある
筆者が現場で経験した失敗例
以前、共有ファイルサーバーを別のサーバーへレプリケーションしていたため、データは安全だと考えていました。しかし、利用者がフォルダを誤削除した際、その削除操作もすぐに複製先へ反映されていました。
幸い、別に取得していた前日のバックアップから復元できましたが、レプリケーションだけでは誤操作から守れないことを実感した事例です。
それ以降は、レプリケーションの正常性だけでなく、バックアップ世代、保存期間、復元テストの結果まで定期的に確認する運用へ変更しました。
バックアップとレプリケーションの選び方
どちらか一方を選ぶのではなく、システム要件に合わせて組み合わせます。
| 要件 | 必要な仕組み |
|---|---|
| 誤削除したファイルを戻したい | バックアップ |
| サーバー障害でも停止時間を短くしたい | レプリケーション |
| ランサムウェアから復旧したい | 隔離・変更不可のバックアップ |
| 災害時に別拠点で業務を継続したい | 遠隔地レプリケーションとバックアップ |
| 重要システムを総合的に保護したい | バックアップとレプリケーションの併用 |
関連するIT用語
- リストア
- リカバリー
- 冗長化
- フェイルオーバー
- プライマリ
- セカンダリ
- RPO（Recovery Point Objective）
- RTO（Recovery Time Objective）
- DR（Disaster Recovery）
- スナップショット
- イミュータブルバックアップ
よくある質問
レプリケーションがあればバックアップは不要ですか？
不要にはなりません。誤削除、データ破損、ランサムウェアによる暗号化なども複製先へ反映される可能性があるため、過去へ戻せるバックアップが必要です。
スナップショットはバックアップですか？
スナップショットは、ある時点のディスク状態を記録する仕組みです。復旧に役立ちますが、元のストレージ障害や管理者による削除の影響を受ける場合があります。保存先や製品仕様を確認し、独立したバックアップと併用することが重要です。
バックアップは何世代保存すればよいですか？
業務要件、法令、保存容量、復旧したい期間によって異なります。日次、週次、月次などを組み合わせ、必要な時点へ戻せるように設計します。
レプリケーションの同期と非同期はどちらがよいですか？
データ損失をできるだけ減らしたい場合は同期方式が向いています。遠隔地への複製や通信遅延を抑えたい場合は非同期方式が使われます。
バックアップが成功していれば安心ですか？
成功表示だけでは不十分です。復元対象が含まれているか、データが破損していないか、実際に復元できるかを定期的にテストする必要があります。
まとめ
バックアップとレプリケーションは、目的の異なるデータ保護技術です。
- バックアップは過去の状態へ復元するためのコピー
- レプリケーションはシステム継続のための複製
- 誤削除やデータ破損にはバックアップが有効
- サーバー障害や拠点障害にはレプリケーションが有効
- レプリケーションはバックアップの代わりにならない
- バックアップは定期的な復元テストが必要
- 重要なシステムでは両方を組み合わせる
「過去へ戻すのがバックアップ、別環境で業務を続けるのがレプリケーション」と覚えると違いを整理しやすくなります。障害発生時は、原因、影響範囲、最新の正常データ、RPO、RTOを確認してから復旧方法を判断しましょう。
コメント