追記 2021-01-27
「“RAID全滅”があり得るように、“クラウドなら絶対安全”もない」、クラウド時代の「データ置き場の考え方」とは？ - INTERNET Watch
最後のキーポイントのところはぜひ読んで、検討しておくべき。
追記 2020-11-10
サーバ管理会社が契約更新ミス 「ふくいナビ」全データがクラウドから消失、復旧不能に - ITmedia NEWS
このようなことも起こるらしいので、バックアップ
追記 2017-02-10
ここまで書き出してみましたが、やり忘れていることがありました。。
維持するのは大変ですが、何かのきっかけになれば。
概要
GitLabの件があり、自分たちの環境を見直してみた。
これ読むといろいろ思い出したし、自分の環境も見直してみようと思った。
追記
日本語でも記事がでていた。
「偶然取った」ってすごい。。。が、自分のところにそんなことがおこるのかわからないので、注意していきたい。
見直したら想定外のことを発見
適切な方法かをもう１度考えるのも良いかもしれない。
自前でバックアップやらないという選択が取れるなら、それが良いケースが多いかと思うが、何らかの事情でいろいろ手元にデータがあり、バックアップの必要があるならば、取ったほうが良いとおもう。
失うと、本当にない。（ことがある。。。）
今、何かバックアップしているなら、確認してみたらどうだろうか？
自分も実際に確認したら、想定と少し違う動きだったので、修正中。
失敗談、自分のだったり、聞いた話だったり
- バックアップを取っていたつもりが、取れていなかった
- 手動で実行した後、実行したコマンドをコピーしたつもりが、先頭の文字がコピーされていなかった
- cronで回したら、カレントディレクトリが違った
- バックアップデータを消したつもりが、本番データを消した
- バックアップが行われていたのは、初回だけだった
- 一回目だけが取れていて、ファイルが存在するために、次が取られなかった
- 一回目を実行した時がrootで、次から専用ユーザにしたため、権限が足りなかった
- 追記するようにしていて、どんどん肥大化した。
- バックアップシステムを壊した
- ファイルシステムを壊してしまった。元に戻せたファイルもあったが、それが本当に壊れていないのかわからなかった。
- バックアップをする必要があるという認識がなかった
- ２次生成物であったので、元に戻せるかと思っていたが、生成するプログラムが更新された。しかし欲しいものは、前のバージョンの生成物
- 論文執筆中の大学生のなんとも言えないオーラを思い出したことがある気もする
- なんかすごく悲しかったような気がするのだが、思い出せない。
- チェックサムを取っていなかったので、コピーしたつもりが、からのファイルだった。
- md5 で d4... となっていた。。
- rsyncしとけばよかった、以後、なるべくrsync
- バックアップの取得方法は適切でなかった
- 仮想マシンを落としたつもりが落としていなかった。
- データを何かかからダンプする場合、ツールの選択が正しいか。
- バックアップを取得しようとしたら、テーブルがロックされてしまいシステムが止まった。
- 以後、バックアップを許可されなくなる可能性がある（そんなことは起こらなかったらしいが。可能性はある）
- バックアップ取得専用のレプリカを作った。今はそんな必要はないかもしれない
- rsync のオプションを間違えた。。
- 仮想マシンを落としたつもりが、物理ホストだった。
- そもそも、実データが壊れていた。空だった。
- バックアップ中にバックアップ先の容量が足りなくなった。
- crontab -e とするつもりが、消す方のやつを、書いてしまって、crontabが飛んだ。それにより、バックアップもできなくなり、バックアップ方法が飛んだ
- 手動でバックアップするときに、screen,tmuxなどを起動していないし、rsyncじゃないしで、手元のネットワーク切断で、バックアップが途中で止まってしまう状況にないか？
- レストア方法を忘れた。。。
- バックアップ先もしくは冗長化構成が、違う場所（業者）だと思っていたら、同じ場所（業者）だった
- 出先作業用のマスターデータとバックアップデータを作っておいたが、同一人物がもっており、その人だけ来ない。
チェックリスト
- バックアップ先が、実は同じシステム（ディスク）ということはないか？
-
毎日バックアップするなら、バックアップができていることを確認したか
- 2日にわたりチェックする
- できれば２人体制で、指差し、声出しで確認したい。
-
バックアップが失敗していることを伝えるアラートシステムがあるか？
- 動いているかを確認したか？
- わざとファイルやディレクトリをどかして、試す。
-
バックアップが失敗していることを伝えるアラートシステムは、ただしく機能しているか？
- ５個のうち１つだけエラー飛ばし続けて、それだけ無視すれば良いやってなっていないか？なっていたら、解消する。
- わざと、アラート状態にする、そして、アラートが飛ぶことを確認し、元に戻したら、アラートが解消されることを確認したか
-
バックアップから元に戻せることを確認したか
- 実際に元に戻して確認したことはあるか？
- 最後にそれをやったのはいつか？最近試したか？
- システム側も０から作ったことはあるか？
-
バックアップサーバの、ディスクの残り容量
- 残り容量問題ないか？
- 残り容量、使用量、可能なら、増加率を、監視できているか？
-
バックアップサーバの残り容量の監視は正しくできているか？、
- 実際にアラートが飛ぶことを確認したか？
- 元に戻したら、きちんとアラート状態から復帰できているか？
- バックアップするデータのデータ量の見積もりをしたか、特に増加する場合。
-
本番環境と、テスト環境とで、ターミナルがわかりやすいか？
- バックアップから再構成するときのテストのターミナルも、わかりやすく、本番とは別れているか？
-
可能なら、多重にとっているか？
- 物理的に別れているか？(2020-11-10追加)
- 物理的な距離として、建物が壊れたとしても大丈夫なくらい、だいぶ離れた位置にあるか？(2020-11-10追加)
- クラウドやバックアップシステムが利用できなくなっても大丈夫な状況か？(2020-11-10追加)
- バックアップ取得時だけ、特殊な操作がいる場合、そこから正しく復旧できるか？
- バックアップ方法について、バックアップがあるか？
-
適切なツールを使っているか？
- rsyncを使う状況ではないか？
- screen, tmuxなどを使う状況ではないか？
-
定期的に（できれば、３ヶ月に１度くらい）、バックアップができているかを確認する
- 可能であれば、アラートが飛ぶかもチェックする
- 増強による停止、停電による停止、メンテナンスによる停止などで、定期実行を止めていないか？
- マシン再起動後、自動で開始するか
- マシン再起動後、自動で開始しない場合、開始していないことはアラートが飛ぶか？
- 定期実行がちょっとずれることにより、アラートが飛ぶのを避けるために、 止めたアラートを再開しているか？
-
仕様書にするならば、正しい仕様書にできているか(2020-11-20追加)
- （対応できるかは不明だが）本当に消す前に連絡がもらえるのか？アラートがくるのか？それは期日的に余裕があるか？
- クラウド等の場合は支払いが遅れた場合、何が起こるのか？
- クラウド等の場合、支払いが遅れた（忘れた、手続きがおくれた、自分いがいのところで手続きがつまっていた）ときどうなるのか？サルベージ方法はあるのか？
- クラウド等でサルベージしないというオプションを自ら指定したか？
- 本当にそれでよいか？
- 自分以外のいろいろな人に確認したか？
- ローカルに絶対とっておくべきデータあるか？
- 個人情報は大丈夫か？
- 個人情報以外の記事は大丈夫か？結構こっちが大事なときもある。それはデータ集めればなんとかなるというのは、あまりそうはならない。ということを伝えたり検討したりしたか
-
手作業で入力したデータは、ローカルにバックアップとれる量か？
- 手作業のデータはサイズが小さいとおもわれるが、労力がはんぱないことを考えて、バックアップを設計したか？
- 手動でバックアップを取ることは可能か？
- 偶然バックアップを手動でとるようなタイミングあるか？復旧時に役立つ
参考情報、反応それぞれ
追記
追記 2017-02-21
- 反応がでてきているので、それも追加してみる。
追記 2017-02-02
- 失敗した事例追記
- Publickeyの記事追加
- 定期的なチェックなどについて追記
追記 2017-02-01
- 定期的なチェックなどについて追記
その他、そもそも他にも気にした方が良いことがあるかもしれない
- お金がかかることもあるので、今回は触れていませんが、バックアップ装置や、どこにバックアップを取るかとか、どんな機材を使うとかなどについても、書いてみたいとは思っています。自分たち以外のところがどうやっているのか気になりました。