VPS の暗号化バックアップ。
オフサイトに、重複排除して、手の届かない場所へ。

バックアップをめぐる議論のほとんどは、最初の1分で食い違う。話している2人が、それぞれ違う障害を思い浮かべているからだ。一方は故障したドライブを思い描いている。もう一方は、ある火曜日の朝にアカウントが消えている光景を思い描いている。両者には別々の答えが必要であり、前者にしか耐えられない構成は、後者で試されるまでは安全に見え続ける。

対策を設計する価値のある障害モードは4つあり、それらは同じテーマのバリエーションではない — それぞれが異なる防御を打ち破る。

ハードウェア。 NVMe が故障する、ホストノードが落ちる、アレイが同時に2台のメンバーを失う。これは誰もが備えている障害であり、現代の仮想化インフラでは最も稀な部類でもある。冗長ストレージはこれに対処する。冗長ストレージが対処するのはそれだけであり、だからこそ RAID はバックアップではないし、これまでもそうだったことは一度もない。RAID はあらゆる書き込みを忠実に複製する。「すべて削除する」という書き込みも含めて。

人的要因。 本番環境に対して実行された移行スクリプト。間違ったターミナルで叩いた DROP TABLE。引数を逆にした rsync。実際のデータ損失の原因として、これが圧倒的に多い。そして唯一の防御は履歴だ — ミスの前の時点のコピーを、ミスが届かなかった場所に保管しておくこと。鍵となるのは時間だ。唯一のコピーが30秒遅れのミラーでしかないなら、そこにはすでにミスが含まれている。

悪意ある攻撃。 誰かが root 権限を奪うか、パッチの当たっていないアプリケーション経由でランサムウェアが侵入する。現代のランサムウェアがまず行うのは、バックアップの設定 — 認証情報、マウントされた共有、クラウドの鍵 — を探し出し、見つけたものを破壊することだ。動作するリストアが一日の作業で済む復旧を可能にしてしまうからこそ、そこを狙う。削除権限を持つバックアップ用の認証情報は、攻撃者がそのまま受け継ぐ認証情報でもある。このガイドの append-only の章は、まさにこの失敗のために存在する。

カストディアル。 何も壊れておらず、何も攻撃されていない。ただアクセスを失っただけだ。自動不正検知シグナルによるアカウント停止、旅行中のカード決済失敗、異議申し立て、コンプライアンス審査、プロバイダーに対して出された命令。マシンは無傷のまま到達不能になり、そのアカウント内のすべてのスナップショットも道連れに到達不能になる。これは、1つのプロバイダー内でどれだけ冗長性を積んでも答えられない障害であり、まともなバックアップが別の屋根の下に置かれるべき理由でもある。

最後の行こそ、このガイドの残り部分全体で組み立てていくものだ。その上の行より高くつくわけではない — append-only 設定は無料であり、2つ目の法域も1つ目と同じ $3.90 で済む。

3-2-1 ルールを、単一の VPS 向けに言い換える。 データのコピーを3つ、2種類の異なるストレージに、そのうち1つはオフサイトに。この古典的な定式化はテープとオフィスサーバーの時代に生まれたものだが、字面よりも精神のほうがよく生き残っている。セルフホストの1台構成に当てはめると、こうなる — VPS 上の稼働データ、どこか別の場所にある2台目のマシン上のリポジトリ、そして本当に取り返しのつかないものについては、自宅のディスクや引き出しの中など、自分の手元に置ける3つ目のコピー。実際に重要な数字は3ではない。データが失われるまでに、いくつの独立した要因が同時に失敗しなければならないか、その数だ。持つ価値のある最低ラインは2つ。

ファイルシステム全体をバックアップするのは、正当化はできるが無駄の多い選択だ。サーバーの大部分はパッケージマネージャー1つで再現できるものであり、それを1ギガバイト運ぶたびにリポジトリの prune は遅くなり、保持コストは上がり、急いでいるときの検索も遅くなる。有用な作業はその逆だ — 新規インストールでは戻ってこないものだけを洗い出す。

典型的なセルフホスト VPS であれば、そのリストは短く、常に次の5つを含む:

• 01データベースの中身。 データディレクトリではなく、ダンプを。理由はステップ05で扱う。
• 02ユーザーがアップロードしたファイル。 Docker ボリューム、アップロードやメディアのディレクトリ、メールストア。たいていはバイト数の大半を占める部分だ。
• 03設定ファイルと秘密情報。 Compose ファイル、.env ファイル、暗号鍵、API トークン。小さいが、それが2時間で終わるリストアと2日かかるリストアの分かれ目になる。
• 04自分で編集したシステムの状態。 /etc はまるごと持ち出せるほど小さい — sshd の設定、ファイアウォールのルール、systemd ユニット、cron エントリ、丸一晩かけて組んだメールルーティングも含めて。
• 05身元が結び付いたもの全般。 Tor の隠しサービス鍵、Matrix の署名鍵、WireGuard の秘密鍵、ノードのウォレット。これらのどれか1つを失うと、そのサービスは戻ってこない — 同じ名前を持つ別のサービスが戻ってくるだけだ。

このリストを、送信元サーバー上の2つのファイルにする。include リストは意図を見える形にし、exclude リストはノイズを締め出す。どちらもバックアップコマンドが読み込むものであり、どちらもバックアップ自体に含めておくべきだ。

/etc/backup/include.txt

/etc
/opt
/root
/var/backups
/var/lib/docker/volumes
/home

/etc/backup/exclude.txt

# Caches and rebuildable artefacts
**/node_modules
**/.cache
**/*.tmp
/var/lib/docker/volumes/*/_data/cache
# Log noise — keep the config, drop the volume
/var/log/journal
# Never back up the mount point you restore into
/mnt/restore

その Docker の行については、つまずきやすい点が2つある。named volumes は /var/lib/docker/volumes 以下にあり、これこそが欲しいものだ。bind mounts は置いた場所ならどこにでもあり、たいていは Compose ファイルのすぐ隣にあって、/opt でカバーされる。コンテナイメージはデータではない — pull すれば戻ってくるものであり、これを含めたバックアップは不要なギガバイトを運んでいるにすぎない。

最後に、何かを組み立てる前にまず結果を計測する。その数字が、どのリポジトリの容量プランを注文すべきか、そして最初の実行が4分で終わるのか40分かかるのかを教えてくれる:

du -sh --exclude=/var/lib/docker/overlay2 /etc /opt /root /home /var/lib/docker/volumes

リポジトリホストの仕事は1つだけで、必要なものもほとんどない。CPU コアは要らない — データを読むことは一切なく、開けない暗号化された blob を保持するだけだからだ。メモリも要らない — 重複排除の処理は送信元側で行われる。必要なのはディスクと安定したアドレス、そして送信元マシンのトラブルが波及しない場所であることだけだ。

パネルでは Order → VPS → Sentinel、イメージは Debian 12、そして — ここが肝心なのだが — 送信元が動いている拠点とは別の拠点を選ぶ。稼働は Helsinki、保管は Reykjavík。アカウント開設にメールアドレスは不要で、請求は Monero、Bitcoin、Lightning、その他対応する資産のいずれかで決済されるため、2台目のサーバーが、1台目が慎重に避けてきた身元情報を再び持ち込むことはない。

「ワーキングセット」列は、通常程度の変化がある状態で毎日のスナップショットを1年間保持することを前提としている。変化の少ないファイルが中心のリポジトリならもっと長く持つし、大きな再書き込みバイナリばかりなら短くなる。最後の行は規模感のため、そしてまさかの日まで人が忘れがちな点のためにある — オブジェクトストレージはダウンロードにも課金され、緊急時に行うのはまさにそのダウンロードだ。

宛先側では — 権限のないユーザーと1つのディレクトリ。

adduser --disabled-password --gecos "" backup
install -d -m 0700 -o backup -g backup /srv/restic/web01

バックアップ用ユーザーにはパスワードも sudo 権限もなく、ログインする対象すら持たない。存在意義はディレクトリを所有することだけだ。複数のマシンをバックアップする場合は、送信元ごとに専用のディレクトリを与える — 送信元ごとに1つのリポジトリにしておけば、1台が侵害されても他の履歴には影響しない。

送信元側では — 他の何にも使わない鍵。

ssh-keygen -t ed25519 -f /root/.ssh/id_backup -N "" -C "backup:web01"
cat /root/.ssh/id_backup.pub

ログイン用の鍵を使い回さないこと。この鍵は、無人のタイマーが深夜3時に使う必要があるため、ディスク上に暗号化されずに存在する — だからこそ、宛先1つ・用途1つに限定した鍵にしておく必要がある。

話を宛先側に戻す — その鍵にできることを制限する。 公開鍵を /home/backup/.ssh/authorized_keys に、先頭にプレフィックスを付けて貼り付ける。restic を SFTP 経由で使う場合:

restrict,from="198.51.100.7" ssh-ed25519 AAAAC3NzaC1lZDI1... backup:web01

restrict オプションは、ポートフォワーディング、エージェントフォワーディング、X11、PTY 割り当てをひとまとめに無効化し、残るのはファイル転送だけになる。from= 句は鍵を送信元アドレスに固定するため、サーバーから盗まれたコピーは他の場所ではまったく使えない。Borg ではさらに一歩進めて command を強制する。ここに append-only モードが宿っている:

command="borg serve --append-only --restrict-to-path /srv/borg/web01",restrict ssh-ed25519 AAAAC3NzaC1lZDI1... borg:web01

この1行に、ランサムウェア対策のすべてが集約されている。送信元が何を送ってこようと、宛先側は常に borg serve だけを、そのパスの中だけで、追記モードのみで実行する。送信元で root シェルを奪われても、この鍵で先月分を消すことはできない。

宛先の名前は、送信元側で一度だけ設定する。 /root/.ssh/config に書いておけば、以降のコマンドはすべて短く済み、アドレスはただ1つのファイルにのみ存在する:

Host rkv-repo
    HostName 198.51.100.42
    User backup
    IdentityFile /root/.ssh/id_backup
    IdentitiesOnly yes

続いて、一度だけ手動で接続して — ssh rkv-repo — ホスト鍵を承認する。無人で動くタイマーはフィンガープリント確認に答えられず、初回のバックアップが1週間黙って固まったままになるのはよくある話だ。宛先マシンにいる間に、他の所有マシンと同じ扱いをしておく — 最初の1時間のハードニングチェックリストをここでも実行する。すべてのコピーを保持するマシンなのだから、まる1時間をかける価値がある。

データベースに関するルールを、一度だけ述べる。 稼働中のデータベースエンジンは状態をメモリに保持し、自分のタイミングでディスクに書き出す。その最中にファイルを読み取ると、いくつもの異なる時点のページが混在したものが手に入る — 正常にリストアできるかもしれないし、壊れた状態でリストアされるかもしれないし、問題なく開けるのに直近1時間分が黙って欠けているかもしれない。外から見てどれに該当するかを知る方法はない。だからこそバックアップは稼働中のファイルには一切触れない。まずダンプをディスクに書き出し、バックアップはそのダンプを拾い上げる。

すべてを1つのスクリプトにまとめる。/usr/local/sbin/nb-backup.sh に置き、実行可能にし、バックアップ自体にもそれを含めておく:

#!/bin/sh
set -eu

# ---- 1. Consistent dumps, written where the include list will find them.
install -d -m 0700 /var/backups/db

# PostgreSQL in a container:
docker exec -t app-db pg_dumpall -U postgres | gzip -9 > /var/backups/db/postgres.sql.gz

# MariaDB / MySQL, InnoDB tables:
# docker exec -t mail-db mariadb-dump --single-transaction --all-databases \
#   | gzip -9 > /var/backups/db/mariadb.sql.gz

# SQLite — never a plain file copy:
# sqlite3 /opt/app/data/app.db ".backup '/var/backups/db/app.db'"

# ---- 2. The snapshot.
restic backup \
  --files-from /etc/backup/include.txt \
  --exclude-file /etc/backup/exclude.txt \
  --tag nightly --one-file-system

# ---- 3. Retention, then reclaim the space it freed.
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune

# ---- 4. Structural check every night; read 5% of the data on Sundays.
restic check
[ "$(date +%u)" = "7" ] && restic check --read-data-subset=5%

echo "backup ok: $(date -u +%FT%TZ)"

あのスクリプトには、見た目以上に効いている3つの細部がある。冒頭の set -eu は、ダンプが失敗したときに実行を中断させる。これがないと、昨日のダンプを半年間黙ってスナップショットし続けることになる。forget と prune を1つのコマンドにまとめているのは、容量を回収しない保持ポリシーはただ肥大化するディスクにすぎないからだ。そして日曜のチェックはインデックスだけでなく実データの一部を読む — リポジトリの破損は稀で、しかも無音で起きる。それを見つけられるのは実際に読むことだけだ。

タイマー。 2つの小さなユニットファイル。ここで正しいスケジューラは cron ではなく systemd だ。タイマーなら Persistent が使え、マシンが落ちていた間に実行されるはずだった回が黙ってスキップされるのではなく次回起動時に実行される。さらに journalctl があらゆる実行の履歴を保持してくれる。

/etc/systemd/system/nb-backup.service

[Unit]
Description=Nightly encrypted offsite backup
Wants=network-online.target
After=network-online.target docker.service

[Service]
Type=oneshot
EnvironmentFile=/etc/backup/restic.env
ExecStart=/usr/local/sbin/nb-backup.sh
Nice=10
IOSchedulingClass=idle

/etc/systemd/system/nb-backup.timer

[Unit]
Description=Nightly encrypted offsite backup

[Timer]
OnCalendar=*-*-* 03:00:00
RandomizedDelaySec=45m
Persistent=true

[Install]
WantedBy=timers.target

systemctl daemon-reload
systemctl enable --now nb-backup.timer
systemctl list-timers nb-backup.timer
systemctl start nb-backup.service && journalctl -u nb-backup.service -n 40 --no-pager

ランダムな遅延は飾りではない。インターネット上のセルフホストサーバーはこぞって深夜03:00ちょうどにメンテナンスを走らせており、ログローテーション、証明書更新、コンテナ更新とまったく同じ秒にバックアップが始まると、その夜は I/O の奪い合いで消費される。開始時刻を45分の範囲に分散させるのに費用はかからず、原因不明の「重い夜」をまるごと排除できる。

そして、失敗を目立たせる。 これは誰もが省略しがちなステップであり、それまでのすべてが意味を持つかどうかを左右するステップでもある。動かなくなったバックアップは何も知らせてこない — タイマーは律儀に発火し続け、サービスは失敗し続け、ダッシュボードは緑のままで、最後の正常なスナップショットだけがどんどん過去へ遠ざかっていく。実際に目にする形で通知が届くよう、サービスに OnFailure= ユニットを追加し、月に一度スナップショット一覧の先頭をのぞく。1行の設定と、1つの習慣。

restic snapshots --latest 3        # is the newest one from last night?
systemctl list-timers nb-backup.timer   # is the timer still armed?

ここまでの内容はすべて、事故に対する防御だった。この章が防御するのは敵対者であり、その設計上の問題は、一度見えてしまうと居心地が悪い — 送信元のマシンは毎晩リポジトリに到達しなければならず、それは送信元マシンがリポジトリに対する有効な認証情報を保持していることを意味する。送信元を掌握した者が、その認証情報も掌握する。認証情報が削除できるなら、攻撃者も削除できる — そして現代のランサムウェアは、何かを暗号化する前に、まさにこれを意図的に行う。リストア可能な被害者は身代金を払わないからだ。

解決策はより強固なパスワードではない。非対称な権限だ — 送信元はデータを追加できるが、削除はできない。これを実現する方法は3つあり、正しく作りやすい順に並べると次のとおり。

1つ目 — SSH 経由の強制 append-only。 これは Borg の得意分野であり、自分で所有するマシンで使える中では最もすっきりした答えだ。ステップ03 の authorized_keys のエントリが borg serve --append-only を強制するため、送信元が何を要求してこようと宛先側は削除を拒否する。prune はそれでも必要だが、それは宛先側から、送信元が関与できないスケジュールで、送信元が到達できないアカウントによって実行される。送信元で root を奪った攻撃者はリポジトリをゴミで埋め尽くすことはできても、侵入前夜のアーカイブを取り除くことはできない。

2つ目 — append-only な REST エンドポイント。 restic の相棒である rest-server にも --append-only モードがあり、同じ性質を持つ — 新しい blob は受け入れるが、既存のものは削除できない。宛先で TLS の背後に置いて実行し、RESTIC_REPOSITORY を sftp: の URL ではなく https:// の URL に向ければ、防御の形はまったく同じになる。宛先でサービスが1つ増える代わりに、同じ保証が手に入る。

3つ目 — オブジェクトロック。 S3 互換ストレージでは、バージョニングとオブジェクトロックの保持期間を組み合わせることで、期間が満了するまで削除が不可能になる。これはプログラムではなくストレージ層によって強制される。3つの中で最も強力で、最も高価であり、プロバイダーアカウントを新たに持ち込むことになる — それは、このガイド全体が分散させようとしているカストディアルリスクを呼び戻すことでもある。3つ目のコピーとしては理にかなっているが、唯一のコピーとしては据わりが悪い。

そのどれも当てはまらない場合 — 素の SFTP で、書き込めるゆえに削除もできる鍵しかない場合 — それを見て見ぬふりをしないこと。送信元がまったく触れられない、独立した2つ目のコピーを追加する。push ではなく pull にする — 宛先側が送信元にログインし、必要なものを読み取って保存する。こうすれば認証情報は露出していないマシン側に存在することになり、送信元を侵害した攻撃者はバックアップを指し示すものを何も見つけられない。構築の手間は少し増えるが、リスクをまさに正しい方向へ反転させてくれる。

どれを選ぶにせよ、他のセキュリティ対策と同じ方法で検証する — 実際に破ろうとしてみることだ。送信元から、バックアップ用の鍵を使って削除を試みる。正しい結果は「拒否される」ことだ。

borg delete ::name-of-an-old-archive
# → Remote: Repository is in append-only mode. Refusing to delete.

なぜバックアップを別の場所に置くべきなのかと大半の人に尋ねれば、火災、水害、データセンターの停電という答えが返ってくる。どれも事実であり、どれも年々まれになっており、どれも100キロメートルの距離で解決する。しかし2026年に実際に事業を潰しているのは事務的な障害であり、距離だけではそれに対処できない。

1つのアカウントは1つの単一障害点だ。 自動不正検知シグナルによる停止、飛行機に乗っている間のチャージバック、コンプライアンス審査、マシンではなく会社宛てに届く削除要請 — そのどれもが、スナップショットを保持しているサーバーを含め、そのアカウント配下のすべてのサーバーに同時に及ぶ。技術的な冗長性は完璧だったが、無意味だった。2つのプロバイダー、あるいは少なくとも2つの異なる法的主体のもとにある2つのアカウント — これに答えられる構造はそれしかない。

1つの法域は1つの法的枠組みだ。 北欧の4つの拠点は互換ではない — スウェーデン、フィンランド、ノルウェー、アイスランドはそれぞれ少しずつ異なるものを保護しており、ノルウェーとアイスランドは完全に欧州連合の外にある。稼働中のマシンとそのリポジトリをこの2拠点に分けるということは、単に「別の場所」にあるだけでなく、独立した別の法体系の下に置くということだ。北欧の法域リファレンスでは、各法令を1つずつ解説している。

そして宛先側は何も知ることができない。 これがあるからこそ、分散配置はトレードオフではなく単なるコストで済む。restic も Borg も、データが送信元を出る前に暗号化するため、リポジトリホストは鍵を持たない blob を保存しているにすぎない。どのファイルを、いくつ、どんな名前で保持しているのかすら把握できない。第二者に信頼を広げているのではなく、自分自身を読めないディスクを借りているだけだ。「完全には信用していないプロバイダーをバックアップ先に使ってよいのか」という問いへの正直な答えもここにある — 暗号化されたリポジトリでは、信頼はほとんど問題にならない。

遅延は問題にならない。 Helsinki と Reykjavík の間は幹線上で30ミリ秒、Helsinki と Stockholm は8ミリ秒、Stockholm と Oslo は11ミリ秒。毎晩のバックアップはそのどの数字も気にしないし、ディスクの転送速度で頭打ちになるリストアも同様だ。ペアはネットワーク上の距離ではなく、法的な距離で選ぶこと — 北欧域内のネットワーク距離など誤差の範囲でしかない。

もう一つ、はっきり言っておく価値がある。これこそが、このガイドが一般的なシステム管理ブログではなくこのサイトに置かれている理由だ — 2台目のマシンは、1台目が答えたはずのすべての問いを再び開いてしまう。稼働中の VPS を身分証明書なしで注文し、Monero で支払ったとしても、そのバックアップ用のマシンを会社のカードとパスポートのスキャンで注文してしまえば、そのペアは弱い方の半分と同じだけ身元を特定できてしまう。匿名 VPS ホスティングの柱となるガイドでは、サインアップ・支払い・ネットワークという3つの層を扱っており、それらはウェブサーバーと文字通り同じように、バックアップ先にも当てはまる。