Auroraデータ復活の秘技：バックアップ＆リストアのプロ技を徹底解説

1. データを誤って削除するシナリオ

データベース管理において、以下のようなシナリオでデータを誤って削除してしまうことがありませんか。

1. データベース管理者やインフラエンジニアや運用保守の担当者が誤ったSQLクエリを実行:

   • delete
     • where句を付け忘れたり、WHEREの条件を間違えて指定したり意図しないデータを削除してしまった
   • drop or truncate
     • 不要なtableやdatabaseを削除しようとする時に、間違って別のtableやdatabaseを削除してしまった
   • GUIツールでの不注意な操作
     • GUIのデータベース管理ツールで誤ってレコードの削除ボタンを押してしまった。

2. 自動化スクリプトやアプリケーションのバグにより、意図しないデータ削除

   • バッチ処理や自動化スクリプトにバグがあると、誤ったデータを削除
   • アプリケーションのビジネスロジックに誤りがあると、ユーザーの操作に基づいて不適切なデータを削除

本記事はAWSのバックアップ＆リストアに関する基礎知識から解説した上で、データを誤って削除した時の対応方法をまとめてみたいと思います。

2. AWSのバックアップ＆リストアの基礎知識

2.1 データベースにおけるバックアップとは

データベースバックアップは、データベースのデータや構造をコピーして保存するプロセスです。これは、データの損失や破損が発生した場合に備えて、データを復元(リストア)するために行われます。バックアップは、災害復旧、データの誤削除、システム障害、サイバー攻撃などからデータを保護するための重要な手段です。

2.2 バックアップの対象

バックアップの対象は、データベースに格納されているデータだけでなく、以下のような要素を含むことがあります。

• データベースのデータ: テーブルやレコードのデータ
• データベースの構造(スキーマ情報): テーブル定義やインデックス
• ユーザーと権限: データベースのユーザーアカウントとその権限設定(system databaseで持っている情報)
• トランザクションログ: データベースの変更履歴を記録するログ

2.3 バックアップの目的

データベースバックアップの主な目的:

• データの復元: データの誤削除や破損が発生した場合に、データを以前の状態に戻す(リスト/リカバリー)ことができる。
• ビジネス継続性の確保: システム障害や災害が発生しても、業務を継続できるようにする。
• 法令遵守: 一部の業界では、データのバックアップと保存が法的に義務付けられている場合があります。

2.4 バックアップの種類

データベースバックアップにはいくつかの種類があります。

• フルバックアップ: データベース全体をコピーします。最も安全ですが、時間とストレージを多く消費します。
• 差分バックアップ: 直前のフルバックアップ以降に変更されたデータのみをコピーします。より効率的ですが、フルバックアップと組み合わせて使用されます。
• 増分バックアップ: 直前のバックアップ以降に変更されたデータのみをコピーします。ストレージ効率は高いですが、復元手順が複雑です。

2.5 AWS Auroraのバックアップ

AWS Auroraでは、以下の2種類のバックアップが提供されています。

2.5.1 自動バックアップ

1. 特徴:

   • クラスターボリューム全体を対象に、指定された保持期間内でのすべてのデータベース変更を増分的にバックアップします。これにより、バックアップ保持期間内の任意の時点にデータを復元することが可能です
   • 保持期間：
     • 1日〜35日
     • 0日に指定できません(つまり自動バックアップが無効化できません)
   • 35日以上保存したい場合は、以下の手動バックアップでスナップショットを取得するしておく必要があります
   • 頻度：1日1回(1日に複数回のバックアップを実行することはできません)

2. 構成
   Amazon Auroraの自動バックアップは、データのバックアップとトランザクションログ(redo log)のバックアップの両方を含み、連続的かつ増分的にデータをバックアップする仕組みを提供しています。

   • データのバックアップ:
     

     • ユーザーが指定したバックアップウィンドウのStart Timeになると、バックアップは自動的に開始
     • 増分バックアップ:
       • 前回(昨日)の自動バックアップからのすべてのデータベースの変更分のみを対象
       • バックアップにかかる時間は、変更されたデータの量に影響されます。変更が少ない場合はバックアップが迅速に完了し、変更が多い場合はより多くの時間がかかる可能性があります。
     • バックアップがこのウィンドウ内に完了しない場合でも、バックアッププロセスは完了するまで続行されます。バックアップウィンドウが終了しても、バックアップが中断されることはありません
     • バックアップウィンドウ内でのみバックアップが開始されるため、ウィンドウ外での変更は次回のバックアップウィンドウまで待つことになります。

   • トランザクションログ(redo log)のバックアップ:

     • トランザクションログ（redo log）は、バックアップウィンドウと関係なく、5分ごとにS3にバックアップされます。
     • バックアップウィンドウ外の時間帯でもトランザクションログは継続的バックアップされる。これにより、データベースの変更があるたびにその差分が保存され、バックアップ保持期間内であれば任意の時点に迅速に復元することが可能
       

3. 課金方法：

自動バックアップにおけるbackup windowと別として、メンテナンスウィンドウの概念があります。

1. 目的
   Amazon RDSのメンテナンスウィンドウは、システムの変更やアップデートが適用されるための週単位の時間枠です。各DBインスタンスには、ユーザーが指定するか、デフォルトで割り当てられるメンテナンスウィンドウがあります。このウィンドウは、以下のような目的で利用されます。
   • システム変更の適用:
     • データベースエンジンの自動的なminorバージョンアップ
     • OSのパッチ適用
     • 基盤となるハードウェアの更新など
   • インスタンスへの変更の適用タイミングを管理:
     • ユーザーはメンテナンスウィンドウを利用して、インスタンス変更の適用タイミングをコントロールすることができます。これにより、業務への影響を最小限に抑えることが可能です
2. 特徴

• 時間枠の設定:
  メンテナンスウィンドウはデフォルトで30分間の時間枠があり、ユーザーが指定しない場合は、AWSがランダムに選んだ時間帯に割り当てられます。
  メンテナンスのstart timeとDurationはユーザーが自由に変更することも可能
  
• パフォーマンスへの影響:
  • メンテナンス中はDBインスタンスのリソースの一部が使用されるため、わずかにパフォーマンスに影響が出る可能性があります。
  • マルチAZ配置の場合、メンテナンスやシステムアップグレードの際に、プライマリインスタンスが一時的に停止する必要がある場合、フェイルオーバーによってスタンバイインスタンスに切り替えることで、サービスの中断を防ぎます。
• メンテナンスの延期:
  • 一部のメンテナンスはユーザーが延期することが可能
  • セキュリティや信頼性に関する必須のパッチは自動的に適用
• Auroraの自動バックアップは、ユーザーが指定したバックアップウィンドウ内に行われます。バックアップウィンドウはメンテナンスウィンドウと重なってはいけません
  

2.5.2 手動バックアップ

1. 特徴

   • フルバックアップ：ユーザーが手動で作成するバックアップで、クラスターボリュームの特定の時点の全体のコピー完全にを保存します。したがって、スナップショットを作成すると、その時点でのデータベースの全体のサイズがスナップショットとして保存
   • ストレージの増加: 例えば、元のデータが100GBの場合、スナップショットを作成すると、そのスナップショット自体が100GBのストレージを使用
   • スナップショットの作成時間は、クラスターボリュームのサイズに依存します。したがって、データ量が多いほどスナップショットの作成に時間がかかります。
   • スナップショットは期限がなく、ユーザーが明示的に削除するまで保持されます
   • 手動スナップショットは、次の条件のいずれかが当てはまるスナップショットです
     • ユーザーによって手動でリクエストされた
     • AWS Backup などの自動バックアップサービスによって撮られた
     • 保持期間外に保存するために自動システムスナップショットからコピーされた

   snapshotという言葉は手動スナップショット(手動で作られたもの)を指すことが多いですが、文脈によって自動バックアップで作られたものも含められる場合があります。そもそもwebコンソール画面でも両方ともsnapshotと読んでいます。

   • 手動スナップショット：
     
   • 自動スナップショット：
     
     :

2. 課金方法
   自動バックアップの保持期間外の（より古い）手動スナップショットに対して請求されます。

	Aurora自動バックアップ	Aurora手動バックアップ(snapshot)
種類	増分バックアップ	フルバックアップ
保持期間	1～35日(default: 1日)	無期限
停止可否	停止できず、少なくとも1日分保持	-
作成方法	自動	手動
Auroraクラスタを削除する動き	1. デフォルトで自動的に削除される 2. 削除時に自動バックアップを保持するオプションを選択することも可能	1. Auroraクラスタを削除してもsnapshotは削除されません 2. 手動スナップショットはユーザーが明示的に手動削除する
課金対象	データボリュームのサイズまで無料(超えた分が請求対象)	自動バックアップの保持期間外の（より古い）手動スナップショットに対して請求

2.6 スナップショットをS3へエクスポート

RDS または Aurora スナップショット内のデータをS3にParquet形式で自動エクスポートできる機能です。

• Aurora → S3 → Athena or Redshift Spectrum or EMR or SageMaker などのビッグデータとして分析に使う際活躍する機能
• MySQL dump よりもかなり容量は小さくできるので、コスト的には優秀ですが用途は分析向き
• デフォルトではDB cluster全体的なデータばエクスポートされるが、特定のDBやテーブルだけエクスポートすることも選択可能
  

3. データリストア(復元)方法

3.1 自動バックアップ or 手動バックアップされたsnapshotからリストア

• 新しいclusterが作られることになります
• 自動バックアップや手動バックアップされた時刻にしか戻れなくて、それ以外の任意の時刻に復元できません

3.2. ポイントインタイムリカバリ(PITR)

Auroraでは、自動バックアップ(data)とトランザクションログ（Redo Log）を利用して、この機能を実現しています。

3.2.1 PITRのプロセス

• 自動バックアップ(data)から新しいクラスターを作成(コストは新しいDBクラスターの分が追加で必要になります)
• Redo Logを適用して、指定した時点までデータを復元

3.2.2 PITRの時間に影響を与える要素

• データベース全体的なデータ量:データベースが大きいほど(自動バックアップに含まれるデータ量が多ければ多いほど)、復元に時間がかかる
• redo logの量:適用する必要があるredo logが多いほど、リカバリプロセスに時間がかかります。指定された時点にデータベースを戻すために、各ログエントリを再生する必要があるためです。
• ネットワークとシステムのパフォーマンス:基盤となるインフラストラクチャとネットワークのパフォーマンスも、リカバリプロセスの速度に影響を与える
• トランザクションの複雑さ:より複雑なトランザクションや変更の量が多い場合、トランザクションログの適用に必要な時間が増加する

• RDS MySQLなど従来のMySQLではPITRはbinlogを利用しますが、Auroraではそもそもbinlogはデフォルトで無効です。トランザクションの変更記録は全部redo logやっているからredo logを利用してPITRを行う。

• 手動バックアップで作られたスナップショットはPITRで利用できません。つまり手動スナップショットの頻度を増やしても、PITRの復元時間には影響を与えません。手動スナップショットは、特定の状態を保持したい場合や、バックアップ保持期間を超えてデータを保存したい場合に有用です。
  • 例えば、自動バックアップは１日しか設定していない。手動バックアップで作成されたスナップショットは２日間前の分があったとしても、PITR利用してデータを復元する場合は、２日間まえ分の手動バックアップが利用できず、１日分の自動バックアップからしか利用できない。

• 最新の復元可能な時点は通常5分前まで、5分以内復元できない理由：
  • バックアップとログの処理時間:redo logを5分間隔で定期的にAmazon S3にアップロードします。このプロセスには時間がかかるため、最新のトランザクションログが完全にアップロードされるまでに遅延が生じます。
  • データ整合性の確保: データベースの復元時には、データの整合性を保つために、すべてのトランザクションが正しく適用される必要があります。最新のデータを含むトランザクションログがアップロードされていない場合、データの不整合が発生する可能性があるため、少し前の時点までしか復元できないようになっています。

3.3 バックトラック(backtrack)

3.3.1 仕組み

バックトラックとは、指定した時間までDBクラスターを「巻き戻す」機能です。
該当機能を有効にすると、データベースへ変更を加えるたびに新しいログレコードが作成され、ログシーケンス番号 (LSN) が生成されます。巻き戻し機能を有効にすることで、LSN のストレージ用クラスターに FIFO バッファーがプロビジョニングされます。これにより、素早いアクセスと秒単位で測定されたリカバリ時間が利用できるようになります。
該当のログってredo logなのか、それともbacktrack専用のlogなのかは不明です

3.3.2 巻き戻しのプロセス

• バックトラックを実行する際、Auroraはデータベースが一時停止され、すべての接続を遮断
• その後、変更ログ(redo log?)を利用して、指定された時刻に最も近い一貫性のある時刻にデータベースを巻き戻します

バックトラックは新たなDBクラスターを作成するのではなく、そのデータベース自体を特定の時点に巻き戻すため、スナップショットからの復元よりも迅速に実行することができます。

3.3.3 制限

• バックトラックはAurora MySQLでのみ利用可能で、Aurora PostgreSQLでは利用できません
• バックトトラックウィンドウ(巻き戻せる時間）の上限は72時間です
• バックトラックは、バックアップやスナップショットを置き換えるものではなく(最大72時間まえしか巻き戻せないから)、特定の過去の時点に迅速に戻すための補完的な機能です。
• バックトラック無効である既存のクラスターを有効化することはできません。バックトラック機能は、新しい DB クラスターの作成時または DB クラスターのスナップショットの復元時に有効化できます。(デフォルトは無効)
• バックトラックは、DBクラスター全体に影響します。例えば、1 つのテーブルや 1 つのデータ更新に限定してバックトラックすることはできません。

3.3.4 課金方法

バックトラック機能を有効化するとデータベースへ変更を加えるたびに新しいログレコードが作成されます。

• 変更レコード件数、時間による課金が発生します。
• 東京リージョン：変更レコード100万レコード当たり$0.014
• 変更レコードの件数は以下のようにCloudWatchのメトリクスで確認できます。

AWSのドキュメントに明確に記載されているわけではありませんが、以下は全て個人的な推測です

• バックトラックのために新しいログ機構を使用しているわけではなく、redo logを利用
• redo logは5分間隔でS3にアップロード（バックアップ）されます。そして、Auroraのストレージでは定期的にredo logを削除（頻度は不明）
• バックトラックを有効にすると、バックトラックウィンドウ（巻き戻せる時間）内でredo logをAuroraのストレージに保持しておく必要がある
• そのため、Auroraのストレージでredo logが増え続けます。その分はバックトラックの料金として請求

実際の利用手順は以下をご参考ください。

3.4 リストア方法の比較

	スナップショットからリスト	ポイントインタイムリカバリ (PITR)	バックトラック
機能	データベースの全体的なバックアップ	特定の時点のデータベースを復元	特定の時間までデータベースを巻き戻す
新規/既存	新規cluster	新規cluter	もとのclusterへ復元
復元速度	低速	中速	非常に高速（通常数分以内）
期限	1.手動スナップショット(無期限) 2.自動バックアップのスナップショットの保持期間(1日~最大35日)	自動バックアップのスナップショットの保持期間(1日~最大35日)	最大72時間(３日間)
コスト	必要な時だけ新規clusterの費用	必要な時だけ新規clusterの費用	バックトトラックウィンドウ期間中で発生した変更レコードの件数に応じて課金
使用シーン	長期バックアップ	35日前までのデータに戻る必要がある場合や、元のクラスターを変更せずに過去のデータを確認したい場合	短期的な操作ミスからの迅速なの取り消し ※追加のストレージコストが発生するため、短期的な復旧ニーズがない場合はPITRのみを使用することがコスパ的に高い