「別のサーバーにもコピーしているから、戻せるはず」。

ここ、自分なら一度立ち止まります。間違って消した状態まで次のコピーに反映されたら、保存先を増やしても、そのファイルは戻りません。

さくらのVPSを選ぶなら、本番の外に、削除前へ戻れる世代を残すところまで自分で決める必要があります。とくに見落としやすいのが、取得を細かくしたときの保持期間です。同じ7世代でも、1日おきと4時間おきでは、残っている過去がまるで違いました。

まずは「何時間分の更新ならやり直せるか」と「誤りに気づくまで何日かかりそうか」。この二つを分けると、バックアップの選び方がはっきりします。

標準の復元ボタンを前提にしない

さくらのVPSには、標準・オプションともバックアップ機能がありません。公式FAQは、別サーバーとの同期や、重要データを手元へ保存する対応を案内しています。

さくらのVPS よくある質問を2026-10-23に確認しました。さくらのVPSの機能を確認した資料で、さくらのクラウドやレンタルサーバーの機能とは別です。

一方、公式マニュアルには、利用者がBackupPCを構築するスタートアップスクリプトの案内があります。「バックアップ機能がない」と、この案内は矛盾しません。前者は契約者へ提供される標準機能の話。後者は、自分でバックアップ環境を作るための手段です。

BackupPCの設定例であり、導入や復元を事業者が代行するサービスではありません。BackupPCの注意事項では、設定・運用・復元を利用者が管理すると明示されています。確認日:2026-10-23。

自分なら、契約前の見積もりに保存先だけでなく、取得の失敗を調べる時間と、戻せるか試す時間も入れます。保存容量を確保して終わり、にはしたくないからです。

同期先と、削除前の世代を残す場所を分ける

誤削除に備えるなら、元の削除をそのまま反映する同期先だけでは足りません。変更前の世代を残す必要があります。

違いを確かめるため、CodexがPythonの一時フォルダーにテスト用ファイルを作りました。本番役のフォルダーと同期先を同じ内容にし、別に変更前の世代を一つ保存。その後、本番役のファイルを削除し、同期先を削除後の内容へ置き換えました。

模擬操作 確認結果
元ファイルを削除して、同期先を最新の内容へ置換 同期先にもファイルが残らない
変更しない世代フォルダーから別フォルダーへ復元 ファイルが戻る
復元ファイルのSHA-256を取得前の値と照合 一致した

これは保存の役割を確かめる小さなファイル操作です。さくらのVPSやBackupPCで取得・復元した結果ではありません。削除を反映しない設定の同期や、別途世代を持つ同期なら結果は変わります。

公式のDR対策の構成例にも、別リージョンへ退避し、rsnapshotで過去の状態を残す自主運用例があります。確認日:2026-10-23。公式の構成例を参考にしており、自分のVPSで同じ手順を実行した結果ではありません。

どこへ保存するかは、何から守るかで決める

本番と同じディスクに置いたコピーは、そのディスクを失ったときに一緒に使えなくなります。別VPSに置く場合も、公式BackupPCマニュアルは、本番と保存先のVPSが同一の収容ホストに入る可能性を挙げています。

守りたい場面 保存先で確かめたいこと
誤削除・誤更新 最新状態だけでなく、変更前の世代を取り出せるか
本番ディスクや収容ホストの障害 同じ障害で保存先まで使えなくならないか
拠点の障害 別の地域から保存物へ接続し、復元を始められるか
本番への不正な書き込み 本番側の権限だけで過去の保存物まで消せないか

最後の行は、保存場所だけで決まりません。別の場所に置いていても、本番から過去の世代を削除できる権限があれば、その権限も一緒に失う怖さが残ります。取得する権限と、古い世代を削除する権限をどう持たせるかまで見ます。

同じ7世代でも、4時間おきにすると戻れる過去が短くなる

誤削除から36時間後に気づく例では、日次7世代に正常なコピーが残り、4時間おき7世代には残りませんでした。取得を増やした方が、戻れなくなったんです。

Pythonで取得時刻を並べ、最新の世代だけを残して計算しました。削除を0時間とし、どの計画も最後の正常取得を1時間前に固定。削除後の取得では誤った状態が保存され、36時間後に発見する想定です。取得はすべて成功し、処理時間はかからないものとしました。

取得の計画 保持世代 最古と最新の時刻差 発見時に残る取得時刻(削除からの時間) 削除前に戻せるか
24時間おき 7 144時間 121時間前〜23時間後 戻せる。1時間前の正常版が残る
4時間おき 7 24時間 11時間後〜35時間後 戻せない。残るのは削除後だけ
4時間おき 11 40時間 5時間前〜35時間後 戻せる。1時間前の正常版が残る
1時間おき 49 48時間 12時間前〜36時間後 戻せる。1時間前の正常版が残る

自分が引っかかったのは、「7世代」をなんとなく「1週間分」と読んでしまうところです。4時間おきなら、7世代の最古から最新までの幅は1日。36時間気づかなければ、正常な版が押し出されます。

幅の計算は、等間隔に保存できた場合の (世代数−1)×取得間隔 です。7個の取得点の間は6区間なので、単純に7を掛けません。ただし、この幅がそのまま「何時間前の事故でも戻せる保証」になるわけではありません。

誤削除の直前に取得が終わったか、次の取得の直前に誤削除したかで、必要な正常版の古さは変わります。発見した瞬間に新しい世代が作られ、古い世代が消える場合もあります。表の11世代は固定した例の結果として読み、自分の実行時刻でも削除直前・直後の両方を並べて確かめてください。

保存間隔と容量は説明用の試算です。実際の保存先の圧縮率、転送速度、復旧時間は測っていません。保存と世代指定の復元の前提は公式BackupPCマニュアルを2026-10-23に確認しています。

失敗した夜を含めると、直近まで戻れるとは限らない

予定が4時間おきでも、最後に成功した取得が昨日なら、4時間前へ戻ることはできません。取得の頻度だけでなく、最後に成功した時刻を見る必要があります。

自分なら、日々の確認を「ジョブが起動したか」で止めません。終了結果、保存物の日時と大きさ、残っている最古の正常世代まで見ます。新しい取得に失敗したのに古い世代だけが削除される仕組みなら、保持の計算も崩れるので、実際の削除順序を先に確かめます。

週末は誰も確認しない、異常が見つかってから調査に時間がかかる。そういう時間も、残したい過去に含めます。ぎりぎりの世代数にして容量を使い切るより、検知や調査が延びても過去が残る余裕を取る方を選びます。

DBだけを細かく残すと、必要容量は変わる

ファイル20GBとDBダンプ2GBを毎回全量で保存する仮定では、全体を4時間おきに11世代残すと242GBです。ファイルを日次7世代、DBを4時間おき11世代へ分けると162GBになります。ただし、同じ復元ができるとは限りません。

20GBと2GBは計算用に置いた数字です。GBを同じ単位として掛け算し、圧縮、差分保存、重複排除、管理情報、取得中の一時領域を含めていません。BackupPCやrsnapshotの実際の使用量を予測する表ではありません。

保存する内容と周期 ファイル分 DB分 合計 DBの取得間隔
全体を日次7世代 140GB 14GB 154GB 24時間
全体を4時間おき11世代 220GB 22GB 242GB 4時間
ファイル日次7世代+DB4時間おき11世代 140GB 22GB 162GB 4時間

式は順に、(20+2)×7、(20+2)×11、20×7+2×11。全体を細かく残す案との差は80GBです。

ここで「じゃあ分ければいい!」と決めるのは、ちょっと早い。

たとえば、昼にアップロードした画像への参照が夕方のDBに入り、ファイル側は前夜の保存しかなかったら。夕方のDBだけ戻しても、その画像は出ません。アプリの更新でDBの構造が変わった場合も、古いプログラムと新しいDBをそのまま組み合わせることはできません。

分けやすいのは、ファイルがその間に変わらない、またはDBとファイルの互換性を確かめた組で戻せる用途です。更新のある添付ファイルや設定、アプリの版もDBと一緒に記録する必要があります。整合する組を作れないなら、162GBの案を容量だけで選ばず、アプリが指定する整合性の取れた保存方法へ戻ります。

稼働中のDBのデータディレクトリーを丸ごとコピーして済ませることも避けます。公式BackupPCマニュアルは、そのまま複製してバックアップできないDBなどでは、専用のバックアップ機能でダンプしたものを保存するよう案内しています。確認日:2026-10-23。

戻す練習は、本番へ上書きせず別の環境で

本番で戻せるまでの時間は、別環境への復元を試してから決めてください。ファイルが取り出せることと、サービスが再開することの間には、まだ作業が残ります。

自分なら、保存した世代を一つ選び、まず隔離した検証先に戻します。メール送信や決済、外部への自動処理は動かさず、保存したデータが読めるかから確かめます。これは実行済みのVPS復旧手順ではなく、試験するときの確認順です。

  1. 保存物を取り出す。 本番VPSへ接続できなくても、保存先にログインし、必要な世代を復号・取得できるか確かめる。
  2. 組み合わせをそろえる。 DBダンプ、添付ファイル、アプリの版、設定を同じ復元用の組として並べる。取得時刻が違うものは、互換性を確かめる。
  3. 内容を戻す。 別のDB・ディレクトリーに復元し、件数や重要なレコード、ファイルのハッシュや中身を元の記録と照合する。
  4. 動作を確かめる。 起動、ログイン、添付ファイルの表示、必要な読み書きを確認する。通信先や名前解決、接続許可も復元先へ合わせる。
  5. 完了までを記録する。 取得・復号・復元だけでなく、設定と内容の確認が終わるまでの時間を残す。予定内に収まらなければ、戻す対象や手順を見直す。

公式BackupPCマニュアルも、意図どおり保存できているか、復元できるかの定期確認を勧めています。ファイル復元の案内はありますが、アプリ全体が使えるかは自分の構成で確認する必要があります。

鍵と設定を、本番の中に閉じ込めない

保存物を暗号化していても、復号鍵が消えた本番VPSにしか残っていなければ取り出せません。保存先の認証情報、復号の手段、OSとアプリの構成、起動設定、外部接続の設定を、障害時に使える場所へ別に残します。

秘密情報を誰でも読めるメモに移す話ではありません。必要な人だけが取り出せる保管先に置き、本番へ入れない状態でも復元担当が使えるかを試します。バックアップのコピーはあるのにログインできない……ここで止まりたくないので。

運用を任せたいなら、契約する前に担当を決める

取得の失敗を調べる人も、復元を試す人も置けないなら、自主運用のBackupPCだけを前提にさくらのVPSを選ぶのは勧めません。保存先を契約しただけでは、バックアップの管理まで任せたことにならないからです。

利用者が管理できるなら、まず守りたいデータを挙げ、失ってよい更新時間と、異常の発見にかかる時間を別々に決めます。その条件を満たす世代を本番の外へ残し、整合する組を一度戻す。そこまでできてから、自分の運用として回せるかを判断します。

4時間おきに取るなら、4時間おきに何を何世代残すのかまで。自分なら、取得を増やした安心感より、必要な過去がまだ残っているかを先に見ます。