GoogleDriveの版数管理を今日はテストしてみるよ！
版数って、バージョンとかってこと？
そうそう、同じファイルを上書きすると過去の変更前の状態に戻せる機能だよ。詳細はここ見てね。
なんとなくわかった！ けど、バックアップと関係あるの？
この版数管理、実は前から気になっていたんですよね。今日はテストがてら、この機能をtermuxから、GoogleDriveなどクラウドストレージにコピーや同期させる rclone を使って実際に試してみたいと思います。
テストするクラウド環境の用意
クラウドは、GoogleのGoogle Apps（グーグルアップス）にします。gpl.jpドメインは、ここに関連付けてありますので１つ新規のアカウントを用意しました。
15GBの保存容量がありますね！ また何も保存していない状態です。
rcloneという、すごいやつをTermuxに入れる！
rcloneは、以下のオフィシャルサイトにもarm用がビルドされていてダウンロードできますが、これはtermux では使ってはいけません。
Rclone Download v1.53.1
https://rclone.org/downloads/
なぜなら、名前解決の仕組みが違うからです。Termux にはバイナリが用意されていますので、pkg installで入れておきます。
$ pkg install rclone
::
$ rclone --version
rclone v1.53.1-DEV
- os/arch: android/arm64
- go version: go1.15.2なぜ、こっちを使うのかと言うと名前解決の方法が違うからです。termuxパッケージのrcloneを使わないと、認証するとき、エラーになりますので。筆者は、ここで途方に暮れました。
rcloneとgoogle driveの初期設定
先ほど用意した、GoogleDriveのアカウントを使えるようセットアップします。
Google Drive
https://rclone.org/drive/
ここに詳しく書いてありますが、要点は１つ。リモートでセットアップしている場合は、以下の選択肢を n として作業しているPCのブラウザから Googleにログインしてverification codeを入力しましょう。
Remote config
Use auto config?
* Say Y if not sure
* Say N if you are working on a remote or headless machine
y) Yes (default)
n) No
y/n> n以下のリンクを作業しているPCのブラウザで開き認証します。認証するとverification codeが出るのでこれを、貼り付けます。
Please go to the following link: https://accounts.google.com/o/oauth2/auth?access_type=offline&client_id=（省略）
Log in and authorize rclone for access
Enter verification code> ここに認証したコードを確認は、このコマンドでリモート名称一覧が出てきます。この名称は rclone コマンド中に使うので短く覚えやすいのが良いかなと思います。今回は、01bupとしてみました。
$ rclone listremotes
01bup:設定ファイルはホームディレクトリの以下にあります。
$ tree .config/rclone/
.config/rclone/
└── rclone.confrcloneを使ってみる
まず、何もGoogleDriveには入っていませんが一覧を出してみます。
$ rclone ls 01bup:
$ ではディレクトリを作ってみましょう。
$ rclone mkdir 01bup:hackgpljp 確認。
$ rclone lsd 01bup:
-1 2020-09-24 17:46:29 -1 hackgpljp
または、
$ rclone lsf 01bup:
hackgpljp/ちゃんと作られているか、ブラウザでも見て見ましょう。
おお〜！ ちゃんとディレクトリが作られていますね。
テストコードでファイルの履歴を作ってみる
同じファイル名を更新していくと、版ができるので確認してみたいと思います。tmpディレクトリを作り、そこで作業します。
$ cd
$ mkdir tmp
$ cd tmp
$ pwd
/data/data/com.termux/files/home/tmpテストプログラムを作ります。今回は、test.shとしてこのような内容にしました。
$ cat test.sh
#!/bin/bash
PATH=$PATH:/data/data/com.termux/files/usr/bin:/data/data/com.termux/files/home/bin
BACKUP=/data/data/com.termux/files/home/tmp
TXTFILE=a.txt
DRIVENAME=01bup
CPATH=hackgpljp
echo '' >> $BACKUP/$TXTFILE
max=30
for ((i=0; i < $max; i++)); do
echo $i ":" `date +'%H:%M:%S.%3N'` >> $BACKUP/$TXTFILE
echo "rclone sync start : "$i `date +'%H:%M:%S.%3N'`
rclone sync $BACKUP/ $DRIVENAME:$CPATH
echo "rclone sync end : "$i `date +'%H:%M:%S.%3N'`
sleep 1
done動作概要としては、以下となります。
・a.txt に、日付ファイルを追記して、rcloneで同期させる
・回数は、30回（つまり、版が30個できる）
・rclone syncがどのくらい時間がかかるか前後で時刻を出しておく
やっと実験です。tmpディレクトリにはテストPGしかまだありません。
$ ll
total 24K
drwx------ 2 u0_a364 u0_a364 4.0K Sep 25 02:51 ./
drwx------ 24 u0_a364 u0_a364 4.0K Sep 25 02:51 ../
-rwx------ 1 u0_a364 u0_a364 490 Sep 25 02:51 test.sh*では、動かしてみましょう！
$ ./test.sh
rclone sync start : 0 03:00:19.515
rclone sync end : 0 03:00:24.202
rclone sync start : 1 03:00:25.237
rclone sync end : 1 03:00:28.314
::（省略）
rclone sync start : 5 03:00:43.284
2020/09/24 18:00:43 Failed to create file system for "01bup:hackgpljp": couldn't find root directory ID: googleapi: Error 403: Rate Limit Exceeded, rateLimitExceeded
rclone sync end : 5 03:00:43.915
::（省略）
rclone sync start : 8 03:00:54.008
2020/09/24 18:00:54 Failed to create file system for "01bup:hackgpljp": couldn't find root directory ID: googleapi: Error 403: Rate Limit Exceeded, rateLimitExceeded
rclone sync end : 8 03:00:54.603
::（省略）
rclone sync start : 29 03:02:24.355
rclone sync end : 29 03:02:27.609一部、Rate Limitのエラーが出ていますね。テストPGは1秒の待ち時間を入れてありますが、速すぎると制限にひっかかるのでしょうか。rclone syncの処理時間は、このくらいのテキストサイズで3秒〜5秒くらいのようです。
気になることはいろいろありますが、GoogleDriveにバックアップされたか見て見ましょう。
$ rclone ls 01bup:hackgpljp
531 a.txt
490 test.shちゃんと、ローカルのtmpディレクトリ が同期されていますね。
ブラウザーでも見て見ましょう。
大丈夫そうです。a.txtを右クリックして「版を管理」から版数が保存されているか確認してみます。
おー！ 版は現行版を含めて28個ありました。途中2回失敗していたからですね。では、１つ目の版をダウンロードしてみてみましょう。
ちゃんと、最初の1回目のタイムスタンプだけでしたね！
では、１つだけ古い２８版を見て見ましょう。
最新のは、29 こ目のタイムスタンプがあるやつなので、ちゃんと１つ前にアップロードされたファイルのようです。
版は100個以上になるとどうなるのか？
先ほどの、ダイアログ中に版は100個まででそれ以上は削除される可能性があると書いてありました。
「a.txt」の旧版は、保存してから 30 日間経過した場合、または保存した版が 100 個に達した場合に削除される可能性があります。削除されないようにするには、ファイルのコンテキスト メニューで [この履歴を削除しない] を選択します。
どうなるか実験してみましょう。テストプログラムをb.txtとして、回数は110回の上書き保存としてみます。
$ ./test.sh
rclone sync start : 0 03:22:16.889
rclone sync end : 0 03:22:20.567
：：
rclone sync start : 109 03:30:25.700
rclone sync end : 109 03:30:29.008今回はレートリミットのエラーは出ませんでした。ブラウザーで履歴を見て見ます。
ふむふむ！ 版は100までしかないですね。このファイルを見てみます。
108のタイムスタンプなので、最新の１つ前ですね。では、版１を見てみます。
あー、なるほどですね。100個以上前の版は流れているようです。
まとめ
今回、簡単な実験からなんとなく雰囲気がつかめました。
・rclone syncで同期されるが、３〜5秒と同期するファイルサイズにより時間はそれなりにかかる。
・あまり短い間に、上書きするとレートリミットの制限にひっかかるようだ。
・版数は、ちゃんと保存されていて100個を越えると一番古いのが流れる。
容量節約してバックアップを効率的に保存しておくってことだったのね！ やっと意味がわかった〜！っていうか、せこいこと考えるわね！
あとがき
おそらく30日を越えると、履歴は消えるのでしょう。どのように消えるのか興味はあります。また、削除したくない場合は、「この履歴を削除しない」にチェックを入れておけば大丈夫のようですが、まだ未確認です。これを確認するには、３０日以上かかりますので。
でもまぁ、うまく使えば、ログや画像ファイルなどバックアップデータを１日1回、同じファイル名で保存すれば、３０日前までは引っ張ってこれるみたいなので容量は節約できそうですね。
