mysqldumpやtarでサイトのバックアップを取得することはよくあると思います。
実データと同じサーバに保存しておけば操作ミスのリカバリーに有用ですが、それだとサーバのデータが飛んでしまうとどうしようもないので、バックアップは実データとは別のストレージにするのが鉄則です。
とはいえ念のためサーバ内にもバックアップが欲しい！というときには、少し工夫すると1コマンドでサーバとリモートに同時にバックアップを保存することができます。
数サイトくらいでは同時に実行せずとも良いのですが、多数あるとそれなりに所要時間が違ってきて役に立ちます。
さらに、今回はバックアップの所要時間を減らしたいというケースに遭遇したので、この機会にパターンをいくつか用意してコマンドと所要時間を比較してみました。
ここでは、AWS S3をリモートの保存先とした例を記載します。
mysqldump
mysqldump は出力先がstdoutなので、ファイルとして保存する際にはリダイレクトを利用します。
合わせて gzip で圧縮してあげると容量が節約されていい感じです。
mysqldump --defaults-extra-file=${HOME}/.mysql/login ${DB_NAME} | gzip | tee ${DB_NAME}.sql.gz | aws s3 cp - s3://${BUCKET}/${FOLDER}/${DB_NAME}.sql.gz
ポイントは、 tee でデータの流れ先をファイルとstdoutに分岐させるところになります。
aws s3 コマンドがストリームをソースとして使えるところもありがたいですね。
tar
tar についても、fオプションを使わなければ出力先は stdout になりますので、その後は mysqldump と同様に扱えます。
tar cz ${DIR_NAME} | tee ${DIR_NAME}.tar.gz | aws s3 cp - s3://${BUCKET}/${FILDER}/${DIR_NAME}.tar.gz
(おまけ) 所要時間の最適化について
12GBのディレクトリ test を圧縮してローカルに保存し、かつS3にも保存するケースでコマンド別に完了までの所要時間を比較します。
Command 1. tarでフォルダを1ファイルに圧縮して保存し、その後S3にもコピー
tar czf test.tar.gz test/ && aws s3 cp test.tar.gz s3://${BUCKET}/test.tar.gz
よく使われるケースと思います。この所要時間を基準とします。
所要時間: 10m 19s
Command 2. tarの圧縮とs3へのコピーをワンライナーで実行
tar cz test/ | tee test.tar.gz | aws s3 cp - s3://${BUCKET}/test.tar.gz
所要時間: 9m 54s
1ファイルでは思ったほどの差異はありませんでしたが、Command 2.の方はCPU使用率が低く抑えられており、並列で複数フォルダを同時実行するのにも耐えうる状況でした。
一方で Command 1. の方は tar 実行時にCPUをフルに使っており、処理の並列化はやや難しそうでした。
Command 3. gzipのレベルを調整
tar c test/ | gzip -v4 | tee test.tar.gz | aws s3 cp - s3://${BUCKET}/test.tar.gz
所要時間: 6m 23s
gzipを個別に実行し、かつ圧縮レベルを4に落とした例も確認しました。
速度は大幅に向上し、圧縮後のサイズは 3.5GB -> 3.6GB へと増えましたが多くの場合にて許容範囲となりそうです。
結果のまとめ
以下の結果となりまして、圧縮レベルもそれなりで所要時間の短いCommand 3.を採用することにしました。
なお7zipやbzipも試してみたのですが、圧縮レベルの割に所要時間が激増したので利用は難しかったです。用途次第ですね。
| Command 1. | Command 2. | Command 3. |
|---|---|---|
| 10m 19s | 9m 54s | 6m 23s |