背景
ちょこちょこ使ってみると、「こういうときどう動くんだっけ？」「こういうことできるっけ？」という思いが出てきます。
一回整理して、動作検証しておこうと思います。
そもそも Resticを動かすまで
1. サーバサイド（バックアップデータが置かれる方）
ipは192.168.1.128とします。
1.1. 導入するパッケージ
sftpが受けられればいいので、標準設定のsshだけ入ってればOK。
こちら側には、resticのパッケージは入れないので、注意。
1.2. 必要設定
1.2.1. バックアップ処理用のアカウント作成
このアカウントでsftpを受け付けます。
バックアップを置く領域に、この権限で書き込みができるように配慮する必要もあり。
$ sudo useradd -m restic
1.2.2. バックアップ用領域の作成
バックアップが差分保存でどんどん容量膨れ上がるので、大容量を持っている領域はちゃんと設けておく。
/bkupに、大容量領域をマウント済みとします。
$ sudo chown -R restic:restic /bkup
$ sudo chmod -R 700 /bkup
バックアップされるデータは細切れ配置になっていて、生データとして見れるわけじゃないです。
なので、別アカウントでバックアップしたファイルを見れるようにする、、みたいな考慮は不要。
1.2.3. SSH受付設定
手順が前後しますが、クライアント側でもresticアカウントを作って、ssh鍵を作り、こちらの/home/restic/.ssh/authorized_keyに公開鍵を入れておきます。
要塞化でsftpをoffにしている場合は、開けてやる必要があります。
2. クライアントサイド（バックアップ対象のデータを持ってる方）
ipは192.168.1.129とします。
2.1. 導入するパッケージ
sshクライアントは普通に入ってると思いますので、記載しません。
$ sudo apt install restic
パスワード作らなくても運用上問題ないのですが、sshの鍵設定するときはつくっておかないとめんどくさい。
一時的にパスワード振って、設定終わったら無効化かなぁ。
$ sudo passwd restic
$ sudo passwd -l restic
2.2. 必要設定
2.2.1. バックアップ処理用のアカウント作成
このアカウントでsftpを受け付けます。
バックアップを置く領域に、この権限で書き込みができるように配慮する必要もあり。
$ sudo useradd -m restic
$ sudo passwd restic
$ sudo -u restic ssh-keygen
2.2.2. Restic設定
sftpをするときに鍵を使うようにしたいのですが、そのフォローが必要です。
ただし、、バージョンによって取れる方法が違うっぽい。。。
今回手元にあった仮想マシン適当に使ったのですが、、debian13(restic 0.18.0)で使えた方法がdebian12(restic 0.14.0）で使えませんでした。。
-o sftp.args="-o IdentityFile=/home/restic/id_rsa"
chatgpt曰く、ver14前後で色々仕様が変わったとか、、（裏取ってないのでちょっと怪しいですが、、）
さておき、バージョン依存があるとちょっと厄介。
別の方法をご相談すると、、
export RESTIC_SSH_COMMAND="ssh -i /home/restic/.ssh/id_rsa"
環境変数に覚えさせてからresticコマンドを叩くと、鍵を想定通り使ってくれます。
まぁ、バックアップは定期的に行うもので、手でコマンド叩くもんでもないですから、、そこらへんも含めてラッピングしてスクリプト作っちゃいましょうか。
2.2.3. バックアップレポジトリの作成
ちょっと面白いのですが、、クライアント側から、サーバ側に、レポジトリを作ります。
サーバ側でレポジトリ作って、そこに書き込ませる感じではないんですね。
以下、env式で鍵設定を入れているものとします。
$ sudo -u restic -E restic init -r sftp:restic@192.168.1.128:/bkup/bkup01
環境変数使っているので、sudoに-Eをつけるのが必須です。
対話で、パスワードの設定を求められます。
レポジトリ自体のパスワードですね。
将来つどつど使うので、確実に控えておきます。
これを実行すると、サーバ側に、/bkup/bkup01というディレクトリができて、その下にサブディレクトリがあれこれ生成されて準備が整います。
2.2.4. パスワード登録
とりあえず手で都度バックアップ、、、のときはパスワード手で打てばインですけど、安定化して、定期バックアップするようになるとそうも行きません。
...ちょっと気持ち悪いですが、、こんなです。
https://restic.readthedocs.io/en/stable/030_preparing_a_new_repo.html?utm_source=chatgpt.com
ファイルに書いといて、そのファイルの場所を引数で与えるか、環境変数に覚えさせておく、ですね。。
そうなるともうパスワードなしレポジトリでもいい気もしますが、、サーバのデータが単独で取られた場合は安全を担保できる（パスワードはクライアントには平置きされるけど、サーバにはない）から、まぁ、、、いいか。。
こちらは鍵と違って、v0.14でも18でも、引数型は使えるようです。
まぁ、環境変数型に合わせちゃいますかね。
以下、/home/restic/mypassにパスワード書いておくとして。
$ export RESTIC_PASSWORD_FILE=/home/restic/mypass
複数レポジトリと使う場合は、レポジトリごとに環境変数ファイルを作っておいて、こんなふうにしておきます。
そうすると、レポジトリ指定の引数も省略できます。
$ export RESTIC_SSH_COMMAND="ssh -i /home/restic/.ssh/id_rsa"
$ export RESTIC_REPOSITORY=sftp:restic@192.168.1.128:/bkup/bkup01
$ export RESTIC_PASSWORD_FILE=/home/restic/mypass_bkup01
ちなみに、ファイルに書き出すなら、最初から乱数で長くてややこしいパスワードをファイルに吐き出して、それ使ってレポジトリ作っちゃえばいいのでは？という気もしてきます。
。。。ファイルなくしたらアウトだから、ちょっと悩ましいですが。
$ openssl rand -base64 64 | sudo -u restic tee /home/restic/password
$ sudo -u restic chmod 600 /home/restic/password
$ export RESTIC_SSH_COMMAND="ssh -i /home/restic/.ssh/id_rsa"
$ export RESTIC_PASSWORD_FILE=/home/restic/password
$ sudo -u restic -E restic init -r sftp:restic@192.168.1.128:/bkup/bkup01
3. 基本的な操作
3.1. バックアップ
手元の./rawfiles以下のファイル群をバックアップするものとします。
環境変数でssh鍵、レポジトリー、パスワードを全部設定している場合です。
前述の通り鍵指定はバージョンによってできませんが、レポジトリは-r、パスワードファイルは--password-fileで都度指定してもOK。
ただし、、initと違って、.cacheファイルを作成するので、sudo -Eだと、エラーが起こります。
(実行ユーザの./に作ろうとして変なことに）
なので、 -Hも追加です。
また、バックアップ対象の場所の指定も、絶対パスで。
相対にすると同様に、誰にとってパス？でおかしなことになるから。
$ sudo -u restic -E -H restic backup /tmp/rawfiles
ちなみにキャッシュファイルは、chatgpt曰く高速化のために使うもので、なくなったら都度状態確認して重くなるだけなので、消しちゃってもいいし、--no-cacheで作らなくしちゃってもいい、とのこと。
これ消すとどこまでファイル送ったかわからなくなって、多重管理になる、、みたいなややっこしいことになるわけではなさそうです。
3.2. バックアップされているファイルの一覧
まずは、スナップショットの一覧の見方。
ちなみにキャッシュ問題はinit時以外はだいたい常につきまとってくるので、毎回-Hを入れます。
$ sudo -u restic -E -H restic snapshots
ID Time Host Tags Paths Size
---------------------------------------------------------------------------------
5b1cda47 2026-01-07 20:13:19 deb13 /tmp/rawfiles 0 B
5621382d 2026-01-07 20:45:20 deb13 /tmp/rawfiles 800.000 MiB
---------------------------------------------------------------------------------
で、その中身。
最新は、IDではなくlastestで指定してもOK。
-ahみたいなlsのオプションはほとんどないっぽい。。longとrecursiveくらいのようです。
$ sudo -u restic -E -H restic ls latest --long --recursive
repository 21cd5a06 opened (version 2, compression level auto)
created new cache in /home/restic/.cache/restic
[0:00] 100.00% 2 / 2 index files loaded
snapshot 5621382d of [/tmp/rawfiles] at 2026-01-07 20:45:20.234097122 +0900 JST by restic@deb13 filtered by []:
/tmp
/tmp/rawfiles
/tmp/rawfiles/rand_400mb.bin
/tmp/rawfiles/zero_400mb.bin
3.3. 復元
snapshotsで戻したい状態を確認し。
$ sudo -u restic -E -H restic restore 9f3ab19c --target ./
repository 21cd5a06 opened (version 2, compression level auto)
[0:00] 100.00% 9 / 9 index files loaded
restoring snapshot 9f3ab19c of [/tmp2/rawfiles] at 2026-01-07 22:34:15.831308988 +0900 JST by restic@deb13 to ./
Summary: Restored 8 files/dirs (2.344 GiB) in 0:05
$ ls
tmp2
gitのように、指定の領域をまるごとそのバージョンの状態にひっくり返す、という動きではないようです。
--targetで指定したディレクトリの下に、まるごと復元する、と。
--includeで復元するファイルを単独指定することは可能。
また、絶対パスで保存しているからか、復元時も絶対パスでディレクトリを掘られるので、注意。
あるいは、--include /tmp2/rawfileみたいに使って、復元時のディレクトリが変に深くならないようにすることもできるのだそうです。
3.4. スナップショット（あるバージョンのバクアップ)の削除
snapshotsで消したいバージョンを探して、、
$ sudo -u restic -E -H restic forget 9f3ab19c
...
$ sudo -u restic -E -H restic prune
...
resticはファイルを細切れにして保存しますが、スナップショット（あるバージョンのバックアップ）はデータをどう細切りにしたか（細切れ群へのリンク情報）をメタ情報として持ってて、そのメタ情報だけ消すのがforget、、と理解しました。
どのバージョンからも紐づいていない細切れデータを消すのがprune。。
これは後でいろいろ試して振る舞いを見てみることにします。
試しておきたい振る舞いと検証結果
1. ファイルの追加時の振る舞い
1.1. 圧縮
$ cd /tmp/rawfiles
$ dd if=/dev/random of=rand_400mb.bin bs=1M count=400
$ dd if=/dev/zero of=zero_400mb.bin bs=1M count=400
$ ls -alh
total 800M
drwxrwxr-x 2 user01 user01 80 Jan 7 20:45 .
drwxrwxrwt 9 root root 180 Jan 7 20:45 ..
-rw-rw-r-- 1 user01 user01 400M Jan 7 20:45 rand_400mb.bin
-rw-rw-r-- 1 user01 user01 400M Jan 7 20:44 zero_400mb.bin
さて、これをバックアップし、サーバサイドで見てみると、、
$ du -sh ./*
4.0K ./config
402M ./data
24K ./index
8.0K ./keys
4.0K ./locks
12K ./snapshots
$ du -sh ./data/*
17M ./data/00
4.0K ./data/01
4.0K ./data/02
4.0K ./data/03
4.0K ./data/04
4.0K ./data/05
4.0K ./data/06
4.0K ./data/07
4.0K ./data/08
4.0K ./data/09
4.0K ./data/0a
4.0K ./data/0b
4.0K ./data/0c
4.0K ./data/0d
4.0K ./data/0e
4.0K ./data/0f
4.0K ./data/10
4.0K ./data/11
4.0K ./data/12
17M ./data/13
4.0K ./data/14
4.0K ./data/15
4.0K ./data/16
4.0K ./data/17
4.0K ./data/18
...
データの実体は、dataの下に細切れにされて配置されるみたいですね。
400MBファイル２つをアップして400MBちょいしか増えてないってことは、圧縮した状態で保存してるってことですね。
randは縮まらないでしょうけど、zeroの方はかなりしっかりと縮まるはずですから。
圧縮ではなく、後に登場しますが、データのブロック化と再利用がいい感じに機能してる、、と見るほうが正しいのかもです。
2. ファイルの変更
2.1. 同一ファイルをmvしたらどうなるか？
$ tree /tmp/rawfiles
./
├── dir01
├── rand_400mb_2.bin
├── rand_400mb.bin
└── zero_400mb.bin
2 directories, 3 files
user01@deb13:/tmp/rawfiles$ sudo -u restic -E -H restic ls --long --recursive latest
repository 21cd5a06 opened (version 2, compression level auto)
[0:00] 100.00% 3 / 3 index files loaded
snapshot f2e36bf0 of [/tmp/rawfiles] at 2026-01-07 21:20:22.657644826 +0900 JST by restic@deb13 filtered by []:
dtrwxrwxrwx 0 0 0 2026-01-07 20:45:24 /tmp
drwxrwxr-x 1000 1000 0 2026-01-07 21:20:03 /tmp/rawfiles
drwxrwxr-x 1000 1000 0 2026-01-07 21:19:46 /tmp/rawfiles/dir01
-rw-rw-r-- 1000 1000 419430400 2026-01-07 20:45:04 /tmp/rawfiles/rand_400mb.bin
-rw-rw-r-- 1000 1000 419430400 2026-01-07 21:20:04 /tmp/rawfiles/rand_400mb_2.bin
-rw-rw-r-- 1000 1000 419430400 2026-01-07 20:44:50 /tmp/rawfiles/zero_400mb.bin
## サーバ側
$ du -sh ./*
4.0K ./config
802M ./data
40K ./index
8.0K ./keys
4.0K ./locks
16K ./snapshots
で、
$ mv ./rand_400mb_2.bin ./dir01/
$ sudo -u restic -E -H restic backup /tmp/rawfiles/
repository 21cd5a06 opened (version 2, compression level auto)
using parent snapshot f2e36bf0
[0:00] 100.00% 3 / 3 index files loaded
Files: 1 new, 0 changed, 2 unmodified
Dirs: 0 new, 3 changed, 0 unmodified
Added to the repository: 88.365 KiB (19.304 KiB stored)
processed 3 files, 1.172 GiB in
$ sudo -u restic -E -H restic ls --long --recursive latest
repository 21cd5a06 opened (version 2, compression level auto)
[0:00] 100.00% 4 / 4 index files loaded
snapshot 05e8a89d of [/tmp/rawfiles] at 2026-01-07 21:25:22.4221972 +0900 JST by restic@deb13 filtered by []:
dtrwxrwxrwx 0 0 0 2026-01-07 21:20:26 /tmp
drwxrwxr-x 1000 1000 0 2026-01-07 21:23:17 /tmp/rawfiles
drwxrwxr-x 1000 1000 0 2026-01-07 21:23:17 /tmp/rawfiles/dir01
-rw-rw-r-- 1000 1000 419430400 2026-01-07 21:20:04 /tmp/rawfiles/dir01/rand_400mb_2.bin
-rw-rw-r-- 1000 1000 419430400 2026-01-07 20:45:04 /tmp/rawfiles/rand_400mb.bin
-rw-rw-r-- 1000 1000 419430400 2026-01-07 20:44:50 /tmp/rawfiles/zero_400mb.bin
## サーバ側
$ du -sh ./*
4.0K ./config
802M ./data
40K ./index
8.0K ./keys
4.0K ./locks
16K ./snapshots
snapshotしたときの出力からはいまいちよくわからない(Fileはまだなんとなくわかるのですが、dirの3チェンジは、、、、./と./dir01で2ならまだわかるんだけど、、/tmpも入ってるのかな。。ややこしい。。）。
ただし、サーバ側から見ると、ファイルサイズの合計は変わってません。
ということで、同一fileをmvした場合は、内部的に重複保存してデータ圧迫、、みたいなことはなさそうですね。
2.2. md5は一緒だけど、別実体の場合は？
$ md5sum ./dir01/rand_400mb_2.bin
2e278958308e539a8dd3e58659a65c7b ./dir01/rand_400mb_2.bin
$ mv ./dir01/rand_400mb_2.bin ./dir01/rand_400mb_21.bin
$ cp ./dir01/rand_400mb_21.bin ./dir01/rand_400mb_2.bin
$ rm ./dir01/rand_400mb_21.bin
$ md5sum ./dir01/rand_400mb_2.bin
2e278958308e539a8dd3e58659a65c7b ./dir01/rand_400mb_2.bin
$ sudo -u restic -E -H restic backup /tmp/rawfiles/
repository 21cd5a06 opened (version 2, compression level auto)
using parent snapshot 05e8a89d
[0:00] 100.00% 4 / 4 index files loaded
Files: 0 new, 1 changed, 2 unmodified
Dirs: 0 new, 3 changed, 0 unmodified
Added to the repository: 88.359 KiB (19.289 KiB stored)
processed 3 files, 1.172 GiB in 0:01
snapshot 9941bde5 saved
## サーバ側
$ du -sh ./*
4.0K ./config
802M ./data
48K ./index
8.0K ./keys
4.0K ./locks
24K ./snapshots
changed扱いにはなるけど、md5が同一だったら保存済みのデータをそのまま使う、、、のかな。
ならもっとシンプルに、同一md5のファイル2つにするとどうだ？
$ cp ./dir01/rand_400mb_2.bin ./dir01/rand_400mb_3.bin
$ tree ./
.
├── dir01
│ ├── rand_400mb_2.bin
│ └── rand_400mb_3.bin
├── rand_400mb.bin
└── zero_400mb.bin
2 directories, 4 files
$ du -sh ./
1.6G ./
$ sudo -u restic -E -H restic backup /tmp/rawfiles/
repository 21cd5a06 opened (version 2, compression level auto)
using parent snapshot 9941bde5
[0:00] 100.00% 5 / 5 index files loaded
Files: 1 new, 0 changed, 3 unmodified
Dirs: 0 new, 3 changed, 0 unmodified
Added to the repository: 105.935 KiB (19.368 KiB stored)
processed 4 files, 1.562 GiB in 0:02
snapshot 274b48a1 saved
## サーバ側
$ du -sh ./*
4.0K ./config
802M ./data
52K ./index
8.0K ./keys
4.0K ./locks
28K ./snapshots
なるほど。
同一のバイナリは、１つしか保持しない、っていう処理をrestic側でやってくれるんですね。
これはありがたい。
2.3. 同名別ファイル
$ dd if=/dev/random of=./dir01/rand_400mb_2.bin bs=1M count=400
400+0 records in
400+0 records out
419430400 bytes (419 MB, 400 MiB) copied, 0.889954 s, 471 MB/s
$ sudo -u restic -E -H restic backup /tmp/rawfiles/
repository 21cd5a06 opened (version 2, compression level auto)
using parent snapshot 274b48a1
[0:00] 100.00% 6 / 6 index files loaded
Files: 0 new, 1 changed, 3 unmodified
Dirs: 0 new, 3 changed, 0 unmodified
Added to the repository: 400.104 MiB (400.078 MiB stored)
processed 4 files, 1.562 GiB in 0:04
snapshot cea8d739 saved
## サーバ側
$ du -sh ./*
4.0K ./config
1.2G ./data
68K ./index
8.0K ./keys
4.0K ./locks
32K ./snapshots
これは想定どおりですね。
変更前と変更後のデータを両方持つので、データ数量が増えると。
2.4. 同名別ファイル(完全上書き）
ソースコードみたいなものだったら各バージョンの管理が重要になるのですが、各バージョンでの保存は別に重要ではない（過去版を使うことはまずない）というケースがあります。
それが仮想マシンイメージのようにデカかったりすると、つどつど残しているとあっという間にレポジトリがパンクします。
とうことで、意図的に上書きでいないかな。。と。
chatgptにご相談してみましたが、、
結論として、そういう発想はないようです。
過去のレポジトリを消すことはできるとのこと。
別途思考整理してまとめ直します。
2.5. 既存のファイル同士をくっつけたら、、？
chatgptとご相談していると、「ブロックごとに差分があるものだけ保存」みたいな表現が。
細切れにしたバイナリブロック的に同じになる場合は重複排除されたり、、？
以下では、/tmpパンクさせちゃったので、/tmp2にお引越しさせて継続してます。
$ cat ./dir01/rand_400mb_2.bin ./dir01/rand_400mb_3.bin > ./dir01/rand_400mb_merged.bin
$ sudo -u restic -E -H restic backup /tmp2/rawfiles/
/tmp/rawfiles/ does not exist, skipping
repository 21cd5a06 opened (version 2, compression level auto)
no parent snapshot found, will read all files
[0:00] 100.00% 7 / 7 index files loaded
Files: 5 new, 0 changed, 0 unmodified
Dirs: 3 new, 0 changed, 0 unmodified
Added to the repository: 2.572 MiB (2.461 MiB stored)
processed 5 files, 2.344 GiB in 0:05
snapshot 9f3ab19c saved
$ sudo -u restic -E -H restic ls --long --recursive latest
repository 21cd5a06 opened (version 2, compression level auto)
[0:00] 100.00% 8 / 8 index files loaded
snapshot 9f3ab19c of [/tmp2/rawfiles] at 2026-01-07 22:34:15.831308988 +0900 JST by restic@deb13 filtered by []:
drwxr-xr-x 0 0 0 2026-01-07 22:33:36 /tmp2
drwxrwxr-x 1000 1000 0 2026-01-07 21:23:17 /tmp2/rawfiles
drwxrwxr-x 1000 1000 0 2026-01-07 22:32:47 /tmp2/rawfiles/dir01
-rw-rw-r-- 1000 1000 419430400 2026-01-07 21:41:35 /tmp2/rawfiles/dir01/rand_400mb_2.bin
-rw-rw-r-- 1000 1000 419430400 2026-01-07 21:37:21 /tmp2/rawfiles/dir01/rand_400mb_3.bin
-rw-rw-r-- 1000 1000 838860800 2026-01-07 22:33:57 /tmp2/rawfiles/dir01/rand_400mb_merged.bin
-rw-rw-r-- 1000 1000 419430400 2026-01-07 20:45:04 /tmp2/rawfiles/rand_400mb.bin
-rw-rw-r-- 1000 1000 419430400 2026-01-07 20:44:50 /tmp2/rawfiles/zero_400mb.bin
## サーバ側
$ du -sh ./*
4.0K ./config
1.2G ./data
72K ./index
8.0K ./keys
4.0K ./locks
36K ./snapshots
おお！！膨れてない！！
ファイル小分けにするときの切れ目の一次第でガチャガチャになるかなぁ、、と思ってたのですが。
バイナリファイルでも、きれいに増える場合は、うまくやってくれそうですね。
仮想マシンのovfになると、エクスポート時に圧縮とかかかるのかな、、そういうバイナリガチャガチャする処理が間に履いちゃうと逆に駄目なんでしょうから、使い方はちょっと難しいかもですが。
でも非常に興味深い動きです。
しっかり記憶しておこう。
2.6. バイナリずらしてみたら？
ブロック単位で同一の場合は重複管理しない。
ってことは、ブロックの切れ目がずれると別ものに見えて、膨れるってことかな、、？、と。
試してみましょうか。
$ ( tail -c +8 ./dir01/rand_400mb_2.bin ; head -c 7 /dev/urandom; ) | sudo -u restic tee ./dir01/rand_400mb_2_alter.bin 1>/dev/null
$ md5sum ./dir01/rand_400mb_2.bin ./dir01/rand_400mb_2_alter.bin
7492bfbd9f548b827c8d7e53e501f399 ./dir01/rand_400mb_2.bin
4c09c57b22bc7f0ef79d62a6cdc59672 ./dir01/rand_400mb_2_alter.bin
## 3.1.の実行後にスナップショット戻して、、としてるので、本リアの出方と違ってるかも。
$ sudo -u restic -E -H restic backup /tmp2/rawfiles/
repository 21cd5a06 opened (version 2, compression level auto)
using parent snapshot acc3f89d
[0:00] 100.00% 9 / 9 index files loaded
Files: 4 new, 3 changed, 0 unmodified
Dirs: 0 new, 3 changed, 0 unmodified
Added to the repository: 2.294 MiB (2.147 MiB stored)
processed 7 files, 3.125 GiB in 0:06
snapshot fa8b52a5 saved
## サーバ側
$ du -sh ./*
4.0K ./config
1.2G ./data
80K ./index
8.0K ./keys
4.0K ./locks
44K ./snapshots
膨れて、、、ない、、？
chatgpt曰く、「可変長チャンク」という方式を使っており、ストリーム的にデータ読んで、最新Xbyteでハッシュみて、ハッシュの末尾で0がいくつ並んだらカット、という方法を取るんだそうで。
頭がズレても、切れ目入れる条件は一緒だから、どっかで同じ位置でハサミが入り。
それ以降は同じ形でハサミが入る、ってことらしいです。
すげー。なるほど。
3. ファイルの削除
3.1. 素直に削除
これはもう素直に消す意外なんもないですね。
$ rm ./dir01/rand_400mb_2.bin
$ rm ./rand_400mb.bin
$ sudo -u restic -E -H restic backup /tmp2/rawfiles/
repository 21cd5a06 opened (version 2, compression level auto)
using parent snapshot 9f3ab19c
[0:00] 100.00% 8 / 8 index files loaded
Files: 0 new, 0 changed, 3 unmodified
Dirs: 0 new, 3 changed, 0 unmodified
Added to the repository: 107.132 KiB (19.929 KiB stored)
processed 3 files, 1.562 GiB in 0:00
snapshot acc3f89d saved
$ sudo -u restic -E -H restic ls --long --recursive latest
repository 21cd5a06 opened (version 2, compression level auto)
[0:00] 100.00% 9 / 9 index files loaded
snapshot acc3f89d of [/tmp2/rawfiles] at 2026-01-07 22:47:36.562533643 +0900 JST by restic@deb13 filtered by []:
drwxr-xr-x 0 0 0 2026-01-07 22:33:36 /tmp2
drwxrwxr-x 1000 1000 0 2026-01-07 22:47:25 /tmp2/rawfiles
drwxrwxr-x 1000 1000 0 2026-01-07 22:47:20 /tmp2/rawfiles/dir01
-rw-rw-r-- 1000 1000 419430400 2026-01-07 21:37:21 /tmp2/rawfiles/dir01/rand_400mb_3.bin
-rw-rw-r-- 1000 1000 838860800 2026-01-07 22:33:57 /tmp2/rawfiles/dir01/rand_400mb_merged.bin
-rw-rw-r-- 1000 1000 419430400 2026-01-07 20:44:50 /tmp2/rawfiles/zero_400mb.bin
user01@deb13:/tmp2/rawfiles$
## サーバ側
$ du -sh ./*
4.0K ./config
1.2G ./data
76K ./index
8.0K ./keys
4.0K ./locks
40K ./snapshots
想定どおりですね。
差分ファイルで過去のものを保持しているから、別に縮んだりはしない、と。
3.2. 特定ファイルについて、過去の履歴も含めて抹消
chatgpt曰く、そういう概念はresticにはないとのこと。
さいですか。。
4. 特殊な状態のファイルはどうなる？
所有者と権限、シンボリックリンクは見ときたいのですが、、今日は力尽きました。。
5. レポジトリのお掃除
同上＋試験パターンをきちんと考える必要がありそうなのですが、、気力が付きました。
一旦まとめ
思いの外、すごかったです。
バイナリ的な並び方をイメージしながら使う必要がありますが、色々考えながら手をならしていこうと思います。