続・DropboxからGoogle Driveへの移行作業

気をつけなければならないことがいくつかあったので後日談です。
カシマです。

結局のところは以下のような構成になりました。

システム構成

Ubunntu 20.04
python3
dbxcli
dropbox.py
google-drive-ocamlfuse
外部ディスク(拡張できるEBSが望ましい)
lsyncd
rsync
cp

ベストプラクティス

ほぼ前回と変わらないのですが、コマンド関連や外部ディスク必須と記述し直しました。
あまりにも容量が多い場合は外部ディスク自体をEBSとして作業するのが一番望ましいです。

仮に前回お伝えした通りの500GBに留めたとしてもディスクフルになろうものならディスク拡張するだけで回避が可能となります。
あとはrsyncだけで片付けようと思いましたが、いくらコピーしても終わらんという問題にぶち当たり、rsyncだけでは終わらないんでは?となりました。
そこでlsyncしながらとりあえずひたすらデータをcpで送り込み続けるという作戦です。

cpだけだと不安がややあるのでrsyncもぶち込みます。

つまり、こうなります。

  • メインタスク
    • cp -r -a /{移行元の外部ディスクディレクトリA}/サブディレクトリa/* /{移行先の外部ディスクディレクトリA}/
    • cp -r -a /{移行元の外部ディスクディレクトリA}/サブディレクトリb/* /{移行先の外部ディスクディレクトリA}/
    • cp -r -a /{移行元の外部ディスクディレクトリA}/サブディレクトリc/* /{移行先の外部ディスクディレクトリA}/
  • 補間タスク
    • 0 /8 * * * root rsync -vuaP /{移行元の外部ディスクディレクトリA}/ /{移行先の外部ディスクディレクトリA}/ –delete –exclude ‘.‘ –exclude ‘__MACOSX*’ >> /{どっかのディレクトリ}/result/{ディレクトリA}.txt
    • 0 /8 * * * root rsync -vuaP /{移行元の外部ディスクディレクトリB}/ /{移行先の外部ディスクディレクトリB}/ –delete –exclude ‘.‘ –exclude ‘__MACOSX*’ >> /{どっかのディレクトリ}/result/{ディレクトリB}.txt
    • 0 /8 * * * root rsync -vuaP /{移行元の外部ディスクディレクトリC}/ /{移行先の外部ディスクディレクトリC}/ –delete –exclude ‘.‘ –exclude ‘__MACOSX*’ >> /{どっかのディレクトリ}/result/{ディレクトリC}.txt
  • 差分反映タスク
    • lsyncd + rsync

手厚い看護 ってやつです。
実際問題これぐらいやらないと750MBぐらいの作業は終わらないんだな、と悟りました。

詳細解説

メインタスク詳細

数の暴力で cp -r -a で一番しんどいと思われるサブディレクトリを列挙してまとめて実行しておきます。
こうすることでまずcpした時点での全てのデータを移行することになります。

補間タスク

cronぶん回しで8時間で終わらないかもしれませんが、持ってこれていない分を移動させます。
lsyncdも設定次第なんでしょうけど、起動時は同期させていないので取りこぼしが出るかもしれません。
そのための補間とも言えます。
とりあえずrsyncで同期させるのだ。

差分反映タスク

lsyncd + rsyncでリアルタイムに同期します。
リアルタイム同期なので誰かがアップした変更したという作業に対してとても強く、即時で該当ファイルだけを転送してくれます。
最終的にメインタスクが完了すればcronのrsyncを短期間(データ量が多いとなかなか終わらない気がするので6時間ぐらいの期間)で回し、lsyncd + rsyncでリアルタイム同期すればほぼ漏れがなくなるんじゃないかな…と考えています。

忘れちゃいけないぜキャッシュ対応

lsyncdでもrsyncでもcpでもなんでもいいのですが、作業ユーザ(今回はlsyncdを使う関係でubuntuからrootユーザに変更)のホームディレクトリにはgoogle-drive-ocamlfuseのキャッシュが存在します。
このキャッシュファイルがEC2のルートボリュームを占め、rsyncやlsync、cp作業に支障をもたらします。
全ての作業を始める前にそもそも作業データを全て外部ディスクに持っていく作業が必要でした☆(ゝω・)vキャピ

Googleのサポートにもあらかじめ「データってディスク的な面でどういう扱いなんですかね?」とサポートに聞いてたんですけど、まさかこのキャッシュにディスクが苦しめられているなんて露知らず…。

というわけでキャッシュデータも外部ディスクに放り出しますので、以下のコマンドで退避してしまいましょう

fusermount -u {Google Driveの共有ドライブのマウント用ディレクトリ}
cp -r ~/.gdfuse /{外部ディスクのどっかのディレクトリ}/
ln -sf /{外部ディスクのどっかのディレクトリ}/.gdfuse .gdfuse

これで再マウントした上で全てのタスクを走らせれば解決…のはずであるが…終わるかなぁ。
続々報なんてならなきゃいいんですけどネ…。

lsyncdはこんな感じで設定済みです。

cat /etc/lsyncd/lsyncd.conf.lua
settings {
        logfile    = "/var/log/lsyncd.log",
        statusFile = "/tmp/lsyncd.stat",
        insist = 1,
        statusInterval = 10,
}

sync {
        default.rsync,
        init = false,
        delay = 0,
        source="{移行元の外部ディスクディレクトリA}",
        target="{移行先の外部ディスクディレクトリA}",
        delete="running",
        exclude = {".",".*","./",".*/","__MACOSX/"},
        rsync  = {
                dry_run = false,
                rsync_path = "sudo /usr/bin/rsync",
                archive = true,
                links   = true,
                update  = true,
                verbose = true
        }
}

sync {
        default.rsync,
        init = false,
        delay = 0,
        source="{移行元の外部ディスクディレクトリB}",
        target="{移行先の外部ディスクディレクトリB}",
        delete="running",
        exclude = {".",".*","./",".*/","__MACOSX/"},
        rsync  = {
                dry_run = false,
                rsync_path = "sudo /usr/bin/rsync",
                archive = true,
                links   = true,
                update  = true,
                verbose = true
        }
}

sync {
        default.rsync,
        init = false,
        delay = 0,
        source="{移行元の外部ディスクディレクトリC}",
        target="{移行先の外部ディスクディレクトリC}",
        exclude = {".",".*","./",".*/","__MACOSX/"},
        delete="running",
        rsync  = {
                dry_run = false,
                rsync_path = "sudo /usr/bin/rsync",
                archive = true,
                links   = true,
                update  = true,
                verbose = true
        }
}

dry_run = trueにしてから試された方が安全に作業を勧められます。

まとめ

これで終わってくれ…あんまり時間がないんだ…(今月末までのタスク)
(時々停止してたのはディスクフルだぜって言ってたんじゃないか説が出てきたけど全然気付けなかったや…。)

コメントを残す

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください

%d人のブロガーが「いいね」をつけました。