resticでさくらのクラウド オブジェクトストレージにバックアップ ─ Debian 12編

前回、resticを利用してさくらのクラウドのオブジェクトストレージにバックアップしてみたを書きました。
あのときはAlmaLinuxで試しましたが、うちが見ているサーバはDebianもそれなりの台数があります。同じ手順で行けるのか、Debian 12（bookworm）でも検証してみました。

検証環境は、Debian 12、保存先は同じく石狩第1のオブジェクトストレージ標準プランです。

 さくら側の準備 

 前回と同じです。コントロールパネルの「オブジェクトストレージ」から、サイトの利用開始 → バケット作成 → パーミッション作成でアクセスキー発行、という流れになります。 

resticのインストール

まずaptを見てみます。

apt-cache policy restic

restic:
  Installed: (none)
  Candidate: 0.14.0-1+b5

0.14.0 です。最新は0.19.1なのでだいぶ差があります。実際、この版には以下のオプションがまだありません。

障害対応中に --dry-run が打てないのは痛いので、今回はGitHubのリリースから0.19.1のバイナリを持ってくることにしました。

apt install -y ca-certificates fuse3

RESTIC_VER=0.19.1
cd /tmp
wget https://github.com/restic/restic/releases/download/v${RESTIC_VER}/restic_${RESTIC_VER}_linux_amd64.bz2
wget https://github.com/restic/restic/releases/download/v${RESTIC_VER}/SHA256SUMS
sha256sum -c SHA256SUMS --ignore-missing

bunzip2 restic_${RESTIC_VER}_linux_amd64.bz2
install -m 0755 restic_${RESTIC_VER}_linux_amd64 /usr/local/bin/restic

restic version
restic 0.19.1 compiled with go1.26.4 on linux/amd64

リポジトリの初期化

ここは前回と同じです。環境変数でまとめて設定します。

さくらのS3互換APIには PUT Bucket が含まれていないため、バケットはコントロールパネル側で先に作っておく必要があります。

# /etc/restic/sakura.env
RESTIC_CACHE_DIR=/var/cache/restic
RESTIC_REPOSITORY="s3:https://s3.isk01.sakurastorage.jp/your-bucket-name"
RESTIC_PASSWORD_FILE="/etc/restic/password"
AWS_ACCESS_KEY_ID="＜アクセスキーID＞"
AWS_SECRET_ACCESS_KEY="＜シークレットアクセスキー＞"
AWS_DEFAULT_REGION="jp-north-1"

パスワードファイルの作成と権限設定を行います。
このパスワードを失うと復元不能なので、別の場所にも必ず控えておきましょう。

sudo mkdir -p /etc/restic
openssl rand -base64 32 | sudo tee /etc/restic/password > /dev/null
sudo chmod 600 /etc/restic/password /etc/restic/sakura.env

source /etc/restic/sakura.env
restic init

created restic repository 1f11b490e0 at s3:https://s3.isk01.sakurastorage.jp/your-bucket-name

バックアップとリストア

restic backup /etc --exclude-caches --verbose

Files:       12043 new,     0 changed,     0 unmodified
Added to the repository: 1.842 GiB (743.219 MiB stored)
snapshot 8a1f2c04 saved

2回目以降は差分だけになります。

restic backup /etc --exclude-caches --verbose

Files:          18 new,    42 changed, 11983 unmodified
Added to the repository: 24.118 MiB (9.402 MiB stored)
snapshot c73b9e51 saved

このあたりの傾向はAlmaLinuxのときと変わりませんでした。resticはOSに依存しないので、想定どおりです。

リストアも試します。0.19系なら、実際に書き込む前に --dry-run で何が復元されるか確認できます。

restic snapshots
restic restore latest --target /tmp/restore --dry-run -vv
restic restore latest --target /tmp/restore

restic mount /mnt/restic でスナップショットをマウントできるので、「あのファイルの3日前の状態だけ見たい」というときに便利です。Debianで使う場合は fuse3 を入れておくことと、マウントポイントを先に作っておくことの2点だけ注意してください。ディレクトリが無いと Fatal: mountpoint /mnt/restic does not exist で止まります。

ディストリを跨いだリストアは所有者に注意

resticは所有者を UID/GIDの数値 で復元します。Webサーバの実行ユーザはAlmaLinuxが apache（48）、Debianが www-data（33）なので、AlmaLinuxのスナップショットをDebianに戻すとUID 48のままになり、復旧したのに403という事故につながります。

0.19.0の --ownership-by-name が使えそうに見えたのですが、これは保存されたユーザ名を復元先で引き直すだけで、apache を www-data に読み替えてはくれません。手元で確認した結果がこちらです。

効くのは同じ名前がUID違いで存在する環境への移動で、名前が無いと警告もなくroot所有になります（ドキュメントに記載は見つけられませんでした）。AlmaLinux→Debianは後者なので、素直にリストア後にchownするのが確実でした。

restic restore latest --target /tmp/restore
chown -R www-data:www-data /tmp/restore/var/www

世代管理と定期実行

forget でスナップショットを削除、prune で参照されなくなった実データを削除できます。--prune で一括実行できます。

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

cronやsystemd timerで回すのも前回と同じです。ひとつだけ、/usr/local/bin にバイナリを置いた場合は PATH の解決が環境によって変わるので、スクリプトの中ではフルパスで書くのが安全です。

#!/bin/bash
set -euo pipefail
source /etc/restic/sakura.env

/usr/local/bin/restic backup /etc --exclude-caches --tag daily

# 世代管理と整合性チェックは週1回
if [ "$(date +%u)" -eq 7 ]; then
  /usr/local/bin/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
  /usr/local/bin/restic check --read-data-subset=5%
fi

まとめ

Debian 12でも、resticのS3バックエンドは素直に動きました。前回のAlmaLinux編の手順がほぼそのまま使えます。押さえておくのは以下くらいです。

・aptで入るのは0.14.0で、リストア系のオプションが揃っていない。GitHubから0.19.1を持ってくる
・restic mount を使うなら fuse3 とマウントポイントの事前作成
・自動実行のスクリプトではresticをフルパスで書く