「本番が消えたら何が起きるか」を、想像したことありますか？「考えたくない」と思うかもしれませんが、考えておかないと本当に起きたときに半日以上のダウンタイムが発生します。
バックアップ戦略 3原則
- 13-2-1 ルール：3つのコピー、2種類のメディア、1つは別ロケーション
- 2復元テストを月次で実施：「バックアップは取れてた、でもリストアできない」を防ぐ
- 3ジョブ全体を再現可能に：dbtのビルドが冪等なら、データロスからの復元は数時間
のスナップショット運用
日次スナップショットの自動化
SQL
-- 本番テーブルから日次スナップショット作成（7日保持）CREATE OR REPLACE TABLE `dwh.fct_orders_snap_${date}`CLONE `dwh.fct_orders`OPTIONS (expiration_timestamp = TIMESTAMP_ADD(CURRENT_TIMESTAMP(), INTERVAL 7 DAY));Snowflake / Redshift のバックアップ事情
- Snowflake：Time Travel（標準 1 日、最大 90 日まで保持可）。`SELECT * FROM tbl AT (OFFSET => -3600)` で 1 時間前を参照
- Snowflake Fail-safe：Time Travel 後さらに 7 日間データを保持（管理者のみ復元可、Enterprise 以上）
- Redshift：自動スナップショット（保持期間 1〜35 日）、別リージョンへのコピー可。手動スナップショットは無期限保持
- BigQuery Cross-region：マルチリージョンに自動レプリケーション、外部要因で 1 リージョン全滅でも残る
1 時間で復旧する Runbook
- 1T+0min：障害検知。Slack 当番呼び出し（PagerDuty）
- 2T+10min：影響範囲特定。`INFORMATION_SCHEMA` / `query_history` で何が落ちたか
- 3T+20min：スナップショットから新テーブル復元（`CREATE TABLE ... CLONE` 等）
- 4T+40min： build を限定範囲で再実行（モデル分離していれば 20 分で済む）
- 5T+50min： / 下流ジョブの動作確認、整合性チェック
- 6T+60min：完了通知、ポストモーテム作成依頼
「全部消えた」を月次で訓練する
DR 訓練のススメ
月次で「特定テーブルを意図的に消して復元」する訓練を運用に組み込む。本番ではなくステージングで OK。Runbook が古くて使えない事故を防げる。
ふくふくの進め方
「DWH の DR が手付かず」というご相談には、現状調査（1 週間）→ Runbook 作成 → 月次訓練の運用設計を 1〜2 ヶ月で。RTO（復旧目標時間）と RPO（許容データロス）を経営合意ベースで決めるところから入ります。
次回予告
EP.12 は DWH 引っ越し。Redshift から BigQuery、BigQuery から など、ツール変更を 3 ヶ月で完遂する計画術。
この記事の感想を教えてください
あなたの 1 クリックで、本当にこの記事は更新されます。「もっと詳しく」「続編希望」が一定数集まった記事は、 ふくふくが 実際に内容を拡充したり続編記事を公開 します。 送信したリアクションはお使いのブラウザに記録され、再カウントされません。