8月です。あっついです。
今年も酷暑のようで、今後涼しくなることはないのかなぁ、かなしみ。。
さて、タイトルにもある通り、今日はバックアップについて考えてみようと思います。
なにかあたらしい仕組みを作った、というより、今の自分の考えの整理としてのメモとして捉えてもらえればと思います。
そもそもバックアップってなによ
哲学的なテーマみたいですね笑
今更なによ、もう今誰もが知っているじゃない？と。
バックアップとは？
パソコンやスマホのデータが消えたり壊れたりしたときに備え、同じデータの複製を別の場所や機器に保存しておくこと
うーん、当たり前のことですね。
とはいえ、きちんとバックアップをされている方は果たしてどのくらいいるんでしょう？
バックアップの重要性
なにかあったときの保険という考えではあるものの、意外と「何か起きたときに初めて考える」という方も多いのではないでしょうか。
もちろんデータそのものの重要度にもよるのですが、私自身バックアップに救われたり、泣かされたりした経験がありました。
自宅PC・NASのバックアップ
かなり昔ですが、自宅にNASを立てていました。
Synology製のDiskStationという機種で、4Bayが搭載されている家庭用としてはなかなかのスペックだったと記憶しています。
※以下は所有していた機種に近いもののイメージ
この機種は結構高機能で、VMインスタンスが立てられたり、バックアップ専用アプリが公式から提供されていたりしました。
私はこれを自宅サーバ兼NASという、オールインワンのWorkstationとして運用をしていました。
24時間稼働させながら、WEBコンソールやアプリなどから管理操作が可能、簡単なバッチやスクリプトも動かせる、ストレージのRAIDも簡単に設定が可能なのですが、それ以上に存在感のあるデバイスが自宅にある...！という優越感に浸っていたのが大きいです。
課題もあった
色々運用していく中で、課題もありました。
ストレージの交換や管理がめんどくさい
NASのスロットベイには安価なHDDを4基搭載していたのですが、24時間/365日の連続稼働の負荷に耐えられるように、Western Digital RedというHDDを購入していました。
NAS用に設計されたHDDとあって、通常のHDDと違って耐久性や信頼性が高いです。
その分値段もお高めなのですが、1回どこにでもある普通のHDDを使ったところ、わずか半年でディスク不良を起こした経験（個体差かもしれませんが）があるため、多少値段が張ってもNAS専用に設計されたHDDを購入するようにしていました。
それでも長期間使っていれば故障は発生します。
故障頻度が少ないとはいえ交換は手間ですし、ランニングコストもかかってきます。
古いHDDの処分も地味に面倒。
念のためゼロフィルフォーマットをしていたのですが、地味に時間かかるし、故障ディスクなので中古品として売却もできない。
監視やデータロストのリスク
また、故障の予兆や不良セクタの発生率などもモニターしておく必要がありました。
通常メールで通知が来るのですが、意外とメールを見落としていて、時間が経って後から気づくことも多いです。
RAID5で組んでいたため、もしディスクが2本以上故障した場合、データはおじゃんになってしまいます。
そういったデータロストのリスクに神経を使うのも、運用していくと面倒と感じるようになりました。
スケールアップの難しさ
RAID構成である以上、ストレージ容量の増設が簡単ではありません。
増やす場合は現在より容量の大きいHDDを4つ新規で購入しかありません。お金も時間もかかるのです。
事件が起きた
NASのディスク容量が80％を超えたあたりで、一度ストレージの整理をしました。
不要なファイルやキャッシュなどを削除し、ディスク空き容量を増やすためのワークアラウンドでした。
不要ファイルの判定は自分の目で見てジャッジしていたのですが、このとき誤って父のPCにあったデータを消去してしまうという事件がおきました。
バックアップとして取っていたカメラの写真データだったのですが、私が禄に確認もせず、キャッシュデータと勘違いして消去してしまったのです。
オペミスに気づいたのはストレージ整理が終わってからでした。
一応Rewindという復元する機能が標準で搭載されていたのですが、ストレージ空き容量の確保が目的だったので、ゴミ箱の中身やスナップショットなども含めて完全削除してしまったのも失敗でした。
父に謝罪をし、復元ができないことを伝えたときのガックシした顔は忘れられません。。
本当に申し訳なかった。
この話の本当にたちの悪いところは、この事件後になんと同様のデータ誤削除をやらかしてしまうのです。
新規バックアップ設定をしかけるときに、誤って同期元と同期先のパスを逆にしてしまったのです。
ミラーリングバックアップで設定していたため、当然同期元のデータがすべて吹き飛ばされてしまいました。
あぁ無情...SourceとDestinationを誤るとこのように悲惨なことになるのですね。。
何がいけなかったのか
この事件の根本原因は人間によるオペレーションミス、つまりヒューマンエラーでした。
むしろヒューマンエラー以外の要因（ディスク・RAID故障）でデータロストが発生したことは一度もなかったのです。
Rewind、スナップショットによる定期断面も自動で設定されていたのに、自らの手で闇に葬ってしまったのです。
これほど人間が愚かなことはないでしょう。
消して大丈夫だと思った、確認したつもり、元に戻せるだろう
このような思い込みによる冒進というのは大変危険だということです。
はい、反省しています...
どうしたらよかったのか
例えシステムで厳重にバックアップし、ユーザを最小権限で絞り込んでいたとしても、管理者権限をもつ人間の判断が誤っていたら全て吹き飛びます。
もちろん複数の人間による何十ものチェックをかければミスの確率は下がるでしょうが、すべて素通りしてしまったら意味がありません。
だからといって、一度もメンテナンスもせずデータ整理もしない、というのは運用上無理があります。
いきなりすべて削除をするのではなく、段階的に削除をするといった方針がよいかと思います。
- 削除したいデータを洗い出す
- 利用者など第三者がいる場合は事前にアナウンスする（同意を得る）
- まずはゴミ箱などに移動する
- ゴミ箱からの削除（完全削除）や、スナップショットの削除は手動でやらない。
など、段階を踏んでいれば大きな事故にはつながりづらいと思います。
しかし、今回は自宅サーバで管理者が自分1人だけのケースになるので、自分自身がこのルールを遵守しなければなりません。
当然外部から監査があるわけでもないですし。
究極の方法
そこで、コストはかかるのですが、クラウド環境にイミュータブルバックアップを行うようにしました。
イミュータブルバックアップとは？
イミュータブル（Immutable）バックアップとは、一度保存したバックアップデータを、指定した期間中、管理者であっても変更・削除・上書きできないように保護する仕組みのことです。ランサムウェアによるデータの暗号化や、人為的ミス・内部不正による改ざんを防ぐ強力なセキュリティ対策として注目されています。
一般的にランサムウェア対策として強力な効果を発揮する方法ですが、人為的なミス抑止にも大きな効果が期待できる方法でもあります。
仕組みとしてはWORM（Write Once, Read Many）技術やオブジェクトロック機能を利用するものです。
今回Amazon S3にイミュータブルバックアップをするようにしたのですが、S3 オブジェクトロック機能が提供されており、コンプライアンスモードを使って削除できないようにしています。
欠点もあります。
最初に書いた通り、バックアップを冗長化するのでコストが2倍になります。
また、誤ってデータをイミュータブルバックアップにしてしまうとそのデータを削除することができなくなります。
ここで重要になるのはバックアップの設計になります。
- どのデータをイミュータブルバックアップにするのか
- どのくらいの期間保持するのか
- 特別な権限をもつユーザだけ削除可能とするか？ or いかなるユーザであっても削除不可とさせるか？
すべてのデータの冗長バックアップを取り、イミュータブルバックアップにすればセキュリティはかなり上がりますが、同時にコストも大きく膨れ上がります。
クラウドはスケーラビリティに優れるサービスですが、コストは青天井なので下手したら破産します。。
重要なデータとお金を天秤に掛ける必要がありますので、必ずしも万能というわけではありません。
しかし、今回テーマとしている人為的なミスによる消失を防げる強力な手段となっています。
現在
自宅においていたNASですが、数年前に手放しており、現在はローカルにストレージ機器はありません。
デバイス管理が面倒だったのと、思った以上に利用機会が減ったためです。
私の環境ではオンラインストレージをメインで利用しております。
多少コストがかかりますが、自宅にPC/サーバ機器をおかずに済むのが魅力でメンテナンスフリーで使えます。
大きく3つのオンラインストレージサービスを利用しています。使い分けとしては以下の通り。
- Amazon S3
- アーカイブ領域としてS3 Glacierを利用。オブジェクトロックとバージョニングが有効化されています
- 保存コストは最安ですが、取り出し料金や通信料金がかかるため、基本は塩漬けや長期保存を目的としている
- pCloud
- 元NASの後継。クライアント用アプリが多数提供されていたり、他サービスとの連携が充実しているので現在のメイン利用領域
- Endpoint（データセンター）がEUとUSしかなく、ストレージI/Oが貧弱なため、3つの中で最もパフォーマンスが悪い
細々としたデータ、日常的によく使うデータ、カメラロールの写真のバックアップなどで利用
- Cloudflare R2
- S3とpCloudの中間的な存在。S3のようにIN/OUTの転送料金がなく、AsiaにEndpointがあるのでパフォーマンスも良い
- クラスA操作・クラスB操作がS3と比べて割高なので、頻繁にAPI操作をするバッチ処理などと相性悪いかも？（それでも微々たるものと思うが）
S3 Standardストレージクラスと比較すると単価が安いが、Glacierよりかは高い（そもそもR2側で提供されているストレージクラスが少ない）
PCやサーバなど、大容量データの定常的なバックアップ先として利用
3つにしているのは、サービスによって料金体系や特性・機能面が異なるため、使い分けるようにしています。
コストに関しては、すべて合わせて月数千円に収まるようにしています。
課題としてはバックアップ用のapplicationの選定です。
pCloudは置いておいて、S3やCloudflareはCLIなどが基本になるので、なるべくグラフィカルで高機能なバックアップ製品があったらよいな...と考えています。
（最近Veeam製品をトライアルしてます）
バックアップの3-2-1ルール
今回バックアップをテーマにした記事でしたが、どちらかというとバックアップの消失という観点の記事になりました。
キーワードとしては
- 3-2-1ルール
- 3-2-1-1-0ルール
というものが違いかと思いますの、興味のある方はベストプラクティスなどを探してみてくださいませ。