※osaponさんの指摘をいただき、処理修正しましたので記事記載も併せて修正しやした！
我が家では、勉強の意味も兼ねて以下のようにしてます。
(aboutにも書いてますが、毎日5:00-6:00に実行してます。およそ実際の処理時間は20分程度で終わってます)
- まず、他拠点側(以降、災対拠点という)と拠点間VPN張っておく(私の場合実家)
- 災対拠点側にNFSサーバを設ける(ウチの場合、ReadyNAS RN104を使ってます)
- 災対拠点側に災害対策サーバを立て、ReadyNASにNFSマウントしておく
- 以下の領域をすべて自宅NFS NAS領域に配置する(現状、これら全体で30GBぐらいす)
DBサーバの/var/lib/pgsql 配下
Redisサーバの/var/lib/redis 配下（これ意味あるのかどうか分からんす)
Web/APサーバの /etc/nginx配下、/home/mastodon配下
- 災対拠点側からrsyncを行い、自宅NFSサーバのデータを頭からpullで引っこ抜く
- ReadyNAS側で30世代のスナップショットを取得する
我が家の自宅側NFSサーバは集合NASと化しており、他にブログのデータやメールボックスのデータなど、様々なサーバの共有ストレージとして動いてます。それらも含めたデータを災害対策の一環として全部転送しています。
この時、APサーバ/DBサーバ側のサービスは全止めしてますが、Redisサーバはそのまま生かしてます。
11/20時点まではDBサーバのサービスも生かしてたんですが、osaponさんの指摘より、タイミングによっては自動vaccum処理が走ってるのをころっと忘れてました。今はDB停止処理も突っ込んでます。
何かしらの設備障害が発生した場合は、本番設備の暫定復旧をかけて、ReverseSyncをして復旧する感じになります。
(これは災対拠点側のIPアドレスが、事情により固定ではない&頻繁に変わることが原因です)
実際運用していて何度か復旧作業を実施する羽目になったことが何度かあるのですが、その際わかったことは以下の通りでした。
- 取り敢えず最低限の復旧として必要なのはDBのデータである
DBのデータさえ残っていれば、とりあえずはなんとか復旧できます。/home/mastodon/liveは最悪gitで引っ張り直して再構築もありだということがわかりました。ただ、アイコンデータやメディアデータ等は消失するため、最低限avatarの再取得が必要であることを確認しています。
- rsync時は–delete必須
当初、rsyncする際は–deleteをつけてなかったんですが、/home/mastodon/live復旧時にデータ不整合を起こし、バージョンアップができない状態になったことがあります。基本的に–deleteをつけた形でミラーリングする必要があると理解しています。
本当は論理バックアップを取得するのが望ましいんだろうなーと思ってますので、他鯖缶各位の方式が望ましいんだろうなとは思ってます。サービス停止を伴わせてファイルを単純取得してる分、方式としては劣るかなって感じです。ただ、実は過去にDB移行を論理バックアップを使用して挑み、大失敗した経験があるため、なかなかそっち側に思考が傾かないのが現状です。(そもそも仕事であんましDBに関する仕事はやらない)
