Insync CLI版での Debian/GNU Linux への Google Drive からのリストア

Insyncは, Google Drive とローカルドライブとの同期用の有料の3rd party 高機能クライアント+サービス.

特筆すべきは, Linux 用の CLI 版(デスクトップを使わない headeless サーバ 用)を, 無サポートの旧バージョン 1.5.7 ではあるが提供している.

Debian 7 wheezy 用の deb, Fedora Core 24 用の rpm が提供されているが, Delian 10 buster でもインストールできた*1.

使い方は現在でもこの説明が正しい*2.

クラッシュした Linux home の Insync による Google Drive からのリストアの経緯

home を一定頻度でフルバックアップ, Insync でいくつかのフォルダを(同期フォルダ内に home 内のへの symbolic link を作ることにより)常時バックアップしている Debian がクラッシュした.

別の host にフルバックアップをリストアしたのに続いて, Google Drive のバックアップを手動でダウンロードして最新まで戻そうとする. いくつかのフォルダはリモートレポジトリに git push してあったので, pull してきた.

ここで, 別の host に Insync headless をインストールして, 常時バックアップを始めようとした. すると, 「このホストは登録済みです」のようなことを言われ, 同期用フォルダが作られないのに Insync が CPU を使っている状態になっていた. これはなぜかというと, Google/Insyncアカウントや同期用フォルダの情報が home 内にファイルとして残っていて, それに基づいて, 新たにインストールした Insync が動作を開始していたのだった.

ここで不安になるのは, どちら向きの同期が起きるかということ.

  • ローカルのフルバックアップに欠けている最新のファイル群が削除されたと見なされGoogle Drive 側で削除される
  • Google Drive 側のローカルに未同期とみなされ, ローカルにコピーされる

結果論としては後者が起きた. 再現性はチェックしていない. Google Drive 側で作成したファイルも, 旧 host で symbolic link を介して追加されたファイルもあったのだが, 同じ振る舞いだった.

ただ, git pull した部分は履歴情報が壊れたかもしれないわけで, 今後どのように振る舞うか観察する必要がある.

*1:ただし, curses で書かれたメニューベースの選択同期の設定はエラーが出て使えなかった. Python(ライブラリ)のバージョンの問題か?

*2:ただしインストールは dpkg -i *.debで.