サーバーを2台にしたのに、データが消えた。未経験インフラエンジニアが区別しておきたい冗長化とバックアップ

こんにちは、インフラエンジニアのryuです。

インフラの勉強を進めていると、「冗長化」と「バックアップ」という言葉がよく出てきます。

どちらも「何かあったときのための備え」なので、同じようなものだと思っていませんか？

実はこの2つは、守っているものがまったく違います。ここを混同したまま設計の話を聞くと、「2台構成なのに、なぜバックアップも取るんだろう」と引っかかってしまいます。

この記事では、未経験のインフラエンジニアが最初に押さえておきたい冗長化とバックアップの違いを、具体的な例を使って整理していきます。

冗長化とバックアップは何が違う？¶

先に結論を書いておきます。

冗長化は「止めないため」の仕組みで、バックアップは「元に戻すため」の仕組みです。

冗長化：機器や経路を複数用意して、どれか1つが壊れてもサービスを動かし続けられるようにすること。 バックアップ：ある時点のデータを別の場所に保存しておき、データが壊れたり消えたりしたときにその時点まで戻せるようにすること。

言葉にすると当たり前に見えますが、この差が実務ではとても大きいです。

冗長化は、今動いているシステムをそのまま動かし続けるためのものです。一方バックアップは、過去のある時点の状態を残しておくためのものです。

つまり冗長化は「いま」を守り、バックアップは「過去」を守っていると考えると分かりやすいです。

2つを並べて比べてみよう¶

違いを表にまとめると、次のようになります。

表の「守れないもの」の行を見てください。ここがいちばん大事なところです。

冗長化は、壊れた機器の代わりを用意する仕組みです。ですが、データそのものが間違って消されたり壊れたりした場合、その状態はもう1台にもそのまま反映されます。

逆にバックアップがあればデータは戻せますが、戻している間はサービスが止まります。

だから、どちらか片方だけでは足りません。多くのシステムで両方を組み合わせているのはこのためです。

冗長化の仕組みを具体的に見てみよう¶

ここからは、冗長化の代表的な例をいくつか見ていきます。

冗長化を考えるときに、よく使われる言葉が単一障害点（SPOF：Single Point of Failure）です。そこが1か所壊れただけでシステム全体が止まってしまう部分のことを指します。

冗長化の設計は、このSPOFを1つずつ見つけて、つぶしていく作業だと言えます。

ディスクの冗長化（RAID）¶

サーバーの中でいちばん壊れやすい部品の1つがディスクです。そこで、複数のディスクを組み合わせて1台のディスクのように扱うRAIDという技術が使われます。

代表的なRAIDレベルを表にまとめます。

RAID 0は名前にRAIDと付いていますが、冗長性はありません。速度を上げるための構成なので、ここは勘違いしやすいポイントです。

Linuxでは mdadm というコマンドでソフトウェアRAIDを組めます。状態は /proc/mdstat で確認できます。

# ソフトウェアRAIDの状態を確認する（出力は一例）
$ cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sdb1[1] sda1[0]
      10476544 blocks super 1.2 [2/2] [UU]

unused devices: <none>

[UU] は2台とも正常に動いているという意味です。1台が壊れると [U_] のように表示が変わります。

ここで大事なのは、RAID 1で2台に同じデータを書いていても、それはバックアップではないということです。Red Hatの解説記事でも、ミラーリングしたRAIDはデータベースが消されたり壊れたりしたとき、消えた（壊れた）データベースが2つになるだけだと説明されています。

rm で消したファイルは、2台のディスクから同時に消えます。

サーバーと経路の冗長化¶

ディスクの次は、サーバーそのものの冗長化です。

Webサーバーを2台用意して、その前にロードバランサーを置く構成がよく使われます。片方のサーバーが止まっても、ロードバランサーがもう片方にだけ通信を流すので、利用者からはサービスが動き続けているように見えます。

AWSでロードバランサーを実際に作る手順は、ELBの作成方法解説で紹介しています。手を動かしてみると、2台構成のイメージがかなりつかみやすくなります。

ネットワークも同じ考え方です。スイッチ同士を1本のケーブルだけでつなぐと、そのケーブルが抜けた時点で通信が止まります。複数のケーブルを束ねて1本のように扱う技術については、EtherChannelとは？で解説しています。

冗長化できる場所を、ざっくり並べると次のとおりです。

• ディスク（RAID）
• 電源（電源ユニットを2つ積む）
• サーバー（複数台＋ロードバランサー、クラスタ構成）
• ネットワーク（回線、スイッチ、ルーターの二重化）
• データセンター（別の拠点やアベイラビリティーゾーンに分散）

下に行くほど、守れる範囲は広がりますがコストも上がります。どこまでやるかは、そのシステムがどれだけ止まってはいけないかで決まります。

「どれだけ止まってはいけないか」は数字で決める¶

冗長化の話になると、可用性という言葉が出てきます。可用性は、システムが使える状態にあった時間の割合のことです。

よく「99.9%」や「99.99%」のように、9の数で表されます。数字だけ見ると違いが小さく感じますが、年間の停止時間に直すとかなり差があります。

AWSのWell-Architectedフレームワーク（信頼性の柱）では、可用性ごとの年間の最大停止時間の目安が紹介されています。

99.9%なら年に8時間以上止まってもいい計算ですが、99.99%になると1時間も止められません。

9が1つ増えるごとに、冗長化にかかる手間と費用は大きく増えます。社内の勤怠システムと、ネットショップの決済システムでは、求められる数字がまったく違います。

現場では「このシステムは何時間止まると困るのか」を最初に決めて、それに合わせて冗長化の範囲を決めていきます。設計書に可用性の数字が書いてあったら、その数字がどんな構成につながっているのかを意識して読んでみてください。

バックアップの考え方を押さえよう¶

次はバックアップです。冗長化があっても防げないトラブルは、意外と身近にあります。

• 作業ミスで設定ファイルやデータを消してしまった
• アプリケーションの不具合でデータベースの中身が壊れた
• ランサムウェアにファイルを暗号化された

どれも、冗長化した全台に同じ被害が広がります。ここで頼れるのがバックアップです。

バックアップの基本は3-2-1ルール¶

バックアップの取り方には、昔から使われている目安があります。それが3-2-1ルールです。

本番サーバーと同じラックに置いたNASにだけバックアップを取っている状態は、意外とよく見かけます。これだと、停電や火災、ランサムウェアの感染で本番と一緒にバックアップも失う可能性があります。

特にランサムウェアは、ネットワークでつながっているバックアップ先まで暗号化しようとします。警察庁のランサムウェア被害防止対策のページでも、バックアップまで暗号化される事例が多いことから、バックアップをこまめに取得し、ネットワークから切り離してオフラインで保存することがすすめられています。

ランサムウェアそのものの仕組みは、ランサムウェアとは？で解説しているので、あわせて読んでみてください。

戻せるかどうかを確かめておく¶

バックアップでよくある失敗が、取っているだけで一度も戻したことがないというケースです。

いざ戻そうとしたら、ファイルが壊れていた。手順が分からず何時間もかかった。必要なファイルが対象から漏れていた。こういう話は珍しくありません。

Linuxで簡単なバックアップを取って、それを戻す流れを試すなら、たとえば次のようになります。

# /etc を日付付きのファイルにまとめてバックアップする
$ sudo tar czf /backup/etc-$(date +%F).tar.gz /etc

# 中身が読めるか確認する（一覧を表示するだけ）
$ tar tzf /backup/etc-$(date +%F).tar.gz | head

# 別の場所に展開して、戻せることを確かめる
$ mkdir /tmp/restore-test
$ sudo tar xzf /backup/etc-$(date +%F).tar.gz -C /tmp/restore-test

本番の /etc に直接展開するのではなく、別のディレクトリに戻して中身を確認しているのがポイントです。

バックアップは「戻せることを確認して」はじめて意味があります。 練習用のサーバーでも、一度は取得から復元までを通してやってみてください。

クラウドでも考え方は同じです。AWSのEC2でディスクを丸ごと残す方法は、EC2のバックアップと復旧の方法で手順を紹介しています。

どの時点まで戻せればいいのか¶

バックアップを設計するときには、もう1つ考えておくことがあります。それは、どの時点まで戻せれば困らないかです。

1日1回、夜中にバックアップを取っている場合を考えてみましょう。夕方にデータが壊れたら、戻せるのは前の日の夜の状態です。その日の日中に追加されたデータは失われます。

これを許せるかどうかは、システムによって違います。設定ファイルなら1日前でも困らないかもしれませんが、注文データが1日分消えたら大問題です。

現場ではこの「どこまで戻れればいいか」をRPO（目標復旧時点）、「どれくらいの時間で戻したいか」をRTO（目標復旧時間）と呼んで、要件として決めていきます。言葉だけでも覚えておくと、設計の打ち合わせで話についていきやすくなります。

冗長化とバックアップを組み合わせた例¶

最後に、ここまでの話を1つの構成にまとめてみます。小さなWebサービスを例にすると、次のような形になります。

Webサーバーのバックアップが「構築手順を残す」になっている点に注目してください。中身が同じサーバーなら、データを保存するよりも、同じものをすぐ作り直せる状態にしておくほうが早い場合が多いからです。

一方データベースは、冗長化とバックアップの両方が必要な代表です。スタンバイがあれば故障には強くなりますが、誤って削除したデータはスタンバイ側からも消えてしまうからです。

こうやって層ごとに「壊れたらどうなるか」「消えたらどうするか」を分けて考えるのが、冗長化とバックアップを使い分けるコツです。

まとめ¶

今回は、混同しやすい冗長化とバックアップの違いを整理しました。

• 冗長化は「止めない」ための仕組みで、機器の故障には強いが、誤削除やデータ破損は全台に広がる
• バックアップは「戻す」ための仕組みで、データは戻せるが、戻すまでの間はサービスが止まる
• RAID 1やスタンバイのデータベースは、バックアップの代わりにはならない
• 可用性の数字やRPO・RTOから、どこまで冗長化し、どの時点まで戻せればいいかを決める
• バックアップは3-2-1ルールを目安にし、実際に戻せるかを一度は確かめておく

設計書や構成図を見るときに、「ここは冗長化で守っている」「ここはバックアップで守っている」と分けて読めるようになると、インフラの見え方がかなり変わってきます。

冗長化やバックアップは、AWSを触りながら学ぶとイメージしやすい分野です。InfraAcademyでは、クラウドの基礎から順番に手を動かして学べるAWSのロードマップを用意しています。インフラ全体の学習の流れを知りたい方は、インフラエンジニアのロードマップもあわせて読んでみてください。

まずは練習用のサーバーで、バックアップを取って戻すところから試してみましょう。

参考¶

• Understanding availability needs - AWS Well-Architected Framework Reliability Pillar
• Managing RAID - Red Hat Enterprise Linux 10 Managing storage devices
• RAID for those who avoid it - Red Hat
• ランサムウェア被害防止対策 - 警察庁
• ランサムウェア被害から学ぶ教訓集 - IPA 独立行政法人情報処理推進機構