当たり前ですが、DBMSは、データの消失に備えてバックアップの仕組みがあります。
バックアップ設計について
- 日時、週次等の定期的な間隔で、自動でバックアップが行われるように設定すること。
- データベースから、独立した記憶媒体（磁気記憶装置、テープ装置等）に保存すること。
- 重要なデータの場合は、遠隔地に保管すること。（災害復旧対策：DR)
バックアップの種類
バックアップには、以下の2種類があります。
- オフラインバックアップ
- オンラインバックアップ
それぞれ特徴を見ていきましょう。
オフラインバックアップ
特徴
- ある時点で、保持されているデータを全てバックアップする。
- データーベースを停止してからバックアップを行う。
メリット
データの整合性を保ちつつ、バックアップを行うことができる。
デメリット
アプリを止めないといけなくなります。（システムによっては、影響は大きいでしょう。）
最近は、24時間365日常に稼動することが求めらるシステムが要件上求められることが多いです。この特性があるので、システムによっては、半年や一年に一回しかバックアップを取らないといったこともざらにあるでしょう。
データ量によって、長いと数分で終わるが、多いと数時間かかる。
ハードウェアリソースへの負荷が高い。
バックアップするデータ量が多いので、ディスクI/O、CPU、メモリ使用率が増え、負荷が増します。
オンラインバックアップ
特徴
稼動した状態でバックアップデータを取得することができる。
メリット
アプリを稼動させながら、バックアップを取得できる。
デメリット
便利な反面、一部制約がある。（ＤＢＭＳによって異なります。）
それとは別に行われるバックアップ(ログファイルの出力)
上記の、「オンラインバックアップ」と「オフラインバックアップ」だけでは、まだデータの安全性を保つには不十分な場合があります。
例えば、バックアップの記憶装置が壊れてしまった場合等は、せっかくバックアップを取ったとしても、無駄になってしまいます。
それを防ぐために、別途、データベースは10分か、1時間おきの高頻度で「ログファイル」を出力しています。
データベースのログファイルとはどんなものなの？
データベースの「ログファイル」は、通常のアプリのログとは別物で、「REDOログファイル（トランザクションログ）」等と呼ばれます。
内容としては、「それまでに実行したSQL文全て」になります。
バックアップ方式
これも「論理バックアップ」と「物理バックアップ」の二種類に分かれます。
論理バックアップ
SQLやCSVとしてDBそのものを再構成できるようにバックアップを取ること。
- MySQLの場合は、mysqldump
- PostgreSQLの場合は、pg_dump
論理バックアップの実体はテキストなので中身を閲覧、編集することも可能。
メリット
- DDLをgitなどでバージョン管理することができる。
- 異なるRDBMSやバージョン違いなどにも対応できる。
- 多くの場合オンラインでも使える。
デメリット
- ファイルサイズが大きくなりやすいこと。
- バックアップ、リストアともに時間が長くなりやすいこと。
- バックアップ時点にしか戻せないこと。（バックアップ後に更新されたデータの復旧はできない。）
ユースケース
- サービスの初期でデータサイズが多くない場合などは採用する。
物理バックアップ
データベースの物理ファイルを丸ごとバックアップする手法。
- OSコマンドのcpやrsyncなどを使う。
メリット
- 最小限のサイズで取得でき、バックアップやリストアの時間が短いこと。
- リストアを行うときの復旧も「バックアップファイルを配置して再起動」とシンプルなものが多く運用に優しい。
デメリット
- 論理バックアップのような移植性(バージョンやRDBMSが異なると無理)がない。
- 論理バックアップと同じようにバックアップした時点までしか戻せない。
AWSのRDSのバックアップ
フルマネージドなので運用も簡単。1日1回のフルバックアップと、5分おきの更新情報が含まれたログのバックアップが行われる。PITRを非常に簡単に運用することができる。リストアもWeb UIから簡単に行える。
データの復旧(リカバリ)方法
上記でご紹介させて頂いた「バックアップファイル（オンライン OR オフライン）」と「ログファイル（REDOログファイル）」を使用して、障害が発生する直前までの状態に、下記の手順で復元を行います。これを、専門用語で「ロールフォワード」と呼びます。
1.「バックアップファイル」で日次単位で復元を行う。（リストア）
2.「ログファイル」で、現在付近の時刻まで復元を行う。（ロールフォワード）
重要なのは、めったに発生しない作業ですが、非常に重要な作業でもあるので、手順を必ず明確にしておきましょう。
ポイントインタイムリカバリ（PITR)
特定の日時の状態にデータをリストアできる手法のこと。
具体的に言えば、「2021/10/10 02:43」に障害が発生した場合に、直前の「2021/10/10 02:42」に戻せる。
バックアップファイルと、更新状態の入ったログ（MySQLではバイナリログ、PostgreSQLではアーカイブログ）が必要。
メリット
障害の直前に復旧できる。
デメリット
- バックアップサイズが大きくなる。
- 復旧の手順が複雑になる。
バックアップとレプリケーションの違い
バックアップとレプリケーションは別物です。運用設計時は必ず併用するように設計しましょう。
バックアップ
- 「アプリケーションの不具合」や「ヒューマンエラー（運用者のミス）」によるデータ破損からのデータ復旧ができる。
メリット
特定時点の復旧ができる。
デメリット
復旧に時間がかかる。
レプリケーション
データの複製を他のハードウェアに配置することにより、ハードウェアの障害発生時にアプリケーションの機能提供を実施し、データロストを回避できる。
特徴
- あくまで複製
- アプリケーションの不具合による誤ったデータ更新に対応できない。
- 運用者が誤って「WHERE句をつけ忘れたUPDATE文を発行してしまった」という状況には対応ができない。
メリット
- 片方のハードウェアに異常が発生した場合でも、もう片方に切り替えてすぐに復旧できる。
デメリット
- バックアップのように特定日時に復元することはできない。
スナップショットとバックアップの違い
データが更新されたある瞬間のイメージを取って保存したものです。
データが更新された部分だけを保持するのでスナップショットに必要な容量は元データの1割～2割程度ですみます。
具体的な動作
変更されていないファイルは前のバージョンのファイルをそのまま使い回し、変更されたファイルは新しいバージョンでそのまま保存するという動作になります。
スナップショットのメリット
更新したデータ部分だけを保持するので通常のフルバックアップに比べるとスナップショットの取得速度はかなり早いです。
スナップショットのデメリット
ディスクが破損してしまった場合は復元することができません。
なので定期的にバックアップを取ることも必要になります。
この記事へのコメントはありません。