- 1. 概要
- 2. 考察
- 3. 実行
- 4. 復元
- 5. 参考サイト
1. 概要
ちょっと古くなって、現時点では、ほとんど使っていないけど、もしかしたら取り出すことがあるかもしれないので、削除するのは躊躇してしまうリポジトリがあります。
これをどうしましょうか？ちゅうお話です。
2. 考察
リポジトリをダンプしておいて、削除する場合、ディスク容量的にどうなんだろうな？
と「Gemini」伍長に相談してみました。
回答は。
FreeBSD 15.1 上の Subversion リポジトリを削除し、ダンプファイル（svnadmin dump で作成したもの）のみを保存しておく運用は、ディスク容量を削減（節約）する観点から非常に効果的で合理的です。
ディスク容量の面におけるメリットや特徴は以下の通りです。
1. ディスク容量的には「大幅に削減できる」
リポジトリそのものを保持する場合と比べて、ダンプファイルのみにする方が容量は小さくなります。
データベースのオーバーヘッドが消える
Subversion のリポジトリの実体（FSFS形式など）は、個別リポジトリごとに膨大な数の小ファイル、インデックス、トランザクション用キャッシュ、フック用のファイル構造などを保持しています。ダンプファイル化することでこれらがすべて削ぎ落とされ、純粋なリビジョンデータとメタデータ（コミットログや属性等）のみの単一ファイルになるため、それだけでサイズが小さくなります。
圧縮率が極めて高くなる
ダンプファイルは単一のプレーンテキスト（またはバイナリ差分データ）として出力されるため、gzip や xz、zstd などの圧縮コマンドと非常に相性が良いです。ダンプしたファイルを圧縮しておけば、元のリポジトリサイズの 数分の一から十数分の一 まで圧縮できるケースも珍しくありません。
2. 容量・運用面のメリットと注意点
メリット
inodes（iノード）の節約
特に UFS や ZFS などのファイルシステムにおいて、大量の小ファイル群（リポジトリ内部のファイル群）を削除して単一のダンプファイル（repository.dump.xz など）にまとめることで、ファイルシステム上の iノード消費を大幅に抑えられます。
バックアップや移行が容易
単一ファイル化されるため、別のストレージへの待避やクラウドバックアップが格段に行いやすくなります。
注意点
即座の閲覧・取り出しはできなくなる
ダンプファイルはあくまで「復元用のデータ」です。過去のコードを1行だけ確認したい場合でも、一度 svnadmin create で一時リポジトリを作成し、svnadmin load で連動させてからアクセスする必要が生じます。
ダンプ作成手順の確認
削除前に正しくダンプが作成されているか（エラー等で途中で途切れていないか）を必ず確認してから元のリポジトリ（/var/svn/repos/... 等）を削除してください。
ちゅうことです。
3. 実行
現行のディスクの状態は。
df -cH
Filesystem Size Used Avail Capacity Mounted on
zroot/ROOT/default 328G 229G 99G 70% /
てな状況です。
リポジトリとして、およそ。
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
ちゅうのがありまして。2017 ～ 2021 はダンプしておいて、問題なさそうです。
「2017」を例としてやってみます。
今回は、「xz」で圧縮します。
「root」ユーザ権限で。
svnadmin --quiet dump /path/to/2017 | xz -9 > /path/to/backup/2017.dump.xz
ls -lh /path/to/backup/2017.dump.xz
rm -rf /path/to/2017
2017 ～ 2021 に適用後、ディスク容量を確認しました。
Filesystem Size Used Avail Capacity Mounted on
zroot/ROOT/default 328G 229G 99G 70% /
わはは、ほとんど変わりませんでした。
まぁ、オーバヘッドが減ることと「inodes」の節約にはなっちょるかな。
4. 復元
ダンプしたものを復元する際は。
「root」ユーザ権限で。
svnadmin create /path/to/2017
xz -dc /path/to/backup/2017.dump.xz | svnadmin --quiet load /path/to/2017
5. 参考サイト
本ページは、「Gemini」伍長を参考にさせていただきました。
|
|
