バックアップ運用の備忘録。

「Baculaで Ubuntu Serverのバックアップ(その1)」からの一連のシリーズで実際にバックアップをする環境を作ったんですけど、そもそものバックアップ運用やそれを実行する環境の設計ってどうやってたっけな？ということを備忘録的に。

１．非機能要件定義

何から話せば良いやらなんですが、お客さんの非機能要件から。

極端に簡潔にして言うと「どうなったらデータが失われても諦められますか？」という問いに対してのご回答ってことですかね。

コンピューターはありとあらゆる理由でブッ壊れますので、どういう障害でデータがブッ飛んだのならお客さんは自分を許せるか、ということです。

障害事象	対策
サーバーの故障	サーバー二重化
データセンターへのミサイル攻撃	他のビルへバックアップデータを移送
都市への核攻撃	他の都市にあるデータセンターへバックアップデータを移送
エイリアン襲来	火星へ…(以下略)

というように、障害事象ごとにバックアップのための運用にどれくらいのコストがかかるかを算出して、お客さんがギブアップするポイントを決めます。

国が滅ぶくらいのところが MAXと思いますが、大きな会社さんだと大型地震で東京壊滅くらいは想定していますね。
BCP(事業継続計画)というのを立てていらっしゃいます。


次は「どのくらい前のデータを戻す事がありますか？」という問に対するご回答となります。

昨今ではマルウェア感染などによってサーバーのデータがロックされ人質に取られる被害が出ていますが、ああいうのは OSから何から感染前の状態に戻す必要があります。

バックアップデータの保持回数(世代って言いますが)は単純にコストが掛け算になるイメージなので、余り長くもできません。
ここもお客さんのギブアップするポイントを探ります。

対象データ種	期間
法律で定められた保管期間のあるもの (電帳法など)	3年〜5年
経営判断用の過去データ	5年〜10年くらい? (お客さんによる)
業務システムのデータ	(例)半年 (データはDBに溜め込まれているケース)
従業員のメールなど	1ヶ月とか
経営層が貯め込んだ叡智動画/画像など	普通のもの→無視 マニア性の高いもの→永久

バックアップの非機能要件定義にはこれ以外にも考慮することはありますけど、環境設計においてはこの 2つが主な要件になると思います。


２．環境設計

非機能要件が決まってからバックアップ環境設計ができれば苦労しません。

「コストパフォーマンスによって決めたい」というお客さんばかりなので、いくつかのパターンを設計して概算を出しましょう。

大体ここでお客さんが障害の影響を安く見て、ケチってショボい環境になってしまいます。
誰も幸せにならないので、サーバー環境設計と営業の腕の見せ所となります。

パブリッククラウドやレンタルサーバーといった他社のインフラサービスを使っている場合は必ずバックアップのサービスが提供されていて、設計云々ではなくそれを利用する他無いと思います。

但しデータ量課金となり、長期間の保持が必要な要件がある場合に思ったより高額になってしまうことがあります。
(きっと中の人はかなり特殊で高額なストレージを使っているから)
AWSなんかでは後々は glacierなど、より安いサービスへのシフトを考えないといけません。

オンプレの場合は、バックアップテープかディスクベースのバックアップストレージと呼ばれる機器の導入になります。

バックアップテープは、2023年5月の時点では LTO9が主流になってるんじゃないでしょうか。
1本(105.4mm x 102.0mm x 21.5mm)で 18TB(圧縮時45TB)の容量があります。
書き込み速度が 500MB/sだそうで、かなり速いです。
私はよくラックの高さ1つ分(1U)で8本の LTOを収められるテープチェンジャーを使っていました。

LTOのドライブの仕様としてメイン世代(LTO9なら第9世代)と1世代前(LTO8)の読み書き、2世代前(LTO7)の読み込みができます。
バックアップは戻してナンボ、安いからと古い世代のドライブではなく最新世代にしておくのが無難です。

バックアップテープは扱いが若干面倒ではありますが、他の所に持ち出せるという BCP観点での利点があります。
データ量に対してテープ媒体の値段が安いので今でも人気があります。


大体これらのハードウェアに対応したバックアップソフトを使います。
Backup Execや Arcsrveが有名です。

こういったソフトは有名所のテープチェンジャーに対応していて、バックアップのスケジューリングからテープの管理まで一括して行うことができます。


業務のサービスを提供しているサーバーに直接これらの機器を付けるパターンもありますが、バックアップソフトはネットワーク経由でのバックアップを可能にしますので、バックアップ専用のサーバーを構築して集中管理＆コストダウンすることが多いです。


３．運用設計

ハードウェア・ソフトウェアが揃ってバックアップ/リカバリができる基盤ができたとします。

バックアップは時間との闘いと覚えておいて下さい。
とにかく短い時間で完遂する必要に迫られるはずです。

複数サーバーのデータをテープを使って 1箇所でバックアップするには、テープ媒体がシーケンシャルアクセスしかできないため、全てのバックアップを順番に行う必要があります。

あるサーバーがサービス提供時間の関係でどうしてもバックアップサーバーのスケジュールに合わせられない場合は、一旦ローカルディスク上にバックアップを行い、サービス提供時間中にそれをバックアップするようにするなどの工夫が必要です。


そしてバックアップを急ぐ故にやってしまいがちなネットワーク負荷の失念。

バックアップ対象のネットワーク上の位置が、バックアップサーバーに近ければ(C)それほど問題にならないのですが、AやBのようにルーターを挟んだ先にある場合、バックアップサーバーの処理が高速な程、ネットワークの帯域を使ってしまいます。
サービスに提供すべきネットワーク帯域が、バックアップのために一杯になってしまうという本末転倒な状況(赤い線)が発生します。

サービス提供の時間帯からはずらしてバックアップ時刻のスケジュールをしたいものの、同じ線を共有している他のサーバーのサービス時間が被っていたりして、中々運用設計が難しいケースがあります。

バックアップサーバーを極端に集約してしまうと、こういった問題も出ますのでご注意下さい。


バックアップテープの運用で気をつけたいのがテープ媒体のブッ壊れです。
皆さんがよく見た AV(アニメヴィデオですが、何か？)の VHSテープも段々ダメになったはず。
バックアップテープも同じ事が起きますので対策が必要です。

バックアップの冗長化をするには 2本のテープに同じデータを書き込んでおくのが分かりやすくてお勧めです。


毎日のように連続してテープでバックアップを行う時に気をつけたい、テープのプールの設計についてひとつ。

バックアップソフトを使うと複数のテープを繋いで長いテープとして使うことができますので、こういうプールの使い方ができます。


これでやらかしたのが、1本のテープが死んだ時でした。
中に入っていた直近 2週間分のバックアップが全て失われてしまったのです。

バックアップ媒体の容量が大きくなる程、テープ媒体が死んだ時に失われるデータも多くなるということですね。
皆さんが叡智なものを保存しているハードディスクが故障した時のダメージ、最近の方が大きくなってないか？と思ったことはないでしょうか。
アレと同じ仕組みです。

そこでこういう風にテープの使い方を変えました。
バックアップソフトに登録するバックアップのジョブを、取得対象データは同じものの、月〜日で 7つに分け、それぞれ違うテープを使うようにしました。

こうすると 1本死んでも失われるデータが飛び飛びになるので、上のケースよりマシになります。

こんなのも現場の痛い経験から得た運用設計のテクニックでしょう。


その他、結構忘れがちなのが、テープドライブクリーニングのためのクリーニングテープ購入と定期的なクリーニングです。
テープチェンジャーを使っている場合は、バックアップソフトにクリーニングジョブの設定とテープの指定をする機能があります。
単体のドライブで運用する場合は、3ヶ月に１回くらいの間隔でクリーニングをするよう運用手順を作りましょう。

クリーニングテープは使用できる回数が決まっています。
追加購入しないまま、ドライブヘッドが汚れに汚れてバックアップが失敗するとどうしようも無くなってしまいますので、クリーニングテープの使用履歴はちゃんと記録して管理しましょう。


思うがままに書いてしまったので抜け漏れが酷いですが、バックアップ運用について書いてみました。
このネタはもっと拡充しないとダメだな…。

バックアップしたくなってきましたか？