git-annex - Gitユーザーのための大容量ファイル管理ツール
(git-annex.branchable.com)- git-annexは、大きなファイルの内容をGitリポジトリに直接入れずに管理できるツール
- オフライン・オンライン環境で同期、バックアップ、アーカイブを行い、チェックサムと暗号化で安全性を確保
- Gitの分散特性を大容量ファイルに適用し、複数のドライブ・サーバー・クラウド間での位置追跡と転送を簡素化
- CLI中心のユーザーに適しており、一般ユーザー向けのgit-annex assistantはフォルダー同期型の使い勝手を提供
- 長期保存のためのシンプルなリポジトリ形式と多様なspecial remotesにより、アーカイブ・移行ワークフローを拡張するツール
概要
- git-annexは、ファイルの内容はGitの外に置き、メタデータと位置情報だけをGitで管理する方式の大容量ファイル管理ツール
- その結果、コミット履歴を軽量に保ちながら、大容量バイナリの保管と移動を柔軟に扱える
- チェックサムと暗号化サポートにより、完全性と機密性を保証
- オフライン・オンラインの両方で同期、バックアップ、アーカイブを行い、分散した保存先間で同一ファイルのコピー数管理とログ記録機能を提供
- コマンドラインユーザー向けに最適化されているが、git-annex assistantを通じて一般ユーザーもフォルダー同期の形で簡単に使える
- 初めて使う人向けに**walkthrough**文書を提供しており、インストールや基本的な流れをすばやく学べる
利用例: Archivist（アーカイブ志向のユーザー）
- 複数のオフライン保管ドライブを運用しながらでも、単一のディレクトリツリーで全ファイルをひとつのもののように閲覧・再編成できる
- ファイル内容がオフラインドライブにあっても、インデックスとポインターにより実際に削除するリスクなしで再配置とコミットが可能
- 特定のファイルが必要な時点でどのドライブにあるかを知らせ、容易に利用可能な状態へ切り替えられる
- 各ドライブは相互の位置情報を共有し、全体の保管状況を把握する
- シンプルなリポジトリ形式を採用しているため、git-annexやgitを使わなくても長期的にファイルへのアクセス性が維持される
- cronジョブで夜間に新規ファイルを自動アーカイブし、意図的・非意図的なコピーを記録して複製が必要な時点を判断する根拠を提供
利用例: Nomad（移動中心のユーザー）
- ノートPC、携帯用USBドライブ/キードライブ、リモートサーバー、クラウド暗号化ストレージなど異種の保存先をGitリモートのように一貫して管理
- 移動中はサーバーにダウンロード待ちキューを積んでおき、接続品質のよい場所で実際の転送を行う遅延転送フローをサポート
- バッテリー節約などのために、USBから瞬時にコピーしてローカルで利用するといったオフラインフレンドリーなワークフローを構成可能
- 利用完了後に保持・削除対象を指定すればローカル容量を回収でき、次回の同期時に変更内容をサーバーと同期する
- special remotesと転送パイプラインを通じて、さまざまなストレージバックエンドやネットワーク状況で柔軟なデータ移動を実現
主要機能と利点
- コンテンツアドレス化とチェックサムに基づく完全性保証と暗号化保存のサポートにより、安全な長期保存を実現
- 位置追跡(location tracking) により、各ファイルの保管場所、コピー数、可用性を明確に把握
- 分散バージョン管理モデルを大容量ファイルに適用し、中央集約型ストレージへの依存を減らしてオフライン耐性を確保
- assistantモードでフォルダー同期の体験を提供し、CLIに不慣れな人でもドラッグ＆ドロップ並みの使い勝手を得られる
利点の要約
- git-annexはファイル参照だけをgitで管理するため、大容量ファイルを負担なく扱うのに適している
- 分散構造により、複数のデバイス・場所で自由なファイル移動、保存、同期・バックアップ、バージョン管理が可能
- オフラインおよび長期保存シナリオ、あるいは複数デバイス・クラウドをまたぐ流動的なデータ管理に特に優れた統合性と拡張性を持つ
- アーカイブ志向と移動志向の混合型ユーザーにも適しており、コピー方針管理とバックエンドの多様化によって組織・個人の双方に有用
- Gitの分散性と移植性を大容量データへ拡張し、長期保管・移行作業の運用リスクと手間を下げるツール
1件のコメント
Hacker Newsのコメント
私は git-annex を使って、あらゆるドライブ上のデータを管理している。各ファイルがどのドライブにあるかを自動追跡し、十分な数のコピーを維持し、すべてのファイルについてチェックサムを確認してくれる。オフラインのドライブでも問題なく動く。git-annex は最初は少し分かりにくく感じるかもしれないので、一時的なリポジトリを1つ作って walkthrough を試しながら実際に触ってみるのがおすすめ。さまざまな workflow も参考になる
どれくらいのデータを保管しているのか気になる。私は約10万〜100万個のファイル、数TBの写真データを ZFS 上で git-annex により管理している。最初は何の問題もなかったが、最近はコマンド1つ1つに5〜30分かかるほど徐々に遅くなっている。これが ZFS のせいなのか、git-annex のせいなのか、あるいはディスクのせいなのか判断がつかない
以前から git-annex でデータ管理することを考えていたが、ファイルを完全に削除する際に手間があり、いくつか問題にも遭遇した。もし時間があれば、どう使っているのか共有してもらえないだろうか
ページには書かれていないが、git-annex は Joey Hess が作った。彼は moreutils、etckeeper も開発している
最近、Git の新しいネイティブな大容量オブジェクト管理機能についての議論が こちら であった
git-annex の残念な点は Haskell であることだ。言語自体が嫌いなわけではないが、インストールしなければならない依存関係の多さには本当に驚いた。そのかなりの部分は他では必要なく、複数のアプリケーションでバージョン衝突も起こしやすい。システムのパッケージマネージャーで入れると特に大変だ。annex と pandoc の2つを入れただけで、毎日のように何十件も Haskell パッケージの更新が流れてくる。もしソースからビルドするディストリビューションを使っているなら悪夢だ。実際、ほとんどは静的リンクしてしまっても問題ないと思う。それなのに Haskell 界隈では、これを細かすぎるライブラリ分割の結果だと言う。だがシステム管理など他の優先事項もあるし、Rust、Go、Zig、C、C++ ではこういう問題に遭遇したことがない。Haskell のエコシステムやユーザーに敵意があるわけではなく、私自身も学ぶつもりではいる。ただ、なぜこの問題が存在するのか、そして解決策は何なのかが気になる
Haskell のツールチェーンでは静的リンクはすでにサポートされている。私は Solus 向けの Haskell スタックを管理しているが、pandoc は libc にしか依存せず、すべての Haskell パッケージをバイナリに静的に束ねて Rust と同じように配布している。つまり十分に可能なことだ。Solus では依存関係が多すぎるので、単純に静的リンクにしている。ディストリビューション保守者の判断の問題だと思う
「ほとんどは静的リンクしても安全だ」という部分については、ディストリビューションの repo である以上、結局はパッケージマネージャーのポリシーの問題なのではないかと思う
フルタイムの Haskell 開発者の立場からしても、静的リンクされていない Haskell パッケージには同じような抵抗感がある。AUR にはすでに静的リンク版があるので、少なくとも不可能ではない。なぜパッケージャーがあえて動的リンクにこだわるのか、私も深くは追っていない。一般に動的リンクは社内ソフトウェア配布には向いていることがあるが、それをディストリビューションにも不必要に持ち込んでいるのだろう
どのパッケージマネージャーを使っているのか気になる。apt ベースのシステムでは Haskell が原因で困ったことはない
pacman -Syuを実行するたびに、更新の半分が Haskell パッケージでうんざりする。たぶん原因は pandoc か shellcheck だgit-annex は本当にクールな技術だ。ただ、私の印象では単一ユーザーのリポジトリで最もうまく機能する。たとえば、1人の人が自分のファイル、文書、音楽などを複数のデバイスをまたいで個人管理する用途には向いている。大容量ファイルを扱う共同リポジトリで同期目的に使ったこともあるが、「magic」ブランチ方式はスケールしなかった
私は self-hosted の forgejo を使っている。今のところ git-annex が LFS より優れている点をまだ見いだせておらず、セットアップも簡単ではなさそうだ。git-annex が Haskell で書かれているのも気に入らないし、おおよそ50%遅いという話も見つけた（ただし出所は1つだけなので、信頼できる情報かはまだ分からない）。コマンドが複雑なのには理由があるのだろうが、LFS のように
.gitattributesを見ればほぼすべて分かるという手軽さがない。git-annex には.gitattributesに相当するような透明性も感じられなかった。それに、git lfs ls-filesに相当するコマンドを示すチュートリアルもないなら、あまり関心は持てないと思う。私はgit statusとgit lfs ls-filesで確認する習慣がある遅いのは Haskell のせいではない。git-annex は分散バックアップツールであり、I/O とデータ保全に非常にこだわった動作をすることが、遅さの原因だ。たとえば drop コマンドでは、その内容がすべての remote に実際に存在するかをリアルタイムで確認しなければならないため遅くなる。
--fastオプションなどでローカルメタデータだけを信頼し、検証過程を省けばかなり速くなる（ただし少し危険だ）LFS と git-annex は微妙に用途が違う。LFS は git リポジトリに大容量ファイルが混在する開発用途、たとえばゲーム開発に向いている。git-annex は重要なデータをバックアップしたいとき、音楽フォルダのような大きなファイル群を複数箇所に保存したいときにより適している。私は後者の形で使っている
git-annex をサポートする Forgejo の soft-fork がある: forgejo-aneksajo
git-annex で管理している最大のリポジトリは、複数のシステムに分散した数TB規模で、10GB超のファイルも多い。投稿者が git-lfs-ls-files のようなものを求めているなら、git-annex では
git annex list --in hereがたぶん近い役割を果たすコマンドラインのドキュメントで実際の活用例が先頭に出てくるのは好感が持てる。多くのツールは、たいてい使いもしない不可解なオプションの説明から始まることが多く、いつも残念に思っていた
GitHub は LFS に Microsoft 流の NIH（Not Invented Here）を適用し、git-annex を採用しなかった
私も git-annex のほうがよりエレガントだと思うが、クロスプラットフォーム互換性は弱い。参考までに、LFS は GitHub と Bitbucket（正確にはどの forge だったか覚えていない）の協業から生まれた。片方が実装を、もう片方が名称を提供し、Git カンファレンスで会って統合された。最近いちばん残念なのは、GitHub の大規模プロジェクトに適用される上限だ。さらに「push するには全オブジェクトをローカルに取得していなければならない」というポリシーのせいで、規模の大きい開発コミュニティはすぐに上限を超えてしまう。参考までに、私は git-lfs に貢献したことがある
（率直に言って）GitHub の NIH アプローチはあらゆる面で不利だ。git-annex を愛して語った発表がある: Staying in Control of your Scientific Data with Git Annex by Yann Büchau
皮肉なことに、私は先週末の1日を使って自前の大容量ファイル用バージョン管理システムを作ってみた。それくらい git-annex が嫌いだ。ファイルを blob に変えてファイルシステムを膨らませてしまう。私の主目的は分散ファイル間の同期であって、バージョン管理そのものには関心がない（そもそも大容量ファイルにどうしてバージョン管理が必要なのか理解できない）。AI と Python を使えば、ファイルをハッシュしてルックアップテーブルを作り、rclone でソースを同期するヘルパーメソッドも作れる。もっとシンプルで効率的な方法はいくらでもある
何年も使ってきたが、最大の利点はクラウドストレージプロバイダーやバックアップとの連携だった。ただ、その連携機能は常に不安定で、メンテナンスされていないサードパーティ製プラグインに依存していた。かつてはデータ不整合バグもあったので、結局使うのをやめた。ここ5年ほどで改善があったのか気になる