バックアップ設計の書き方｜RPO・RTOの決め方と世代管理の計算例

バックアップ設計とは、「どのデータを、どの時点まで（RPO）、どれだけの時間で（RTO）戻せるようにするか」を決め、そのための方式・取得間隔・保持世代・保管先・復元手順を表にまとめることです。 取得の設定より先に、戻すときの目標を決めるのが出発点になります。

この記事では、対象データ別のバックアップ設計表を Markdown とタブ区切りのテンプレートで示し、架空の備品予約システムでの記入例を付けます。フル・差分・増分の必要容量と復元時に読む世代数は、変更率を変えて Python で計算した早見表にしました。日次7・週次4・月次12の世代の数え方、3-2-1 の確認表、復元テストの記録テンプレートもそのまま使えます。

確認環境：Ubuntu 24.04、Python 3.11（標準ライブラリのみ）。掲載した数値はすべて記事中のコードで計算した出力です。データ量・変更率・転送速度・作業時間は、計算の手順を示すための例の値です。

バックアップ設計の早見表（決めること8項目）

バックアップ設計表のテンプレート

1行が1つの対象データです。「方式」から書き始めず、左から順に RPO・RTO を先に埋めると、方式と間隔が自然に決まります。

表計算ソフトに貼れるタブ区切り版です。

対象データ   重要度 RPO RTO 方式  取得間隔    保持世代    保管先 復元手順    担当

記入例：社内の備品予約システム

対象データ   重要度 RPO RTO 方式  取得間隔    保持世代    保管先 復元手順    担当
予約データベース（PostgreSQL）    高   15分 4時間 週次フル＋更新ログの連続保管  フル：日曜 2:00／ログ：5分ごと  フル4世代、ログ28日分、月次フル12世代   別サーバーのディスク、遠隔地のオブジェクトストレージ  手順書 BK-01（フルを戻し、ログを指定時刻まで適用）    基盤担当
備品の写真・添付ファイル    中   24時間    8時間 週次フル＋日次増分   フル：日曜 3:00／増分：毎日 3:00   日次7、週次4、月次12    別サーバーのディスク、遠隔地のオブジェクトストレージ  手順書 BK-02（フル→増分を順に展開）   基盤担当
設定ファイル・定義ファイル   高   変更の都度   2時間 リポジトリで版管理   変更のたびに登録    全履歴 リポジトリのサーバー、開発者の手元の複製    手順書 BK-03（該当の版を取り出して配置） 開発担当
アプリケーションのログ 低   24時間    3営業日    日次で圧縮して転送   毎日 1:00 90日分    ログ保管用のストレージ 手順書 BK-04（該当日のファイルを取得）  運用担当
サーバーのイメージ   中   7日  8時間 フル（イメージ取得）  毎週日曜 4:00 と、構成変更の前  4世代 仮想化基盤のバックアップ領域  手順書 BK-05（イメージから起動） 基盤担当
利用者マスタ（社内認証基盤から連携）  中   24時間    8時間 連携元から再取り込み  取得しない（毎晩の連携で再作成できる） なし  連携元 手順書 BK-06（連携ジョブを手動で実行）  運用担当

記入例のポイントは3つあります。

• 作り直せるデータは「取得しない」と明記する。 利用者マスタは連携元から再作成できるので、バックアップの対象から外し、その理由と再作成の手順を書いています。空欄にせず「取得しない」と書くと、検討した結果であることが伝わります。
• RPO が短いデータは、更新ログの保管を組み合わせる。 PostgreSQL の公式ドキュメントは、ベースバックアップと保管した WAL（更新ログ）を組み合わせることで、ベースバックアップ以降の任意の時点の状態に戻せると説明しています（Point-in-Time Recovery）。
• 復元手順の欄には手順書の番号を書く。 手順そのものは別紙にし、設計表からたどれるようにします。

RPO・RTOの決め方

RPO は「入力し直せる量」から決める

RPO は、障害のあとに「どの時点まで戻ってもよいか」です。データの種類ごとに、次の問いで決めます。

取得間隔が RPO を満たすかを計算する

「毎日1回取っているから RPO は24時間」とは限りません。 取得にかかる時間と、保管先へ届くまでの時間も足して確かめます。

# 取得間隔から「最大でどれだけ前に戻るか」を求め、RPO と比べる
def worst_loss_min(interval_min, backup_min=0, copy_delay_min=0):
    """最悪の場合に失うデータの時間幅（分）
    interval_min: 取得間隔 / backup_min: 取得にかかる時間 / copy_delay_min: 保管先へ届くまでの時間"""
    return interval_min + backup_min + copy_delay_min

cases = [
    ("日次フル（毎日1回、取得60分）", 24 * 60, 60, 0),
    ("6時間ごとの増分（取得10分）", 6 * 60, 10, 0),
    ("1時間ごとの増分（取得5分）", 60, 5, 0),
    ("更新ログを5分ごとに保管", 5, 0, 1),
    ("日次フル＋遠隔地へ翌朝コピー", 24 * 60, 60, 8 * 60),
]
print("方式\t最悪の場合に戻る幅\tRPO 24時間\tRPO 1時間\tRPO 15分")
for name, i, b, c in cases:
    w = worst_loss_min(i, b, c)
    label = f"{w/60:.1f}時間" if w >= 60 else f"{w}分"
    print(name, label, *("収まる" if w <= r else "超える" for r in (1440, 60, 15)), sep="\t")

方式  最悪の場合に戻る幅   RPO 24時間    RPO 1時間 RPO 15分
日次フル（毎日1回、取得60分）    25.0時間  超える 超える 超える
6時間ごとの増分（取得10分） 6.2時間   収まる 超える 超える
1時間ごとの増分（取得5分）  1.1時間   収まる 超える 超える
更新ログを5分ごとに保管    6分  収まる 収まる 収まる
日次フル＋遠隔地へ翌朝コピー  33.0時間  超える 超える 超える

日次フルは、取得に60分かかると最悪25時間前の状態に戻るため、RPO 24時間をわずかに超えます。遠隔地へのコピーが翌朝になる構成では、遠隔地の複製から戻す場合に33時間です。RPO は「間隔＋取得時間＋転送の遅れ」と比べます。 RPO を15分にしたいデータは、更新ログを短い間隔で保管する方式が候補になります。

RTO は「復元の作業時間の合計」と比べる

RTO は、止まってから使えるようになるまでの時間です。データを読み戻す時間に加えて、検知・判断・準備・確認の時間も含めて見積もります。

# 復元にかかる時間を見積もり、RTO に収まるかを確かめる
def restore_minutes(data_gb, mb_per_sec, sets=1, per_set_min=5):
    """データの読み戻し時間（分）。sets は読む世代数、per_set_min は世代ごとの準備時間"""
    transfer = data_gb * 1024 / mb_per_sec / 60
    return transfer + sets * per_set_min

FIXED = {"検知": 10, "判断・連絡": 20, "復元先の準備": 30, "動作確認": 30}   # 分（例）
fixed = sum(FIXED.values())
print("固定の作業:", FIXED, "合計", fixed, "分")
print("データ量\t速度\t方式\t読む世代数\t読み戻し\t合計\tRTO4時間")
for gb in (500, 2000):
    for speed in (50, 100, 200):
        for name, sets, extra in (("フル", 1, 0.0), ("フル＋差分", 2, 0.30), ("フル＋増分6回", 7, 0.30)):
            r = restore_minutes(gb * (1 + extra), speed, sets)
            total = fixed + r
            print(f"{gb}GB\t{speed}MB/s\t{name}\t{sets}\t{r:.0f}分\t{total:.0f}分（{total/60:.1f}時間）\t{'収まる' if total <= 240 else '超える'}")

固定の作業: {'検知': 10, '判断・連絡': 20, '復元先の準備': 30, '動作確認': 30} 合計 90 分
データ量    速度  方式  読む世代数   読み戻し    合計  RTO4時間
500GB   50MB/s  フル  1   176分    266分（4.4時間） 超える
500GB   50MB/s  フル＋差分   2   232分    322分（5.4時間） 超える
500GB   50MB/s  フル＋増分6回 7   257分    347分（5.8時間） 超える
500GB   100MB/s フル  1   90分 180分（3.0時間） 収まる
500GB   100MB/s フル＋差分   2   121分    211分（3.5時間） 収まる
500GB   100MB/s フル＋増分6回 7   146分    236分（3.9時間） 収まる
500GB   200MB/s フル  1   48分 138分（2.3時間） 収まる
500GB   200MB/s フル＋差分   2   65分 155分（2.6時間） 収まる
500GB   200MB/s フル＋増分6回 7   90分 180分（3.0時間） 収まる
2000GB  50MB/s  フル  1   688分    778分（13.0時間）    超える
2000GB  50MB/s  フル＋差分   2   897分    987分（16.5時間）    超える
2000GB  50MB/s  フル＋増分6回 7   922分    1012分（16.9時間）   超える
2000GB  100MB/s フル  1   346分    436分（7.3時間） 超える
2000GB  100MB/s フル＋差分   2   454分    544分（9.1時間） 超える
2000GB  100MB/s フル＋増分6回 7   479分    569分（9.5時間） 超える
2000GB  200MB/s フル  1   176分    266分（4.4時間） 超える
2000GB  200MB/s フル＋差分   2   232分    322分（5.4時間） 超える
2000GB  200MB/s フル＋増分6回 7   257分    347分（5.8時間） 超える

500GB のデータは、読み戻しが 50MB/s だと合計が4時間を超え、100MB/s なら収まります。2000GB になると、200MB/s でもすべての方式で4時間を超えます。RTO に収まらないときの選択肢は、(1) 読み戻しを速くする、(2) 読む世代数を減らす（フルの間隔を短くする、差分にする）、(3) 待機系へ切り替える構成にして復元を待たない、の3つです。 見積もりは目安なので、後述の復元テストで実際の時間を測って置き換えます。

フル・差分・増分の容量と復元時の世代数

日曜にフル、月曜〜土曜に差分または増分を取る1週間を、フル1回 500GB、1日の変更率 1%〜20% で計算します。変更は毎日ちがう場所に起きると仮定した、上限側の見積もりです。

# 週次フル＋日次差分／増分の必要容量と、復元時に読む世代数を比べる
# 前提：日曜にフル、月〜土に差分または増分。変更は毎日ちがう場所に起きると仮定（上限側の見積もり）
FULL_GB = 500          # フルバックアップ1回の大きさ
DAYS = 6               # フルの後に取る日数（月〜土）

def week(rate: float):
    diff = [min(1.0, d * rate) * FULL_GB for d in range(1, DAYS + 1)]   # 差分：フル以降の変更すべて
    incr = [min(1.0, rate) * FULL_GB for _ in range(DAYS)]              # 増分：前回以降の変更だけ
    return {
        "毎日フル": (FULL_GB * (DAYS + 1), 1, FULL_GB),
        "週次フル＋日次差分": (FULL_GB + sum(diff), 2, FULL_GB + diff[-1]),
        "週次フル＋日次増分": (FULL_GB + sum(incr), 1 + DAYS, FULL_GB + sum(incr)),
    }

print("変更率/日\t方式\t1週間の容量\t4週間保持\t土曜の復元で読む世代数\t土曜の復元で読む量")
for rate in (0.01, 0.03, 0.05, 0.10, 0.20):
    for name, (gb, sets, read) in week(rate).items():
        print(f"{rate*100:.0f}%\t{name}\t{gb:,.0f}GB\t{gb*4:,.0f}GB\t{sets}\t{read:,.0f}GB")

表から読み取れることは次のとおりです。

• 容量は「毎日フル」が最も大きく、増分が最も小さい。 変更率 5% なら、4週間保持で毎日フル 14,000GB、差分 4,100GB、増分 2,600GB です。
• 差分は、変更率が高いほど増分との差が開く。 変更率 1% では 605GB と 530GB でほぼ同じですが、20% では 2,500GB と 1,100GB です。変更が少ないデータなら、差分を選んでも容量の負担は小さく済みます。
• 復元で読む世代数は、差分が2、増分は最大7。 土曜の状態に戻すとき、差分は「日曜のフル＋土曜の差分」の2つ、増分は「日曜のフル＋月〜土の増分6つ」を順に読みます。増分は途中の1つが読めないと、それ以降に進めません。
• 読む量の合計は差分と増分で同じ。 違いは世代の数、つまり手順の回数です。

方式を選ぶ判断表

世代管理：日次7・週次4・月次12の数え方

世代管理は、複数の時点のバックアップを残しておき、戻す時点を選べるようにする仕組みです。誤った更新や削除は、気づくまでに日数がかかることがあるため、「気づくまでの日数より前」に戻れる世代が必要です。 よく使われる組み合わせが、日次7世代・週次4世代・月次12世代です。

2026-10-05 の時点で、どの日のバックアップが残っているかを数えます。毎日取得し、日曜の分を週次、毎月1日の分を月次として長く残す決まりにしています。

# 日次7・週次4・月次12 の世代保持で、ある日に残っているバックアップを数える
from datetime import date, timedelta

def retained(today: date, daily=7, weekly=4, monthly=12):
    """毎日取得。週次は日曜の分、月次は毎月1日の分を長く残す"""
    keep = {}
    d = today
    for _ in range(daily):                      # 直近 daily 日分
        keep.setdefault(d, []).append("日次")
        d -= timedelta(days=1)
    d = today
    while d.weekday() != 6:                     # 直近の日曜まで戻る
        d -= timedelta(days=1)
    for _ in range(weekly):                     # 日曜の分を weekly 週分
        keep.setdefault(d, []).append("週次")
        d -= timedelta(days=7)
    y, m = today.year, today.month
    for _ in range(monthly):                    # 毎月1日の分を monthly か月分
        keep.setdefault(date(y, m, 1), []).append("月次")
        y, m = (y - 1, 12) if m == 1 else (y, m - 1)
    return dict(sorted(keep.items(), reverse=True))

today = date(2026, 10, 5)
keep = retained(today)
youbi = "月火水木金土日"
for d, kinds in keep.items():
    print(d, youbi[d.weekday()], "・".join(kinds))
print("単純な合計:", 7 + 4 + 12, "世代")
print("重なりを除いた数:", len(keep), "世代")
print("いちばん以前の復元点:", min(keep), f"（{(today - min(keep)).days}日前）")

# 1年間、毎日数えたときの最小・最大
counts = [len(retained(date(2026, 1, 1) + timedelta(days=i))) for i in range(365)]
print("2026年の各日の世代数: 最小", min(counts), "最大", max(counts))

2026-10-05 月 日次
2026-10-04 日 日次・週次
2026-10-03 土 日次
2026-10-02 金 日次
2026-10-01 木 日次・月次
2026-09-30 水 日次
2026-09-29 火 日次
2026-09-27 日 週次
2026-09-20 日 週次
2026-09-13 日 週次
2026-09-01 火 月次
2026-08-01 土 月次
2026-07-01 水 月次
2026-06-01 月 月次
2026-05-01 金 月次
2026-04-01 水 月次
2026-03-01 日 月次
2026-02-01 日 月次
2026-01-01 木 月次
2025-12-01 月 月次
2025-11-01 土 月次
単純な合計: 23 世代
重なりを除いた数: 21 世代
いちばん以前の復元点: 2025-11-01 （338日前）
2026年の各日の世代数: 最小 21 最大 22

7＋4＋12 は23ですが、同じ日が日次と週次、日次と月次を兼ねるので、実際に残るのは21世代です。 2026年の各日について数えると、21〜22世代の間で変わりました。容量を見積もるときは、重なりを除いた数で計算すると過不足が減ります。

保持世代を決めるときの確認項目です。

3-2-1ルールの確認表

3-2-1 は、保管先を決めるときの考え方です。米国の CISA（サイバーセキュリティ・社会基盤安全保障庁）は、重要なファイルの複製を3つ持ち、2種類の異なる記憶媒体に保存し、そのうち1つを事業所から離れた場所に置くと説明しています。

確認項目    基準  自システムの状況    結果
複製は3つあるか    本番のデータを含めて3つ        
媒体は2種類か 同じ機器・同じ方式に偏っていない        
1つは別の場所か    同じ建物・同じ拠点でない        
本番と同じ権限で消せないか   バックアップの削除に別の権限が必要       
遠隔地の複製から戻す手順があるか    手順書があり、試している        
遠隔地の複製の RPO を確かめたか  転送の遅れを足して計算     

復元テストの記録テンプレート

バックアップは、戻せることを確かめて初めて役に立ちます。復元テストは「取得できているか」ではなく「目標の時点に、目標の時間で戻せるか」を確かめる作業で、RTO の見積もりを実際の時間に置き換える機会にもなります。

項目  記録
テスト番号   RT-2026-03
実施日 2026-09-12
対象データ   予約データベース
使ったバックアップ   2026-09-06 のフル＋更新ログ
復元の目標時点 2026-09-11 15:00
復元先 検証用サーバー（本番とは別）
手順書と版   BK-01 第3版
開始時刻・終了時刻   10:00・12:10
かかった時間  2時間10分
目標（RTO）との比較 RTO 4時間以内
復元できた時点 2026-09-11 15:00（RPO 15分以内）
確認した内容  予約の件数が取得時の記録と一致、最新の予約を画面で表示、ログインと新規予約
手順書と違った点    更新ログの保管先のパスが手順書と異なっていた
見直すこと   手順書のパスを修正（担当：基盤担当、期限：2026-09-19）
実施者・確認者 実施：基盤担当A、確認：運用担当B
次回の予定   2026-12

復元テストで確かめる観点です。

バックアップ設計を書く手順

1. 対象データを洗い出す。 データベース、ファイル、設定、ログ、サーバーのイメージに分けて並べます。
2. 作り直せるかどうかで分ける。 作り直せるものは「取得しない」と理由を書きます。
3. RPO と RTO を決める。 利用部門と「どこまで戻ってよいか」「何時間待てるか」を確認します。
4. 方式と取得間隔を決め、RPO を満たすか計算する。
5. 容量を見積もり、保持世代を決める。 重なりを除いた世代数で計算します。
6. 保管先を 3-2-1 の確認表で点検する。
7. 復元手順書を書き、復元テストで時間を測る。 測った時間で RTO の見積もりを置き換えます。
8. データ量が増えたら見直す。 読み戻しの時間はデータ量に比例するため、半年〜1年ごとに再計算します。

よくある質問

Q. RPO と RTO はどちらを先に決めますか？ A. どちらもデータごとに決めますが、RPO が取得間隔と方式を、RTO が復元の方法と構成を決めます。設計表では左から RPO、RTO の順に埋め、その後で方式を選ぶと進めやすくなります。

Q. 差分と増分はどちらを選べばよいですか？ A. 復元の手順を減らしたいなら差分（常に2世代）、容量と取得時間を抑えたいなら増分です。変更率が低いデータでは容量の差が小さいため、差分を選びやすくなります。計算例では、変更率 1% で差分 605GB・増分 530GB、20% で 2,500GB・1,100GB でした。

Q. データベースの複製（レプリケーション）があれば、バックアップは不要ですか？ A. 役割が違うため、両方を用意します。複製は機器の障害からすばやく切り替えるための仕組みで、誤った更新や削除もそのまま複製先に伝わります。過去の時点に戻すには、世代を持つバックアップが必要です。

Q. 世代はいくつ残せばよいですか？ A. 「異常に気づくまでの最長日数」より長く戻れる数にします。日次7・週次4・月次12は、直近は1日単位、1か月前までは1週間単位、1年前までは1か月単位で戻れる組み合わせで、重なりを除くと21〜22世代です。

まとめ

• バックアップ設計は、対象データごとに RPO・RTO を先に決め、方式・取得間隔・保持世代・保管先・復元手順を1行にまとめる。
• RPO は「間隔＋取得時間＋転送の遅れ」と比べる。 日次フルで取得に60分かかると、最悪25時間前に戻る。
• RTO は読み戻しに加えて、検知・判断・準備・確認の時間を合計して比べる。
• 容量は増分が最小、復元の世代数は差分が2で一定。 変更率が低いほど差分と増分の容量差は小さい。
• 日次7・週次4・月次12は、重なりを除くと21〜22世代。 容量は重なりを除いた数で見積もる。
• 保管先は 3-2-1 で点検する。 3つの複製、2種類の媒体、1つは別の場所。
• 復元テストで時間と時点を測り、記録を残す。 測った値で設計表の見積もりを置き換える。

参考・出典

• CISA「Back Up Business Data」 https://www.cisa.gov/audiences/small-and-medium-businesses/secure-your-business/back-up-business-data
• PostgreSQL 16 ドキュメント「Continuous Archiving and Point-in-Time Recovery (PITR)」 https://www.postgresql.org/docs/16/continuous-archiving.html

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。