資産管理ツールに、バックアップ機能をrustで実装するメモ
yunaバックアップ処理自体の実装は１から行わず、外部のツールを利用することにする。
候補は以下
restic
→go製で追加モジュール不要、cloud stoageにも対応している。比較的歴史もあり安定してそう。
CPU:Intel(R) Core(TM) i5-8365U CPU @ 1.60GHz
メモリ16GBのノートPCで、80G程度をwasabi storageにアップ→高速な回線で約３時間50分程度。
同ディレクトリに対し、変更無しで再度バックアップ実行→約１時間
rustic
resticのバックアップ仕様に基づいたrust実装
→cloud storageはrclone経由での実装。windowsはまだexperimental。
触ったところ、高速かつresticに加えていくつかの柔軟なオプションが使えて非常によさそう。
やりたいと考えているリアルタイムバックアップができそうなのはこれだけ。（対象ディレクトリのバックアップの際、指定ディレクトリ以外に変更が無いことが分かっていれば、オプションで指定できる。他のツールはこれができない）今後に期待。
duplicati
→機能は比較的良さそう。webベースのUIと、コマンドベースのCUIが用意されている。
windows以外はmono経由で若干使いづらい。候補外
duplicacy
→機能的には良さそうだが、商用は有料なので候補外
conserve
rust製。s3などのcloud storageも考慮されてそうだが、まだ未実装っぽい（？）
→今回は候補外だが、作者が別プロジェクトが落ち着いたら手を付けるとのことなので今後に期待
#現状と 今後の展望
バックアップ時の暗号化は、どのツールも行われていそうだが、後発の方が効率性がより追及されている印象。
現状、最優先の要件は
・windowsのPC移行サポートツール
だが、リアルタイムバックアップも早々に行いたいので、
取り急ぎresticで構築してみて、その後rustecでwin/linux/mac で動作確認をしていく。
バックアップは、資産管理ツールの１機能として提供する。
資産管理ツールはrust製なので、resticもrustでprocess::Command経由で呼び出す。
yuna問題発生
resticを使って、file:514410, folder: 57427, total80GBをubuntu上でリストアすると、
直接resticのbinaryから実行したときは数時間で完了するのに、rustからCommand経由で実行すると、超低速で終わらない（CPUを全然消費してない）。
対応
もともと、資産管理ツールのbackgroundでtokio runtimeによる非同期loop処理を行っているアプリから、
buckup命令を受信したら、Commandでresticバイナリを実行していた。
backupの前後処理を含めてrustのバイナリを資産管理ツールから分離させたところ、解決した。
修正前
bin/background.rs→処理に関するloop処理で、命令受診時にtokio::process::Commandでresticを実行
修正後
bin/background.rs→処理に関するloop処理で、命令受診時にtokio::process::Commandでbackupを実行
bin/backup.rs→ここから、resticを実行
検証がしっかりできていないが、恐らく非同期runtimeの制御に問題があり、
restic実行に必要なCPU・メモリの割当がうまくいってなかったと思われる。
が、プロジェクトの構成的にも、バイナリを用途ごとに分解したほうがbackground実行時の使用リソースが減るので善しとする。