ArkVault：ドライブがLinuxシステム自体を再構築してくれる、BorgBackup用のGUIツール

何も設定されていないまっさらなLinuxインストール環境にバックアップ用ドライブを接続するだけで、ファイル以上のものを取り戻せます。ArkVaultは、暗号化されたバックアップの隣にガイド付きの復元キットをドライブ上に書き込みます。そのため、ドライブ自体がマシンを再構築する方法を把握しているのです。つまり、ドットファイルやSSH鍵、ランチャーのシンボリックリンク、systemdユニットなど、あらゆるものが復元可能になります。

最終的に得られるもの

これらのスクリーンショットは、ダミーデータを使ってサンドボックス環境で実行した際のものであり、私の実際のマシンのファイル一覧ではありません。

4つのプロファイルがあり、各項目のサイズ見積もりがリアルタイムで表示されます。また、SSHキーのような機密性の高い項目が含まれるプロファイルにはロックマークが付きます。『重要なものをすべてバックアップ』ボタンを押せば、選択済みのすべての項目がバックアップされます。

このツールの目的はここにあります。復元ウィザードがドライブ上のインストールマップを読み取り、どの項目がバックアップされたかをカテゴリ別に表示します。機密性の高い項目にはロックアイコンも付きます。

また、メインカタログには含めたくない単発のコレクション用に、ドラッグ＆ドロップモードも用意されています。

項目	値
コード量	Pythonコード約7,900行、ZIPファイル内に50個のファイルが含まれる
Pip依存パッケージ	ゼロ。GTKはシステム側から利用され、requirements.txtは意図的に空になっている
テスト結果	93項目すべてが合格しており、pytestは不要である
ZIPファイルのサイズ	116 KB（Borgの実行ファイルは同梱されておらず、インストーラー側でダウンロードされる）
サンドボックス環境での復元テスト	8項目すべてが新規作成された$HOMEディレクトリ内に正しく復元された
私のマシンにおける夜間バックアップ時間	2026年9月3日～15日にかけて、実時間で51秒から1分31秒であった
1回の夜間バックアップで処理される項目数	2026年9月11日～16日にかけて、222～225項目であった
重複排除効果（私のリポジトリ）	2026年9月9日時点で、188.45 GB相当のスナップショットが18.24 GBとして保存されている
ライセンス	MITライセンスに基づき無料で利用可能

Borgが実際に提供してくれる機能

ArkVault自体はバックアップエンジンではありません。実際の処理は BorgBackup が行っており、ArkVaultはそのフロントエンドに過ぎません。

• 暗号化: repokey-blake2方式を採用しています。暗号キーはリポジトリ内に保存され、パスフレーズによって保護されています。したがって、ドライブを盗まれても何も得られません。
• 重複排除: コンテンツ定義型のチャンク分割を行うため、ゆっくりと変化するホームディレクトリのスナップショットが10個あっても、その分だけ容量を消費することはありません。
• 圧縮: zstdのレベル6を使用します。十分な圧縮効果がありつつ、バックアップ処理が極端に遅くなることもありません。
• 保持期間の管理: デフォルトでは borg prune によって1日ごとのスナップショットが7個、週ごとが4個、月ごとが6個だけ保持されます（設定変更も可能）。これにより古いスナップショットは自動的に削除され、ドライブの容量がいっぱいになることも防げます。

なぜ不変型ディストリビューションの制約が別の設計を必要としたか

私はこのツールを、ルートパーティションが読み取り専用となる不変型のFedoraディストリビューションである Bazzite 上で作成しました。その後、同じ制約を持つ Bluefin へと移行しています。この制約がこのツール全体の設計を形作ることになったのです：

• すべてのインストール先は ~/.local となります。/ 以下には一切変更が加わりません。
• 仮想環境（venv）は --system-site-packages オプション付きで作成されるため、GTK4やPyGObjectは読み取り専用のベースからコンパイルする代わりにホスト側から利用されます。
• pip install borgbackup ではインストールができません（liblz4のヘッダーが存在せず、適切なwheelもないため）。そのためインストーラーは公式リリースの スタンドアロン版 Borgバイナリ をダウンロードします。これはPyInstallerでビルドされ、FUSEも同梱されています。
• sudo の使用は一切ありません。ルート権限が必要な処理、例えばドライブのフォーマットなどは、polkit/pkexecのプロンプトを通じて実行されます。

実際の仕組み：ドライブがマシンを復元する

Borgでは、どのファイルが重要なのか、それぞれに必要な権限は何か、またファイルが復元された後にマシンが再び動作するためには何をしなければならないかが分かりません。通常のバックアップツールではファイルだけが戻ってくるだけで、ユーザー側で各ファイルの配置場所や再有効化すべき systemd ユニットを思い出さなければなりません。一方、ArkVaultでは、そのような情報も含めて毎回のバックアップ時にドライブへ書き込んでいます。

• arkvault-repo/：暗号化された Borg リポジトリです。
• ArkVault-App/：ArkVault自体のソースおよびインストーラーが同梱されており、一時ディレクトリを経由して名前変更することで、コピー途中で中断してもドライブ上に不完全な状態のアプリが残らないようになっています。
• arkvault-install-map.json および RESTORE-README.md：バックアップされた内容の一覧や、特別なツールなしでも読める説明書です。

このインストールマップには、どの項目が機密情報であるかが記載されています。ただし、実際の内容自体は一切含まれていません。

バックアップ実行時の処理内容

バックアップ実行時の流れは単純です。まずカタログと一致するファイルを特定します（存在しないパスはスキップされます）。必要に応じて書き込み負荷の高いサービスを一時停止させ、稼働中のデータベースが一貫した状態になるようにします。その後、borg createおよびborg pruneを実行し、最終的に復元用キットをドライブに書き込みます。

第二のコピーモード：通常のフォルダーをそのままミラーリングする方法

Borgリポジトリは重複排除・暗号化されており、中身が見えない構造になっています。内容を読み出すにはBorgかArkVaultが必要ですが、どちらもインストールされていないマシンの前に立った時には困ります。

そこで第二のモードとしてarkvault mirrorが用意されており、これを使うと通常の$HOME配下のフォルダー構造をそのままドライブに書き出します。復元方法はbash <drive>/restore.shを実行するか、単純にフォルダーをドラッグして戻すだけです。ただし履歴も重複排除機能もない、単一の最新コピーのみが得られる形になります。

「単純にフォルダーをコピーすればいい」という考えが安易すぎる理由は2つあります：

• 機密データも引き続き暗号化される。 exFATにはUnixのパーミッション情報が存在しないため、コピーした.sshフォルダーは誰でも読める状態になってしまいます。そのため機密フラグが付いたファイル群はすべてGPGで暗号化されたtarアーカイブにまとめられます（tar形式ならファイルシステムでは保持できないパーミッションも保存可能）。そしてrestore.shがそれを復号した上で適切なパーミッションを再設定します。
• exFATは大文字小文字を区別しない。 Foo/とfoo/の両方が存在するツリーでも、コピー時には片方に統合されてしまい、まるで正常に完了したかのように見えて実際はデータが失われます。ArkVaultでは事前に大文字小文字の衝突や不正な文字の有無をチェックし、該当するツリーについては.tar.gz形式で損失なく保存するとともに、その理由もマニフェストに記録します。

どちらのモードでもドライブ上には同じ復元用キットが書き込まれるため、いずれの方法を使っても次のマシンで復元作業を行うための情報が得られます。

用心深い安全対策の詳細

主な作業は、以下のような安全対策の実装に費やされました：

• システムディスクのフォーマットを拒否する機能　誤ったドライブをフォーマットしてしまうのは、バックアップツールにおける典型的な災害です。ArkVaultでは /sys/class/block/*/slaves を参照することで、LUKSやLVMのデバイスマッパー構造を辿り、物理ディスクまで特定します。暗号化されたルートパーティションのマッパー名は実際のディスク名とは全く異なるため、単純な名前チェックでは見逃してしまうからです。もしシステムディスクを一切列挙できない場合、ArkVaultは 安全側に振る 動作を行い、一切のフォーマットを拒否します。ただし、実際に実行する際には正確なデバイス名を入力して確認する必要があります。
• 復元時のパス制限機能　不適切または改ざんされたインストールマップであっても、対象ホームディレクトリ外へ書き込みができないようにします。シンボリックリンクでつながる親ディレクトリは解決されますが、末端のシンボリックリンクは意図的にたどらず、ホームディレクトリから逸脱しようとする再配置先も拒否されます。
• ログ内での機密情報の保護　パスフレーズや機密情報として登録された内容は、完全一致チェックに加え apiKey: や Bearer といったパターンに対する正規表現チェックも併用してログから削除されます。
• 復号用パスフレーズの表示機能　初回バックアップ時には、選択不可なテキスト形式でパスフレーズが表示されるため、誤ってクリップボードにコピーされることはありません。「パスフレーズを保存しました」にチェックを入れるまで「閉じる」ボタンも無効になっています。このパスフレーズ一覧は一切ディスクに書き込まれません。万が一パスフレーズを紛失した場合、バックアップデータも永遠に利用できなくなります。
• FAT32はリポジトリとして使用不可　4GBというファイルサイズの上限がBorgの仕様に合わないためです。一方でexFATは、Borgが内部でUnixメタデータも保持していることから警告付きで利用可能となっています。
• 空のアーカイブの作成を拒否　すべてのソースパスが存在しなくなった場合（ドライブがアンマウントされた、カタログ記述に誤りがあったなど）、「正常に完了した」ように見える空のアーカイブの作成をArkVaultは拒否します。
• 任意のタイミングで整合性検証が可能　UIやCLIから borg check を実行することで本格的な整合性チェックが行えます。また「スナップショットを閲覧」機能では、FUSEを通じてアーカイブが読み取り専用でマウントされるため、信頼する前に中身を確認することも可能です。

設定方法

GTK4/libadwaita用のPyGObjectバインディング、udisks2、およびpolkitが必要です。Fedora/GNOME系では標準でインストールされています。Debian/Ubuntuでは次の1行を実行すればよいだけです：

sudo apt install python3-gi gir1.2-gtk-4.0 gir1.2-adw-1

その後、インストーラーを実行します。このインストーラーは再実行しても問題なく安全に動作します：

bash install.sh

これによりアプリケーションが ~/.local/share/arkvault にコピーされ、--system-site-packages オプション付きの仮想環境が作成され、公式のBorgバイナリもダウンロードされます。さらに ~/.local/bin/arkvault およびデスクトップエントリも生成されます。次に：

arkvault probe

すべて問題なければOKです。arkvault を単純に実行するとGUIが起動します。同じコア機能がヘッドレスなCLIとしても利用可能です：

arkvault probe|backup|restore|list|check

実際に重要な作業は「カタログの編集」です。初期状態で用意されているカタログはあくまで例に過ぎません。core/discovery.py、profiles.py、core/quiesce.py、core/containers.py、core/installmap.py の各ファイルには「EDIT ME」と記された箇所があります。新規インストール時に復元できない項目の一覧を作成することが目的ですので、自分で設定内容を書き込む必要があります。

カタログ自体は core/discovery.py 内に記述されており、単なるPythonコードです。各エントリにはホームディレクトリからの相対パス、秘密情報のフラグ、および備考が含まれます。パスは実行時にチェックされるため、存在しない項目を記載しても問題ありません。以下が初期状態で用意されている設定一覧です：

_SETTINGS = [
    (".bashrc", False, "Bash rc"),
    (".gitconfig", False, "Git identity and settings"),
    (".ssh", True, "SSH keys/config/known_hosts (PRIVATE KEYS)"),
    (".config/rclone", True, "rclone remotes (may embed tokens)"),
]

ご自身のホームディレクトリ下に配置したアプリケーションには、復元ウィザードが再実行したり手動での実施を促したりするための再デプロイ手順も記載できます。同ファイル内にはNode.jsアプリ用のサンプル例もコメント付きで記載されています：

redeploy = {"steps": [
    {"kind": "npm", "dir": "my-node-app", "cmd": "npm ci"},
    {"kind": "symlink", "link": ".local/bin/my-app",
     "target": "my-node-app/cli.js"},
    {"kind": "desktop-entry",
     "path": ".local/share/applications/my-app.desktop"},
    {"kind": "privileged-script", "script": "my-node-app/install.sh",
     "via": "pkexec", "manual": True,
     "desc": "Installs udev rules / system units (needs root)"},
]}

最初の一覧からいくつかシェルの設定ファイルを削除しました。ZIP版にもPython仮想環境の作成手順（"kind": "pip"）が含まれています。

最初のバックアップを実行した後、復元用の情報シートをバックアップ先以外の場所に保存し、「アプリをドライブにコピー」ボタンをクリックしてください。自動実行が必要な場合はREADME-SETUPに記載されている systemd ユーザータイマーのテンプレートを利用できます。このテンプレートではパスフレーズはキーリングまたは ARKVAULT_PASSPHRASE から読み込まれます。

復元テスト（サンドボックス）

実際には、このドライブから本物のマシンを復元したわけではありません。私が行ったのは、偽の $HOME 環境を用意し、ZIPファイル内のディレクトリ構造そのままに、サンドボックス内で完全なテストを実施しただけです。

1. ソースを解凍し、install.sh を実行したところ、実際に27.9 MB分の Borgデータがダウンロードされました。
2. arkvault probe を実行したところ、すべて問題なしでした。
3. arkvault backup を用いて、3つのサンプルプロファイルを一時的なドライブディレクトリにバックアップしました。合計8項目が保存され、repokey-blake2を用いたリポジトリの初期化、install-mapやRESTORE-README、自己包含パッケージも作成されました。
4. arkvault list および arkvault check を実行したところ、どちらも正常に完了しました。
5. arkvault restore を実行して、別の新規ホームディレクトリに復元を行ったところ、8項目すべてが正しいパスに配置され、残りの項目については手動で確認するためのチェックリストも出力されました。

依存関係を必要としないテストスイートでは、同じディレクトリ構造に対して93/93の結果が得られました。これにより、サンプルデータにおける処理の仕組みが正常に機能することが証明されています。ただし、大規模で実際のホームディレクトリの復元が問題なく行えるかどうかはまだ証明されていません。

私自身のマシンからの数値です

同じツールが、systemdのユーザータイマーを利用して毎晩02時00分に私のマシンのバックアップを行っています。以下の数値は、そのタイマーユニットのログおよび Borg 自体が出力する --stats の結果から得られたものです。

項目	値
1回の実行でバックアップされる項目数	222～225件（2026年9月11日～16日）
最初にスナップショット作成される SQLite データベース数	1回あたり27～39個、サイズは1.4～1.7 GB（2026年9月11日～16日）
ある1つのスナップショット（2026年9月9日）	元データサイズ17.45 GB、圧縮後14.12 GB、重複排除後は1.62 GB
全スナップショット（2026年9月9日時点）	元データ合計188.45 GB、圧縮後146.78 GB、重複排除後は18.24 GB（約10倍の削減率）
ディスク上のリポジトリサイズ（2026年9月16日）	31 GB
毎晩の実行時間（2026年9月3日～15日）	51秒から1分31秒
2026年9月16日の実行時間	3分8秒
メモリ使用量のピーク値	1.7～2.6 GB（2026年9月3日～16日）

毎晩、リポジトリにはわずか0.85～1.6 GB分の新規データしか追加されません。そのため、15～18 GBほどのソースデータに対しても毎日スナップショットを作成してもコストは抑えられているのです。なぜ9月16日の実行時間が通常の3倍もかかったのかはまだ特定できていません。9月9日に Borg が報告した18 GBという数値と、1週間後にディスク上に確認された31 GBとの差には2つの要因がありますが、それぞれを個別に測定してはいません。すなわち、さらに7晩分の新規データが加わったこと、そして Borg は borg compact を実行した際にのみリポジトリの空き領域を解放するため、ArkVault が同コマンドを実行していないせいで Borg が解放できなかったスナップショット分の容量が残っていることです。これらの統計値が記録された3日間において、Borg は警告付きで終了していました（終了コード100）。ArkVault ではこれを正常な成功とは見なさず、警告として記録しています。

注意点

• このZIPファイルは、元のインストールスクリプトにあったバグを修正しています。 BorgのGitHubリリースにはGPGの .asc 署名が付属していますが、.sha256 ファイルは含まれていません。そのためインストーラーがチェックサムを取得しようとした際に404エラーとなり、set -e の設定によりスクリプト内のフォールバック処理が実行される前にインストールが中断されてしまいました。本バージョンではこの問題が修正され、さらに任意で ARKVAULT_BORG_SHA256 環境変数を設定することで、信頼できるハッシュ値を指定することも可能です。私の環境ではBorgバイナリが既に存在していたため、ダウンロード処理が実行されることはありませんでした。
• FAT32形式だと予期せぬトラブルを招く可能性があります。 ArkVaultではそのことを検知して拒否しますが、多くのUSBドライブは初期状態でFAT32形式になっています。
• プルーニング処理だけではリポジトリのサイズは縮小しません。 ArkVaultは各バックアップ実行後に borg prune を実行しますが、borg compact は実行しません。現在のBorg（私の環境では1.4.4）では、コンパクト処理を行った際に初めてディスク領域が解放されます。そのため時折 borg compact を実行するか、タイマーに登録しておくことをお勧めします。
• 異常終了した場合、リポジトリのロックが残ってしまうことがあります。 borg break-lock を使えばロックを解除できます（GUIにも対応するボタンがあります）。また BORG_LOCK_WAIT=120 と設定すれば、同時実行を試みる処理が即座に失敗せず待機するようになります。
• WALモードで動作中の SQLite では、dbファイル、walファイル、shmファイルをまとめてバックアップするか、あるいはサービスを一度停止させる必要があります。これが「クワイエット処理」の目的です。この処理の再起動処理は finally ブロック内に記述されているため、たとえバックアップ中にエラーが発生してもサービスは正常に復旧します。
• 別のユーザー名で復元することも可能です。 各保存先のパスはホームディレクトリを基準に記録されているため、新しいユーザーでも問題なく復元できます。ただし新ユーザーに割り当てられない所有権情報は手動で確認する必要があり、自動的に無視されることはありません。
• GNOMEキーリングが利用できない環境（ヘッドレス環境やCI環境など）では、エラーになる代わりにメモリ上のパスフレーズとプロンプト入力方式へ自動的に切り替わります。
• 面倒なバグ： 以前は python -m arkvault backup ... を実行しても何も起こらない状態でした。これはGUI側の引数解析処理がサブコマンドを無視し、0を返していたためです。__main__.py では現在はCLI用のサブコマンドが正しく処理されるようになっています。終了コードが0であるだけでなく、実際にアーカイブが作成されたかどうかも確認してください。
• アンインストールしたツールもカタログに残り続けます。 あるツールを削除した後も毎晩のバックアップ実行時に「該当フォルダがリストされているが存在しない」という警告が出続けました。ArkVaultはそれでも処理を続行し、他のデータをバックアップした上でサマリーにもその警告を記載します。対処法としてはカタログから該当エントリを削除する必要があります。
• 配布用のカタログは意図的に空の状態にしてあります。 私が実際に使用しているカタログには重要なデータの保存先が記載されていますが、それは公開用ZIPファイルに含めるべき内容ではありません。その代わりに「Projects/Settings」の例や再デプロイ手順のサンプルが同梱されており（上記の「設定方法」セクションを参照）、構造は同じですが私の環境用パスは一切含まれていません。

関連記事：LLMを使って任意のプロジェクトを自分のシステム向けに適応させる方法 および ArkVaultがバックアップ対象とするスタック。ArkVaultはAIコーディングエージェントを用いて開発されました。

ダウンロード

• Download ArkVault source (zip) 116 KB

個人利用は無料です。役に立ったら、コーヒーをおごってもらえると嬉しいです。