🔥

災害時の備えとして、自宅NASのデータをすべてS3 Glacier Deep Archiveにバックアップしておく

2023/06/12に公開

自宅のNASなどにテラバイト級のデータを保有している場合、そのバックアップ先はなかなかに悩ましいものです。

RAIDで十分と考える人もいるかもしれませんが、肝心のバックアップデータが自宅内に置いてあるなら、地震などの災害で家ごと潰れてしまえば何の意味もないですし、それどころか最悪データを失うことが心の引っかかりになって逃げ遅れてしまう恐れすらあるので、クラウドバックアップは必須だと思っています。

お金が無限にあればDropboxやGoogleドライブのようなフルマネージドなクラウドストレージに同期しておけばよいのですが、数テラバイトにもなると毎月まあまあの金額になってしまいますし、あくまで非常時用のバックアップであってデータの読み書きはほとんどしない想定なので、DropboxやGoogleドライブはオーバースペックでもったいないと思ってしまいます。

そこで自分は日次バッチで S3 Glacier Deep Archive に保存しています。8TBぐらいのデータをバックアップしていますが、毎月500円ぐらいの費用で済んでいます。

https://twitter.com/ttskch/status/1629808284684398592

というわけでそのやり方をメモがてら残しておきます。

ちなみにこの記事を書いたあとで知ったのですが ディザスタリカバリ という言葉があるようです。

1. S3バケットを作る

普通に非公開のS3バケットを作ってください。
その際、最も単価の安いus-east-2(オハイオ)かus-west-2(オレゴン)を選ぶようにしましょう。

参考:料金 - Amazon S3 |AWS

2. cronでaws s3 syncを実行

crontabなどに以下のようなコマンドを設定します。

0 1 * * * aws s3 sync /path/to/nas s3://[バケット名]/ --delete --storage-class DEEP_ARCHIVE

これで、日次でNASのデータ全体をS3バケットにGlacier Deep Archiveストレージクラスを使用してバックアップすることができます。

s3 sync コマンドは特にオプションをつけなくても下層ディレクトリを再帰的に辿ってくれます。
--delete オプションは、同期元(NAS)になくて同期先(S3)にあるファイルを同期先(S3)から削除するためのものです。安全策をとりたい場合はこのオプションはつけなくてもよいかもしれません。

以上。簡単ですね👌

おまけ:間違えて --storage-class DEEP_ARCHIVE を付けずに aws s3 sync を実行してしまった場合の対処方法

これは僕の体験談ですが、メインのMacを買い替えたタイミングで、新しいマシンにcrontabを設定する際、間違えて aws s3 sync /path/to/nas s3://[バケット名]/ --delete とストレージクラスを指定せずに設定してしまい、気づいたときにはS3バケット内の不特定複数のファイルだけがStandardストレージクラスに保存されている状態になってしまいました🙄

このときの対処内容も備忘録としてメモしておきます。

# バケット内の全ファイルの情報をダンプ(ファイル数が多いと数分程度かかる)
aws s3api list-objects-v2 --bucket [バケット名] > s3dump.json

# ストレージクラスがSTANDARDであるファイルのキーだけをリスト化
cat s3dump.json | jq '.Contents[] | select(.StorageClass == "STANDARD") | .Key' | tr -d '"' > keys.txt

# 当該ファイルのストレージクラスをDEEP_ARCHIVEに変更
cat keys.txt | xargs -I{} -S9999 aws s3 cp "s3://[バケット名]/{}" "s3://[バケット名]/{}" --storage-class DEEP_ARCHIVE

最後のコマンドで、xargs-S オプションで大きめの数字を渡しているのは、一部ファイルがめちゃめちゃ深い階層にあってキーの文字数がデフォルトの上限を超えてしまい正常に xargs に引数を渡せなくなる現象を回避するためです。(これに気づかず30分ぐらいハマりました…)

以上。お役に立てば嬉しいです。

参考

GitHubで編集を提案

Discussion