Zenn
🔨

【備忘録】さくらのVPSで容量切れ！　安価な S3 Glacier Deep Archive に急遽クラウドバックアップ

2024/11/15に公開
AWS
S3
備忘録
さくらのVPS
tech

さくらのVPSな自鯖で保存するデータ量の見積もりが甘くて Ubuntu LTS をアップグレードできないぐらい空き容量不足になっていたので、急遽 AWS アカウントを作成して10年ぐらい前の 128GB のデータを S3 Glacier Deep Archive にクラウドバックアップする羽目になったので箇条書きでメモ。

  1. AWS の初期設定の手順はあちこちで書かれているけど、メニューの名前が翻訳されたりして結構変わってるのでできるだけ新しい記事を探したくなるが、記事の内容が割と玉石混合っぽいので、近年に書かれた信頼できそうな記事を探してメニュー名その他を適宜読み替える方が良さげ。
  2. とは言え、企業向けの真面目な記事に書かれている通りに AWS の監視や監査を真面目に設定するとログその他で安価ではなくなりそうなので、今回 AWS Config で2日で $0.2 程請求された（ように見える）のが初月だけなのかとりあえず様子見。
  3. リージョンはとりあえず遠くても安そうなオハイオ(us-east-2)を選択。
  4. AWS は乗っ取りが怖いので各種パスワードは Web ブラウザに生成させてできるだけパスキーを使用。2FA の選択肢にパスキーがなくても「物理ハードウェア」を選択すると選択肢にパスキーと表示される場合がある。
  5. コストサマリー等の一部の項目は AWS アカウントを作成してから24時間経過しないと表示されない。 無料枠超過等のアラート等はその前に届くが、AWS 内に他にも同様のサービスがあるかもしれないので時間に余裕があれば AWS アカウント作成後に24時間経過してから作業を始めた方が良いのかもしれない。（今回は余裕がなかったのでアラートがすぐに届くか不明のまま見切り発車）
  6. AWS でアクセスキーを使わずに SSO で認証するために IAM Identity Center を有効化したら初回時に組織インスタンスとアカウントインスタントを選択する画面が表示されたが、AWS で SSO を利用するなら AWS アカウントへのアクセスが可能な組織インスタンス一択なので注意。「個人用途だしアカウントインスタンスで問題ないでしょ」と判断して結構はまった。[1]
  7. はっきりとは分からないが作業が長時間かかる場合は AdministratorAccess のセッション期間も長めにしておいた方が良いかもしれない。（デフォルトは1時間なのでセッション期間がこちらで律速される？）
  8. ウチでは AWS CLI で SSO する際にいきなり w3m が起動したが、入力するコードは Ctrl+Z しないと表示されなかったし、結局 w3m ではコードを入力できなかったので w3m を閉じた後に表示された URL とコードで認証した。[2]
  9. 最初、S3 のストレージクラスはバケット単位で設定すると勘違いしていたので、S3 Standard でアップロードしてしまった。バケット内のオブジェクトは aws s3 cp で --storage-class DEEP_ARCHIVE を指定して同じオブジェクトにコピーしないとストレージクラスを変更できないらしい。
  10. 今回はほぼ不要な圧縮済みの多数のファイルを念のためバックアップするので、個々のファイルを aws s3 sync はせずに 128GB のtarアーカイブ1つにまとめてアップロードすることでオブジェクトのパディングとメタデータとリクエスト数を節約したが、tarファイルを作成する空き容量はないので tar cf - | aws s3 cp - ... で tarストリームを直接アップロードする。
  11. tarストリームのチェックサムは tar cf - hoge/* | tee >(sha256sum >hoge-checksum.txt) | aws s3 cp ... のように途中で tee コマンドにパイプして計算することになるが、S3 のオブジェクトのチェックサムはバケット内でのコピー時にチェックサムをオプションで指定して整合性をチェックする以外に確認方法がないらしく、一度 S3 Glacier Deep Archive にしてしまうと復元に12～48時間程度かかるらしい（？）ので注意。 [3]
  12. aws s3 cp - で 標準入力をアップロードする際は最終的なファイルサイズが不明なので、ファイルサイズが 50GB を超える時は --expected-size オプションで予め容量のヒントを与えておかないとコケるよ！ と AWS CLI のコマンドリファレンスに書いてあった。実際、見事にコケた。[4]
  13. 同様に標準入力をアップロードする際はコンテンツタイプも不明なので、 --content-type オプションで application/x-tar(tarアーカイブの場合) を指定しておくこと。
  14. さくらのVPS（大阪第3ゾーン）からオハイオ(us-east-2)リージョンへのアップロードはほぼ 100.0mbps のまま推移して接続が切れたりはしなかった。後からリソースを制限されたりしないかちょっと不安だったが、今のところ問題ない模様。

後で何か思い出したら追記予定。

脚注

  1. 一度アカウントインスタンスを選択してしまうと削除してから同じリージョンで組織インスタンスを作成できるようになるまで結構待たされるし、なぜか AWS Organaizations で IAM Identity Center の信頼できるアクセスの有効化を強制（回避できなかった）されるし、再有効化するとアカウントインスタンスを選択できなかった（時間が経過すれば表示された？）。 ↩︎

  2. どうも AWS CLI を実行中の端末エミュレーターと Web ブラウザが別画面に表示されることを前提にしていたっぽいが、w3m で認証できなかったのは AWS CLI か認証ページのバグかもしれない。 ↩︎

  3. チェックサムをアップロード直後に確認したければ最初は S3 Standard でアップロードしてから aws s3 cp でストレージクラスを S3 Glacier Deep Archive に変更する際に保存したチェックサムで整合性をチェックするしかない？（識者の意見求む） ↩︎

  4. 今回は 100GB まではアップロードできたが upload failed: - to s3://hoge/hoge.tar An error occurred (InvalidArgument) when calling the UploadPart operation: Part number must be an integer between 1 and 10000, inclusive
    と表示された。 ↩︎

Discussion