3 つのバックアップ
論理バックアップ
- SQL や CSV で DB そのものを再構成できるようにする
- 例:
mysqldump -u root -p --host 127.0.0.1 -P 4306 sample > dump.sql
- 例:
- 実体はテキスト
- メリット
- DDL が Git でも管理できる
- 異なる RDBMS やバージョンの違いにも対応できる
- デメリット
- ファイルサイズが大きくなりやすい
- バックアップ・リストアに時間がかかる
- バックアップ時点にしか戻せない
物理バックアップ
- DB の物理ファイルを丸ごとバックアップする
- cp とか rsync とか、専用ツール使ったりする
- メリット
- 最小限のサイズで取得できる？
- バックアップとリストアの時間が短い
- デメリット
- コピーする際は DB を停止させる必要がある？
- 専用ツール使えば避けられる
- バージョン違いに対する互換性はないことが多い
- バックアップ時点にしか戻せない
- コピーする際は DB を停止させる必要がある？
PITR
- 特定の日時の状態にデータをリストアできる手法
- バックアップファイルと更新情報のログが必要
- MySQL ならバイナリ、PostgreSQL ならアーカイブログ
- メリット
- 時間単位でバックアップが可能
- デメリット
- バックアップのサイズが大きくなる
- 論理・物理バックアップに比べて複雑になる
バックアップ方法をまとめる
| 項目/手法 | 論理バックアップ | 物理バックアップ | PITR |
|---|---|---|---|
| バックアップサイズ | 中 | 小 | 大 |
| バックアップ時間 | 中 | 中 | 中~大 |
| リストア時間 | 大 | 小 | 中 |
| 運用コスト | 小 | 中 | 中~大 |
| 復旧時点 | バックアップ開始時点 | バックアップ開始時点 | バックアップ終了直後から最新状態の間の任意の時点 |
バックアップの設計
各バックアップ手法において考慮すべき観点が 3 つあります
RPO(Recovery Point Objective)
【目標復旧時点】
- 障害発生時にいつの時点のデータを復旧するか
- DB の更新頻度によって変わる
- 1 日 1 回しか更新されない DB なら、更新後に物理バックアップを取るだけで十分
- 更新が頻繁にある DB なら、任意の状態に戻すために PITR が適切
RTO(Recovery Time Objective)
【目標復旧時間】
- 障害発生時に目標となる状態へ復旧するまでの時間
- データを多少失っても良く、1 日 1 回の物理バックアップの状態に戻すことが目標なら「物理バックアップから DB が復旧するまでの時間」が RTO となる
- RTO を短くするためにホットスタンバイや冗長化が手法としてあげられる
RLO(Recovery Level Objective)
【目標復旧レベル】
- 障害発生時にどこまで復旧させるか
- 朝の時点まで戻せれば良いとか、直前まで戻さないといけないとか業務によって変わる
- もちろん、理想は直前だが全ての現場でそうである必要はない
稼働率とバックアップ
- RTO(目標復旧時間)と RLO(目標復旧レベル)によって設計が決まる
- 判断基準として稼働率が用いられる
| 稼働率 | 年間停止時間 | 難易度 |
|---|---|---|
| 90% | 36.5 日 | バックアアップとリストア |
| 99% | 3.65 日 | オンプレなら予備ましん必要。大規模データならリストアの所要時間把握が必要 |
| 99.9% | 8.7 時間 | 法定停電への対応、24 時間 365 日サポートなどのシステム外の仕組みづくりが必要 |
| 99.99% | 52 分 | バックアップからのリストアでは難しく、コールドスタンバイが必要 |
| 99.999% | 5 分 | 遅延レプリケーションなどの専用システムが必要 |
| 99.9999% | 32 秒 | 無停止サーバーが必要になり、コストが高くなる |
ちなみに、Amazon RDS / Cloud SQL は 99.95% を保証・提供していて、満たさない場合は返金対応があります
関係ないけど、AWS S3 ではイレブンナインという言葉を使って耐久性を表現することがあります
戦略
- バックアップはなぜ必要？
- (遅延)レプリケーションあるから不要なのでは？ => No!!!
- 理由例： マスター DB に WHERE 句なしの UPDATE 文を実行した場合、レプリケーションも上書きされる
- レブリケーションでは防げない場面でデータを守る
- アプリのバグによるデータ破壊
- 不正なデータ投入
- ヒューマンエラー
- レプリケーションの破壊
アンチパターンにならないために
- バックアップは設定して終わりではない
- バックアップの際のエラー通知
- DB シャーディングなどによって DB サーバーが増えた場合にはテーブル単位でのバックアップもあり得る
- バックアップの運用を見直すタイミング
- DB のサーバーが増えた
- サーバーを入れ替えた
- OS やミドルウェアのバージョンアップ時
- バックアップから復旧したことが一度もない
GitLab ぐらい有名なところでもデータ復旧手段がいくつも機能していなかったことに気付いていなかった
https://www.publickey1.jp/blog/17/gitlabcom56.html
バックアップとリストアの自動化
- 本番から必要なデータをバックアップ
- バックアップからステージングを生成
- ステージングと本番の差分確認
- ステージングで不必要なデータを修正する
Docker でも使って、バックアップからリストアするまでを自動(スクリプト)化することを検討する
リストアの機会を定期的に作る
- 障害を想定してロールプレイング的にリストアをチームで体験する
- 本番と同様のステージング環境を作ってみる
クラウドサービスを利用する
- AWS/GCP/Azure などなど
- PaaS を使えば GUI でぽちぽちして気軽にバックアップとリストアを体験できるし、運用もできる
- PITR を複雑な操作なしに設定できることが最大のメリット(フルマネージド)