{"schemaVersion":1,"url":"https://kumyu.com/ja/server-life/sakura-vps-backup-retention","title":"さくらのVPSのバックアップ設計｜取得間隔・保持世代と誤削除からの戻し方","language":"ja","modified":"2026-10-23","description":"公開記事の表と同じ節の説明です。単位・税込/送料・仮定・確認日は列名とcontextを合わせて読んでください。数値は文字列のまま保持しています。","tables":[{"section":"同期先と、削除前の世代を残す場所を分ける","anchor":"section-2","context":"誤削除に備えるなら、元の削除をそのまま反映する同期先だけでは足りません。変更前の世代を残す必要があります。\n\n違いを確かめるため、CodexがPythonの一時フォルダーにテスト用ファイルを作りました。本番役のフォルダーと同期先を同じ内容にし、別に変更前の世代を一つ保存。その後、本番役のファイルを削除し、同期先を削除後の内容へ置き換えました。\n\nこれは保存の役割を確かめる小さなファイル操作です。さくらのVPSやBackupPCで取得・復元した結果ではありません。削除を反映しない設定の同期や、別途世代を持つ同期なら結果は変わります。\n\n公式のDR対策の構成例にも、別リージョンへ退避し、rsnapshotで過去の状態を残す自主運用例があります。確認日：2026-10-23。公式の構成例を参考にしており、自分のVPSで同じ手順を実行した結果ではありません。\n\nどこへ保存するかは、何から守るかで決める\n\n本番と同じディスクに置いたコピーは、そのディスクを失ったときに一緒に使えなくなります。別VPSに置く場合も、公式BackupPCマニュアルは、本番と保存先のVPSが同一の収容ホストに入る可能性を挙げています。\n\n最後の行は、保存場所だけで決まりません。別の場所に置いていても、本番から過去の世代を削除できる権限があれば、その権限も一緒に失う怖さが残ります。取得する権限と、古い世代を削除する権限をどう持たせるかまで見ます。","references":["https://vps.sakura.ad.jp/contents/column/dr-measures/"],"columns":["模擬操作","確認結果"],"rows":[["元ファイルを削除して、同期先を最新の内容へ置換","同期先にもファイルが残らない"],["変更しない世代フォルダーから別フォルダーへ復元","ファイルが戻る"],["復元ファイルのSHA-256を取得前の値と照合","一致した"]]},{"section":"同期先と、削除前の世代を残す場所を分ける","anchor":"section-2","context":"誤削除に備えるなら、元の削除をそのまま反映する同期先だけでは足りません。変更前の世代を残す必要があります。\n\n違いを確かめるため、CodexがPythonの一時フォルダーにテスト用ファイルを作りました。本番役のフォルダーと同期先を同じ内容にし、別に変更前の世代を一つ保存。その後、本番役のファイルを削除し、同期先を削除後の内容へ置き換えました。\n\nこれは保存の役割を確かめる小さなファイル操作です。さくらのVPSやBackupPCで取得・復元した結果ではありません。削除を反映しない設定の同期や、別途世代を持つ同期なら結果は変わります。\n\n公式のDR対策の構成例にも、別リージョンへ退避し、rsnapshotで過去の状態を残す自主運用例があります。確認日：2026-10-23。公式の構成例を参考にしており、自分のVPSで同じ手順を実行した結果ではありません。\n\nどこへ保存するかは、何から守るかで決める\n\n本番と同じディスクに置いたコピーは、そのディスクを失ったときに一緒に使えなくなります。別VPSに置く場合も、公式BackupPCマニュアルは、本番と保存先のVPSが同一の収容ホストに入る可能性を挙げています。\n\n最後の行は、保存場所だけで決まりません。別の場所に置いていても、本番から過去の世代を削除できる権限があれば、その権限も一緒に失う怖さが残ります。取得する権限と、古い世代を削除する権限をどう持たせるかまで見ます。","references":["https://vps.sakura.ad.jp/contents/column/dr-measures/"],"columns":["守りたい場面","保存先で確かめたいこと"],"rows":[["誤削除・誤更新","最新状態だけでなく、変更前の世代を取り出せるか"],["本番ディスクや収容ホストの障害","同じ障害で保存先まで使えなくならないか"],["拠点の障害","別の地域から保存物へ接続し、復元を始められるか"],["本番への不正な書き込み","本番側の権限だけで過去の保存物まで消せないか"]]},{"section":"同じ7世代でも、4時間おきにすると戻れる過去が短くなる","anchor":"section-3","context":"誤削除から36時間後に気づく例では、日次7世代に正常なコピーが残り、4時間おき7世代には残りませんでした。取得を増やした方が、戻れなくなったんです。\n\nPythonで取得時刻を並べ、最新の世代だけを残して計算しました。削除を0時間とし、どの計画も最後の正常取得を1時間前に固定。削除後の取得では誤った状態が保存され、36時間後に発見する想定です。取得はすべて成功し、処理時間はかからないものとしました。\n\n自分が引っかかったのは、「7世代」をなんとなく「1週間分」と読んでしまうところです。4時間おきなら、7世代の最古から最新までの幅は1日。36時間気づかなければ、正常な版が押し出されます。\n\n幅の計算は、等間隔に保存できた場合の （世代数−1）×取得間隔 です。7個の取得点の間は6区間なので、単純に7を掛けません。ただし、この幅がそのまま「何時間前の事故でも戻せる保証」になるわけではありません。\n\n誤削除の直前に取得が終わったか、次の取得の直前に誤削除したかで、必要な正常版の古さは変わります。発見した瞬間に新しい世代が作られ、古い世代が消える場合もあります。表の11世代は固定した例の結果として読み、自分の実行時刻でも削除直前・直後の両方を並べて確かめてください。\n\n保存間隔と容量は説明用の試算です。実際の保存先の圧縮率、転送速度、復旧時間は測っていません。保存と世代指定の復元の前提は公式BackupPCマニュアルを2026-10-23に確認しています。\n\n失敗した夜を含めると、直近まで戻れるとは限らない\n\n予定が4時間おきでも、最後に成功した取得が昨日なら、4時間前へ戻ることはできません。取得の頻度だけでなく、最後に成功した時刻を見る必要があります。\n\n自分なら、日々の確認を「ジョブが起動したか」で止めません。終了結果、保存物の日時と大きさ、残っている最古の正常世代まで見ます。新しい取得に失敗したのに古い世代だけが削除される仕組みなら、保持の計算も崩れるので、実際の削除順序を先に確かめます。\n\n週末は誰も確認しない、異常が見つかってから調査に時間がかかる。そういう時間も、残したい過去に含めます。ぎりぎりの世代数にして容量を使い切るより、検知や調査が延びても過去が残る余裕を取る方を選びます。","references":["https://manual.sakura.ad.jp/vps/startupscript/backuppc.html"],"columns":["取得の計画","保持世代","最古と最新の時刻差","発見時に残る取得時刻（削除からの時間）","削除前に戻せるか"],"rows":[["24時間おき","7","144時間","121時間前〜23時間後","戻せる。1時間前の正常版が残る"],["4時間おき","7","24時間","11時間後〜35時間後","戻せない。残るのは削除後だけ"],["4時間おき","11","40時間","5時間前〜35時間後","戻せる。1時間前の正常版が残る"],["1時間おき","49","48時間","12時間前〜36時間後","戻せる。1時間前の正常版が残る"]]},{"section":"DBだけを細かく残すと、必要容量は変わる","anchor":"section-4","context":"ファイル20GBとDBダンプ2GBを毎回全量で保存する仮定では、全体を4時間おきに11世代残すと242GBです。ファイルを日次7世代、DBを4時間おき11世代へ分けると162GBになります。ただし、同じ復元ができるとは限りません。\n\n20GBと2GBは計算用に置いた数字です。GBを同じ単位として掛け算し、圧縮、差分保存、重複排除、管理情報、取得中の一時領域を含めていません。BackupPCやrsnapshotの実際の使用量を予測する表ではありません。\n\n式は順に、（20＋2）×7、（20＋2）×11、20×7＋2×11。全体を細かく残す案との差は80GBです。\n\nここで「じゃあ分ければいい！」と決めるのは、ちょっと早い。\n\nたとえば、昼にアップロードした画像への参照が夕方のDBに入り、ファイル側は前夜の保存しかなかったら。夕方のDBだけ戻しても、その画像は出ません。アプリの更新でDBの構造が変わった場合も、古いプログラムと新しいDBをそのまま組み合わせることはできません。\n\n分けやすいのは、ファイルがその間に変わらない、またはDBとファイルの互換性を確かめた組で戻せる用途です。更新のある添付ファイルや設定、アプリの版もDBと一緒に記録する必要があります。整合する組を作れないなら、162GBの案を容量だけで選ばず、アプリが指定する整合性の取れた保存方法へ戻ります。\n\n稼働中のDBのデータディレクトリーを丸ごとコピーして済ませることも避けます。公式BackupPCマニュアルは、そのまま複製してバックアップできないDBなどでは、専用のバックアップ機能でダンプしたものを保存するよう案内しています。確認日：2026-10-23。","references":["https://manual.sakura.ad.jp/vps/startupscript/backuppc.html"],"columns":["保存する内容と周期","ファイル分","DB分","合計","DBの取得間隔"],"rows":[["全体を日次7世代","140GB","14GB","154GB","24時間"],["全体を4時間おき11世代","220GB","22GB","242GB","4時間"],["ファイル日次7世代＋DB4時間おき11世代","140GB","22GB","162GB","4時間"]]}],"sources":[{"title":"さくらのVPS BackupPCマニュアル","url":"https://manual.sakura.ad.jp/vps/startupscript/backuppc.html","checkedAt":"2026-10-23T22:24:23+09:00"},{"title":"さくらのVPSで始めるDR対策","url":"https://vps.sakura.ad.jp/contents/column/dr-measures/","checkedAt":"2026-10-23T22:24:23+09:00"}]}