データベースにおける論理バックアップ(dump)、物理バックアップとスナップショットの違い

1. 論理バックアップ(dump)

• データベースの論理的な構造を記録し、それをテキストファイルとして保存する方法

• 出力されるファイルはダンプファイルとも呼ばれており、中身はCREATEやINSERTなどのSQLクエリ文が含まれているテキストファイルです。

  DROP TABLE IF EXISTS syain;
  /*!40101 SET @saved_cs_client = @@character_set_client /;
  /!40101 SET character_set_client = utf8 /;
  CREATE TABLE syain (
  id int(11) NOT NULL,
  name varchar(20) NOT NULL,
  romaji varchar(20) DEFAULT NULL,
  PRIMARY KEY (id)
  ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
  /!40101 SET character_set_client = @saved_cs_client /;
  <中略>
  LOCK TABLES syain WRITE;
  /!40000 ALTER TABLE syain DISABLE KEYS /;
  INSERT INTO syain VALUES (1,'suzuki','null'),(2,'tanaka','1'),(3,'kobayashi','2');
  /!40000 ALTER TABLE syain ENABLE KEYS /;
  UNLOCK TABLES;
  /!40103 SET TIME_ZONE=@OLD_TIME_ZONE */;
  <後略>

長所：

• 生成物はテキストファイルのため、grepやsedなどのツールで中身を確認することもできますし、中身を変更することも簡単にできる。
• バックアップサイズを小さく済ませられることが多い。テキスト形式であるため、圧縮効率がよく、圧縮すれば元のサイズの1/20未満で抑えられることも多いです。データ容量を理由に論理バックアップを採用するところも数多くあります。
• database単位やテーブル単位で部分的なバックアップが可能です。
• バックアップされたデータを異なるデータベースシステムにインポートすることが容易です。
  • MySQLではmysqldumpというツールで正しいオプションを指定すれば、生成される論理バックアップファイルをPostgreSQLといった別のデータベースエンジンにインポートすることも可能。
  • dumpファイルの中身については以下の記事をご参考ください。

• 一般的に、物理バックアップに比べて時間がかかる。

短所

• 論理バックアップを生成するにはサーバーで行わなければならないため、サーバーのCPUがさらに消費される。
• 論理バックアップから復元するためには、MySQLがクエリ文を読み込んで解釈し、以下のことをしますから、時間が極めて長くなりがちです。
  • 空のテーブルの作成
  • SQL文(INSERT文)の実行によるレコード作成
  • インデックスの作成

2. 物理バックアップ

• データベースのデータディレクトリにある物理ファイル(データファイルやログファイルなど)を別の場所にコピーするだけです。
• 物理バックアップはrawバックアップと呼ばれる時もあります。
• データベース管理システム（DBMS）固有のツールを使用することが多いです。例：MySQLのPercona XtraBackup、OracleのRMAN、SQL Serverのバックアップ機能

MySQLデータディレクトリにあるファイルとその役割：

長所

• 物理バックアップは高速で効率的です。特に大規模なデータベースでは、全体のバックアップやリストアが迅速に行えます。
• 復元する時にはMySQLサーバーがクエリを実行したり、インデックスの再構築などは必要がないので、復元も論理バックアップより早いです。
  この種類のバックアップは、問題の発生時に早急にリカバリさせる必要がある大規模で重要なデータベースに適しています。
• データベースの状態を保持するために、一貫性のあるスナップショットが取得できます。
  • トランザクションの一貫性を維持するために、データベースを停止させるか、ホットバックアップ機能を使用します。

短所

• InnoDBの物理バックアップは、それに相当する論理バックアップよりもはるかに大きい場合が多い。

InnoDBのテーブル領域には一般的に多くの未使用の領域がある。またデータ以外も挿入バッファやロールバック・セグメントなどかなりの」領域が利用されている。

1. Percona XtraBackupはMySQLにおいてよく使われている物理バックアップツールです。
   フルバックアップや差分バックアップ両方サポートできる。
2. OracleではRmanがよく使われている物理バックアップツールです。

3. スナップショット

スナップショットは、ある瞬間のデータベースの物理的な状態を保存するもので、広い意味では物理バックアップに分類されますが、上記の物理バックアップ取得の仕組みがと異なるため、一般的には別々の方法と認識されます。

定義や分類など

• ストレージ専用機器に，特定時点のデータをイメージとして保存する技術です。クラウドサービスのデータベース（例：AWS RDSやAlibaba CloudのRDS）でよく利用されるデータバックアップ方法
• よく使われいてるツール：Veritas File System, Linux LVM, NetApp NAS
• 大きく分類するとRedirect-On-Write（ROW），Copy-On-Write（COW），Clone/Split Mirror，COW with Background Copy（COW with BC）の4方式が一般的である。それらの違いは以下のページをご参考ください。

• アリババクラウドのRDS スナップショットはRedirect-On-Write（ROW）を使っています。

スナップショットにおけるRedirect-On-Write（ROW）の仕組み

ストレージ上では「ブロックデータ」と「メタデータ」に分けてデータが管理されています。
ブロックデータは実際にユーザーが書き込んだデータですが、メタデータはブロックデータの書き込み位置の情報なので、ブロックデータと比較すると非常に容量は小さいです。
以下ではVolumeを対象としてRedirect-on-Write方式でスナップショットを取得した際のブロックデータおよびそのメタデータの動作を、以下の3つのシーンに分けて解説します。

1. スナップショット取得時
2. データ上書き時
3. リストア時

1. スナップショット取得時

• スナップショットの取得時には、ブロックデータの参照先を示すメタデータのみを保存します。そのためほとんど容量を消費しません。
• 容量とは関係なくて、30秒以内にスナップショットが取得できる。

2. データ上書き時

スナップショットの対象となっているVolumeにデータが上書きされた際には、新たにブロックデータ（赤のブロックデータ）が書き込まれます。同時にVolumeのメタデータも参照するブロックデータが変わることで、変更前のブロックデータはスナップショットのみが参照するデータとなります。そして、この時点でスナップショットのみが指しているブロックデータがスナップショットの容量となり、スナップショットの容量消費が発生します。
　

3. リストア時

• リストア時には、Volumeのメタデータが指し示すブロックデータが、スナップショット取得時のものに戻ります。
• この時Volume更新時に書き込まれたブロックデータ（赤のブロックデータ）は、ほかにスナップショットで紐づくメタデータがなければ削除されます。
• このようにRedirect-on-Writeでは、スナップショットの取得時以降スナップショットとして保存されたメタデータおよびその対象ブロックデータの更新を行いません。そのため、最小限の容量消費と非常に少ない負荷でスナップショットの取得が可能となっています。
• 復元速度: 40分/TB

4. dumpとスナップショットの違い：

スナップショットとダンプは、両方ともデータのバックアップ方法であり、一般的にはデータのコピーを作成することでデータを保護することを目的としていますが、異なる機能があります。

• スナップショットは、データベース内の特定の時点でのデータの論理的状態を保持するために使用されます。スナップショットは通常、データベースからの瞬間的なコピーを作成することによって作成されます。これにより、すべてのトランザクションが完了する前に、特定の時点でのデータベースの状態を反映することができます。

• ダンプは、データベース全体をコピーするために使用されます。データベース全体のスキーマ、テーブル、データなどを含みます。ダンプは、通常、データベースがオフラインである必要があります。これは、データが変更されることを防ぐためであり、データの整合性を維持するためです。

• つまり、スナップショットはデータの状態を保持し、ダンプはデータ全体をコピーします。また、スナップショットは通常オンラインで作成され、ダンプは通常オフラインで作成されます。

5. 物理バックアップとスナップショットの違い

1. スナップショット取得は物理バックアップより高速です。
   • スナップショットバックアップは、データベースの論理状態のみを記録し、データベースファイル全体をコピーする必要がないため、通常、物理バックアップより高速です。
   • 一方、物理バックアップは、データベースファイル全体をコピーする必要があるため、比較的時間がかかります。
2. スナップショット技術はそもそも物理バックアップよりは優れていて、一部のプロダクトは物理バックアップしか対応できない場合がある。
3. スナップショットバックアップはインスタンスのCPUやメモリを消費せず、I/O使用量も物理バックアップに比べてはるかに少ないため、バックアップ処理全体がインスタンスのパフォーマンスに与える影響はほとんどありません。
4. スナップショットバックアップは、物理バックアップと比較して、データベースの復旧時間を大幅に短縮し、RTO（Recovery Time Object）を大幅に短縮し、障害発生時のビジネスへの影響を軽減することができます。

比較項目	dump	物理バックアップ	スナップショット
論理/物理	論理	物理	物理に近い
online/offline取得	online	offline	online
バックアップ単位	tableごと可能	インスタンス単位	インスタンス単位
output	人間が読めるCREATEやINSERTなどのSQLクエリが含まれているテキストファイル	物理ファイル（データファイルやログ・ファイル）
取得速度	一番遅い(必要なテーブルに絞れば早くなる)	高速	最速
復元速度	一番遅い	最速	高速
DBサーバーに対する影響	大きい	小さい	ほとんどありません

• online取得：バックアップ時にデータベースのアクセスを停止する必要がない
• offline取得：バックアップ取得時に、データベースのアクセスを停止する必要がある
• クラウドサービスを利用する場合は、基本的にdumpかスナップショットを利用するのは一般的です。
• PolarDBではdump取得するにもわざわざVM上でdatabaseに接続した上で、mysqldumpなどのコマンドを実行し、dumpファイルをVMにoutputする必要もありません。databaseバックアップ専用のマネージドサービスDBSを使ってdumpかんたんに取得できます。
  

6. alibaba Cloud RDSの物理バックアップとスナップショットについて

• local disk: local SSD
  • 物理バックアップしか利用できない。
• cloud disk: Standard SSDsと enhanced SSDs (ESSDs)二種類がある
  • snapshotバックアップしか利用できない。