この記事はえとねるん Advent Calendar 2024 5日目、およびえとねるん Advent Calendar 2023 23日目の記事です。


今日は、自分がちまちまと作っているバックアップ管理ツールxdbmの紹介をしたいと思います。

“バックアップ管理ツール"とは?

xdbmは"cross device backup manager"と名乗っている通り、複数のデバイスでバックアップ(の状態)を管理するために作ったツールです。

具体的なこのようなツールの使いどころとしては、一つのリムーバブルディスクを複数のPCでバックアップしており、そのリムーバブルディスクのデータにフォーカスしてバックアップの状態を把握することができます。

注意点として、xdbmはバックアップ自体は行いません。 理由としてバックアップを行うソフトウェアは世の中に数多く存在し、またその実装はプラットフォームや採用してほしいアルゴリズムなど環境が無数に存在し、開発する必要がないと思ったからです。 xdbmはバックアップの状態を管理・同期することのみに特化させています12。 かわりに、複数デバイスでのバックアップの状態を管理するツールというものは見つけることができなかったため、rustの練習も兼ねて作りました。

xdbmに出てくる概念の説明

device

おおまかに使ってるOSごとに1デバイスです。 PCを2台持っていれば2つのデバイスを使うことになります。

また、デュアルブートしていたり、WSLを使っているときはその分デバイスを増やすのが普通です。

storage

一方、一つのSSDやオンラインストレージサービスはストレージとして表します。

現在、以下の3種類に分類して管理しています。

  • 物理ストレージ: PC内臓のSSDなど。HDD/SSDの情報やファイルシステムの種類を入れることができる。自動認識も行うことができる。
  • オンラインストレージ: Google DriveやOneDriveやS3など。ハードウェア特有の情報を持たない。自動認識も基本的にできない。
  • サブディレクトリ: 他のストレージのディレクトリ。なぜこれをストレージとして扱うのかというと、たとえば特定のディレクトリをファイルサーバーで公開したり、btrfsのようにサブボリュームとして使ったりする場合に、これらは親のストレージからの相対パスとは別の場所にマウントできる(することが多い)から。

deviceとstorageの関係

ストレージをデバイスにbindすることで、そのストレージがデバイスから使えることを表す。 このときにそのデバイスにおけるマウントパスを保存している。

それぞれ、ディレクトリがあるストレージが2つと、デバイスが2つある。各デバイスはストレージごとにマウントの情報を持つことができる。
Relationship of Devices and Storages

backup

デバイスに登録されたバックアップは、そのデバイスにバインドされた2つのストレージ内のディレクトリ間の関係です。

コマンドやメモを保存するようにしていますが、それらはただのテキストでそれほどモデリングされていません。 将来的にはsyncなのかcopyなのかとかを入れるようにしてもいいかもしれません。

Device 1で行われるStorage1からStorage2へのバックアップ
A backup

各バックアップは、過去の実行結果を保持しています。 ステータスとログを保存できるようにしています。

xdbmが真価を発揮するのは、以下のような状況に複数のデバイス上で登録されているが、同じ場所をターゲットにした複数のバックアップが存在するときです。

さらにDirectoryのサブディレクトリ間を対象とするdevice2上のバックアップが追加された
Two backups on two devices

xdbmでバックアップ状況を同期しておけば、このようなバックアップをしているときに、Storage1上のこのサブディレクトリのバックアップ状況を得ることができます。

技術的な話

現在、xdbmはRustで実装されています。ライブラリクレートなしで作ってます。 このシステムで一番大事な同期には、git3を使っており、そのため、各情報はすべてテキストファイル(yaml)で保存しています。 yamlへの読み書きのために、serdeを使っています4

CLIツール関連のクレートが充実していて、かなり楽でした。

クロスプラットフォームなパスの取り扱い

xdbm自体は今年の3月に0.1.0をリリースしてた(https://crates.io/crates/xdbm/versions)のですが、実は当初の目的であるクロスデバイスでバックアップの状況を把握できるというのは最近まで部分的にしか達成できていませんでした。

その原因が、Windowsと*nixでパスの区切り文字が異なっていることです。 PathBufは内部的にはOsStrなので、yamlファイルにおいても区切り文字が異なっていました。

直接的にあるディレクトリのバックアップ状況を見るためのコマンドを実装しているときに気づきました(8月)。

最終的に、クロスプラットフォームでみれるパスなはずだから、UTF-8の文字列のリストになるだろうということでそのような変更を行って5この問題は解決しました(#17)。

簡単な使い方

最後に簡単な使い方を説明します。

インストール

まず、前提として、gitが入っており、ユーザー名などの設定が終わっている必要があります。

cargo

Rustをインストールしていれば、cargo install xdbmでインストールできます。

Rustのインストール方法はこちらを見てください。

自分はWindowsやraspiではこれでインストールしています。

Arch Linux

ここにPKGBUILDがあります。

バイナリ配布はしないの?

xdbmはlibgit2を使用している関係で、libcだけでなく、opensslも環境依存のものになってしまってます。 オプションで外すこともできるので、将来的にはオプションでスタンドアロン版も作れるようにしたいと思ってます。

特にraspiとスマフォでのビルドが大変。

セットアップ

なんと、xdbmはシェル用の簡易的な補完スクリプトを出力できるようにしてあります。 なので、まずはこれを実行することを推奨します。

pwshなら

xdbm completion powershell | Out-String | iex

fishなら

source (xdbm completion fish)

とかでしょうか。

詳しくは

xdbm completion --help

をご覧ください。

1台目

リポジトリとデバイスのセットアップ

最初はリポジトリとdeviceのセットアップを行います。

xdbm init <device name>

リポジトリはconfigdir/xdbmにできます(xdbm pathで確認できます)。

cd (xdbm path)

して、中身を確認してみましょう。

xdbmのリポジトリの中身

いろんな操作をするたびに自動でコミットが積まれていきます。

ストレージの追加

次に、ストレージを追加しますが、普通そのデバイスのメインのストレージを登録すると思います。 そのために、xdbm storage add physical <storage name>を実行します。 自動的にストレージを取得してくるので、そのリストから上下矢印で選択します。

xdbm storage listを実行したり、リポジトリのstorages.ymlをみるとストレージが追加されたことが確認できます。

他の種類のストレージについても同様に追加できます。 適宜--helpを見てください。

バックアップの追加

必要なストレージの登録が終わった後はバックアップを登録します。 バックアップの追加は以下のコマンドで行います。

xdbm backup add --src </path/to/source> --dest </path/to/destination> <backup_name> external <cmd_name> [note]

--srcがバックアップ対象、--destがバックアップ先です。 backup_nameはそのバックアップにつける名前(一意につける必要があります)で、<cmd_name>にバックアップに使うツールの名前を入れます。 noteはオプションでバックアップツールに関するメモを残す場所です。

バックアップ完了の記録

バックアップの追加が終わったら、実際にバックアップをした記録を残します。

xdbm backup done <backup_name> <status>

一応statusには成功した場合は0を入れることになってます。

2台目以降

つぎにこれを2台目でも使えるようにしていきます。

セットアップとデバイスの登録

まず、gitのリモートリポジトリを用意して、1台目のxdbm pathのリポジトリをpushします。 そして、2台目では、xdbm init --repo-url <repository url> <device_name>pullとdeviceの登録を行います。 この時の認証は公開鍵認証のみに対応していて、ssh-agentを使う(デフォルト)か、秘密鍵を指定して行います。

ストレージのバインド

オンラインストレージやリムーバブルディスクは既に1台目で登録していても、2台目で使うことがあると思います。 しかし、この時点では1台目で登録したストレージは2台目ではバックアップの対象として使えないです。 xdbm storage listをすると一番右のマウントパスが全く表示されません。

そのようなものはxdbm storage bind --alias <alias> --path <mount_path> <storage_name>で2台目に登録します。 aliasはデバイス固有の名前をつけることを想定しています(正直ストレージ自体の名前に統合してもいいかも)。 もう一度xdbm storage listすると、ちゃんと右側に表示されることが分かると思います。

あとのバックアップの登録と記録は1台目と同様に行うことができます。

バックアップの状態の確認

バックアップの確認は主に2つのコマンドで行えます。

一つ目はxdbm backup listでバックアップ全体もしくはそこからデバイスや対象に応じてフィルターしてリストを表示してくれます。

xdbm backup list

二つ目はxdbm status -sb <target>で、targetをカバーしてるバックアップをまとめて表示してくれます。

xdbm status

なんか同じようなことするのにコマンドが複数あったり、自由度が低い気がしたりしてるので、このあたりはいいアイデアがあったら改修したいなと思ってます6


おわりに

意外と長くなってしまいましたが、xdbmについて書いたことはあまりなかったので、書いてよかったと思ってます。

あと、えとねるんアドカレに大遅刻してしまいました7


  1. execvで実行する、程度の機能はつけてもいいかもしれませんが ↩︎

  2. Unix哲学 ↩︎

  3. libgit2です ↩︎

  4. 実はこのライブラリは開発が止まってるので移行しないといけないです(https://crates.io/crates/serde_yaml)。 ↩︎

  5. つまりそれまで使っていたデータのフォーマットに破壊的変更が入りました。手作業で編集する必要があります。 ↩︎

  6. SQL的に問い合わせできるとか? ↩︎

  7. https://misskey.qwjyh.net/notes/a2g24t34s3 ↩︎