オフサイトバックアップ

データの隣に置いたコピーでは不十分な理由、バックアップ先の選び方、キー権限の制限方法、マシンが完全に利用不能な場合にアクセスできるべきものを説明します。

更新日 2026年8月23日

同じディスク上のコピーが守ってくれるのは、自分で rm -rf をやってしまうミスだけです。OSの再インストール、アクセス権の喪失、ランサムウェア、マシン全体が落ちるような障害から身を守れるのは、別の場所にあるコピーだけです。

どこに保存するか

保存先	メリット	注意点
2台目のVPS	完全に制御でき、転送も速い	同じプロバイダーの2台はリスクを共有している
自宅のPCやNAS	安価で、物理的に離れている	固定アドレスが必要。または自宅側から接続を開始する必要がある
S3オブジェクトストレージ	メンテナンス不要、容量に応じた課金	復元時の下り通信料金を確認する
SFTPアクセス付きの別ストレージ	シンプルで、大容量でも安価	通常、ストレージ側にバージョニングがない

原則はシンプルです。コピーは、元のマシンが完全に失われても残っていなければなりません。1つの出来事で両方のストレージが落ちるなら、それは1か所です。

選択肢は2つあり、ランサムウェアへの耐性が異なります。

マシンがコピーをプッシュする。 シンプルですが、プッシュ用のキーがマシン上にあります。rootを奪った攻撃者はストレージにも到達します。

ストレージが自分でコピーを取得する。 キーは受け取り側にあり、マシンはそれを知りません。より安全ですが、受け取り側がマシンに到達できる必要があります。

両方をカバーする折衷案があります。マシンがプッシュしつつ、受け取り側のキーを書き込み専用に制限し、削除権限を与えない方法です。

command="rrsync -wo /srv/backup/vds",restrict ssh-ed25519 AAAA... vds-backup

Resticでは、同じ役割を append-only モードが担います。追記しかできないリポジトリです。

restic --repo sftp:backup@host:/srv/restic backup /data

この場合、古いスナップショットを削除するのはマシンではなく、受け取り側が独自のスケジュールで行います。

マシン上にあり、コピーを削除する権限を持つキーは、仕組み全体の価値を損ないます。ランサムウェアはまさにそのキーを最初に探します。削除権限は別の誰かに属していなければなりません。

復元が必要になるのは、たいてい最悪のタイミングです。マシンは落ち、慌てていて、時間がありません。事前に次のものを確認しておいてください。

ストレージのアドレスと認証情報 — このマシンの外に書き留めておく。
Resticリポジトリのパスワード — パスワードマネージャーに保管する。
マシンのrootパスワード — 暗号化して保存され、/hosting/vds/m/<id> パネルの「アクセス」タブのボタンで表示されますが、パネルは自分しか利用できません。
何がどこにあるかの一覧 — どのコピーに何が入っているか。

これを短いメモに書き、VPSの外に保管してください。

帯域幅は最大500 Mbpsですが、ボトルネックは通常、受け取り側にあります。最初の完全なコピーは手動で、負荷の少ない時間帯に行ってください。その後は変更分だけが転送されます。サービスに影響が出ないよう速度を制限するには、次のようにします。

rsync --bwlimit=10000 ...
restic backup --limit-upload 10000 ...

値の単位はキロバイト毎秒です。

同じプロバイダーの同じ場所に2つのコピー。 何と呼ぼうと、それは1か所です。
コピーをプッシュしているが、止まったことに誰も気づかない。 Uptime Kuma でプッシュの監視を設定してください。
復元を一度も試していない。 復元訓練を参照してください。
ストレージの認証情報が、コピーにも入ってしまうスクリプトの中にある。 暗号化していれば致命的ではありませんが、スクリプトと一緒にストレージを失うと、そこが穴になります。

コピーに何を入れるべきかの詳細はバックアップするもので、方法はrsyncとResticで解説しています。