AWS

個人写真のS3へのバックアップに際するキーポイント

iCloudの残量がなくなってきたので、写真のバックアップをS3にアップロードした。 これは、あまり良い方法ではなかったのだと思うが、一応記録に残しておく。

そもそも、プライベートなものをネット回線にさらすこと自体が多大なリスクである。 特に記録を残しておきたいのは以下の3点。

• HASHの記録は「CRC64NVME(推奨)」で行う
• ストレージクラスを標準でアップロード
• ストレージクラスをGlacierに変える

HASHの記録は「CRC64NVME(推奨)」で行う

アップロードが成功したかどうかは、ファイルのハッシュを見る。 SHA256だと、multipartでアップロードされた各パケット全てから算出されるらしい。 これにより、ローカルでファイル単体を見た場合と、ハッシュ値が異なる。 そのため、パケット分割による影響を受けない、ハッシュ計算方法として提示されている、 CRC64NVMEを使用する必要がある。

ストレージクラスを標準でアップロード

言い換えるならば、最初からGlacierでアップロードしないことである。 なぜならば、標準->Glacier系は、リスクは無い。 アップロードに失敗して即削除した場合でも、料金は使用した時間、アクセス分しか請求されない。

しかし、Glacier->標準の場合は、 Glacierの最低日数90日分の使用料が必ず乗る。そのため、即座に切り替えた場合は、使用していない日数分の 料金を支払わなければならない。

そのため、このような手動バックアップの場合は、ストレージクラス標準でアップロードし、 完了後にクラスをGlacier系に切り替えるのが適切と思われる。

ストレージクラスをGlacierに変える

ストレージクラス標準でアップロードを完了したのちに、Glacierの希望のクラスに切り替える。 似たような名前が並んでいるので、この時は気を付けなければならない。

私の場合は、Glacier Flexible Retrieval(旧 S3 Glacier)にしたかったのだが、 誤って別のクラスにしてしまった。なんか、(旧)とかあって不安だったし。 その結果、ライフサイクルルールを設定して、90日後に切り替えるよう設定する羽目になった。

所管

この場合のこの方法は、おそらく適切ではない。

最も高いセキュリティは、インターネットに晒さないこと。 AWSのセキュリティは高いとはいえ、今この状態でも、簡単な操作で全て流出してしまう。 本当は、自宅のラズパイにNAS機能を追加してしまうのが、手間的にもセキュリティ的にも適切なのだと思う。 ただ、イニシャルコストと自分の不勉強が足を引っ張っている。 USBが空いているので、そこにHDDかSSDを入れてしまった方がいいのだろうか。気乗りはしないが。

S3の3つのデータセンターにバックアップされるほどの堅牢性を7円・年/GBで得られるなら安いとは思う。 ただ、それは100GB以内の話であって、1TBレベルになるなら、7000円/年なのだから、HDD1つ買った方がいいと思う。

また、今回のS3によるバックアップを初めて行う際に、調査するのも、記録するのも、多大なエネルギーを使用する。 実質、丸一日使用してしまった。その割には、得られた知識の拡張性は、そうない。 リターンが高い行動を選んでいかなければならない。行動について取捨選択しなければならない。