TT Lab
はじめる
学ぶ 学習パス コース

SIのDB運用

復旧したことのないバックアップ

TT Labで続きを見る

一言でいうと

復旧してみたことのないバックアップは、バックアップではなく、バックアップだと信じているファイルです。バックアップの価値は、復旧によってのみ証明されます。

なぜこれが問題なのか

バックアップが失敗する仕方は、派手ではありません。スクリプトがエラーを出しているのに終了コードを見ないため、毎日0バイトのファイルが溜まっていたり、対象テーブルの一覧が古いため、新しく作ったテーブルだけが抜けていたり、バックアップファイルが元と同じディスクにあるため、ディスクが壊れる日に一緒に消えてしまったり。

これらのどの場合でも、毎日の点検報告は「バックアップ正常」です。そのため、問題はバックアップが必要なまさにその日に、初めて発見されます。

特によく引っかかるのが、データ以外の部分です。シーケンス・権限・トリガーが抜けたバックアップは、復旧してもアプリケーションが起動しません。復旧リハーサルを一度でもやってみれば、これがその日にわかり、やらなければ障害当日にわかります。

バックアップの価値は復旧でしか証明されません

運用点検会議で、「バックアップは毎日正常に動いています」という報告を聞きます。その次の質問は、1つであるべきです。

「最後にそのバックアップから復旧してみたのはいつですか」

答えが「ありません」なら、それはバックアップではなく、バックアップだと信じているファイルです。実際に、こんなことが起きます。

最後の項目が特によくあります。データさえあれば復旧できるわけではありません。

バックアップの3つの軸

軸 質問 指標
何を データだけですか。スキーマ・権限・シーケンスも含みますか バックアップ対象の一覧
どのくらいの頻度で どれだけ失ってもよいですか RPO(復旧時点目標)
どのくらい速く どれだけ止まってもよいですか RTO(復旧時間目標)

RPOとRTOは、技術ではなく業務が決める値です。「1時間分のデータを失ってもよいですか」を、業務担当者に尋ねる必要があります。その答えに応じて、バックアップの周期と方式が決まります。

ほとんどのSIプロジェクトは、この対話をしません。そのため、「バックアップは毎日明け方に回しています」という技術的な事実だけがあり、それが業務の要求を満たしているのかは、誰にもわかりません。

カットオーバーにおけるバックアップ: 時間がそのまま選択肢です

カットオーバー(サービスイン)作業のバックアップは、性格が違います。ロールバック手段として使えなければならないからです。

午前2時に始めて4時までに判断しなければならない作業で、復旧に3時間かかるバックアップは選択肢ではありません。そのため、カットオーバー計画には、必ずこの2行が入っている必要があります。

백업 소요 시간 : 실측 __분
복구 소요 시간 : 실측 __분   ← 이 값이 롤백 판단 시한을 결정한다

このコードブロックの韓国語は、バックアップ所要時間と復旧所要時間を実測の分数で書く欄で、復旧所要時間の値がロールバック判断期限を決める、という意味です。

復旧に時間がかかるなら、別の手段を用意します。

バックアップ対象でよく抜け落ちるもの

データベースだけをバックアップして終わりにすると、復旧できません。

そのため、バックアップ対象の一覧を文書で管理し、新しいオブジェクトが追加されたときに一覧を更新する手続きが必要です。自動バックアップが「スキーマ全体」を対象にしているなら、かなり解決しますが、それさえも確認してみたことがあって初めてわかります。

復旧リハーサルの手順

リハーサルはこのように行います。コツは、本番サーバーではない場所で、バックアップだけを使って行うことです。

1. 백업 파일을 별도 서버/디렉터리로 가져온다 (운영에서 직접 복구하지 않는다)
2. 빈 상태에서 복구를 수행한다 — 시작·종료 시각을 기록
3. 검증
   - 테이블 수, 주요 테이블 행 수
   - 시퀀스 현재값
   - 계정·권한·인덱스·제약
   - 애플리케이션 기동과 로그인 (가능하면)
4. 결과를 문서로 — 소요 시간, 발견된 누락, 조치
5. 발견된 누락을 백업 대상 목록에 반영

このコードブロックの韓国語は、復旧リハーサルの5つの手順を示しています。バックアップファイルを別のサーバーやディレクトリに持ってくる(本番で直接復旧しない)、空の状態で復旧を実施して開始・終了時刻を記録する、検証する(テーブル数と主要テーブルの行数、シーケンスの現在値、アカウント・権限・インデックス・制約、可能ならアプリケーションの起動とログイン)、結果を所要時間・発見された漏れ・措置とともに文書にする、発見された漏れをバックアップ対象の一覧に反映する、です。

項目3の最後の行が、リハーサルの本当の価値です。「復旧はできたのにアプリケーションが起動しない」を、障害当日ではなくリハーサルで発見するのです。

バックアップ検証の自動化

リハーサルを毎回人がやるのは難しいです。最低でも、このくらいは自動化します。

# 매일 백업 직후 자동 검증
1. 백업 파일이 생성됐는가 (존재 + 크기 > 최소 기준)
2. 백업 명령의 종료코드가 0인가        ← 놀랍게도 이걸 안 보는 곳이 많다
3. 파일이 열리는가 (압축이면 무결성 검사)
4. 예상 객체가 포함돼 있는가 (테이블 목록 grep)
5. 주 1회: 실제 복구 후 행 수 비교

このコードブロックの韓国語は、毎日のバックアップ直後の自動検証の5項目を示しています。ファイルが生成されたか(存在とサイズが最小基準以上か)、バックアップコマンドの終了コードが0か(意外にもこれを見ていない所が多い)、ファイルが開けるか(圧縮なら整合性チェック)、想定オブジェクトが含まれているか(テーブル一覧をgrep)、週1回は実際に復旧して行数を比較する、です。

項目2を強調したいです。バックアップスクリプトが失敗しているのにcronがエラーを飲み込んでいると、誰も気づきません。終了コードを確認し、失敗したときはアラートを送る必要があります。「バックアップ失敗の通知が来たことがない」というのは、「バックアップが常に成功している」のではなく、通知そのものがないのかもしれません。

保管と削除

バックアップは無限に溜まります。ポリシーが必要です。

일 백업: 14일 보관
주 백업: 8주 보관
월 백업: 12개월 보관

このコードブロックの韓国語は、日次バックアップは14日間、週次バックアップは8週間、月次バックアップは12か月間保管する、という意味です。

保管数がそのまま、戻れる範囲です。日次バックアップが14個あれば、2週間前に戻れます。「3か月前のデータを復元してください」という依頼が来うる業務なら、その期間だけ保管する必要があります。これも業務と合意する項目です。

そして、削除も自動化しますが、安全装置を置きます。「古いものを削除する」スクリプトのバグで、全部消してしまった事例が実際にあります。日付条件だけで削除し、最小保管数を下限として置き、削除の前に一覧をログに残します。

そして、バックアップは別の場所に置きます

同じサーバー、同じディスクにあるバックアップは、そのサーバーが死ねば一緒に死にます。最低でも別のストレージ、できれば別の物理的な場所にコピーを置きます。

エアギャップ環境なら、外部クラウドが使えないので、社内のバックアップ専用ストレージや、テープ/外付け媒体を使います。そのときは、媒体の持ち出しと持ち込みの手続きと暗号化も一緒についてきます。これも、カットオーバー前に整理しておくべき項目です。

現場での姿

カットオーバー計画を立てるとき、バックアップがそのまま時間の計算になる瞬間があります。復旧に3時間かかるバックアップなら、ロールバックの判断期限は作業終了の3時間前でなければなりません。この計算をしておかないと、午前4時に「今戻すと朝の業務開始に間に合わない」ということを、その場で悟ることになります。

そのため、バックアップ項目に書くべきなのは「バックアップ完了」ではなく、ファイルパスと復旧所要時間です。実際のファイル名をカットオーバー結果報告書に書かせるルールも、同じ理由から生まれました。いざ必要な瞬間に、どのファイルなのかを探すのに時間を使わないためです。