データベースのバックアップはどのように業務を遂行しているかに依存する

 

データベースをどのようにバックアップするかは、データベースがどのように業務を遂行するか、データベースのバックアップのロジスティクス、そして、あなたが満たそうとしている復旧時間目標（RTO）と復旧時点目標（RPO）という3つの要素に依存します。ここでは、データベースがどのように配信されるかを検証してみます。

データベースの提供方法には、所有するサーバ上でのソフトウェアとして、Platform-as-a-Service（PaaS）として、そしてサーバレスサービスとして、の3つがあります。それらについて考えてみます。

従来のデータベース・ソフトウェア

数年前まで、データベースはすべて製品のライセンスを購入し、好きなサーバやVMにインストールすることで提供されていました。サーバのセキュリティや管理、ストレージ、アプリケーション自体、そして（もちろん）データベースのバックアップも含めて、すべて自分で責任を持つ必要がありました。

つまり、バックアップの方法を含め、さまざまな選択ができるのです。データベースの挙動は特殊で、非構造化データ用に設計された手法では簡単にバックアップできないため、いくつかの可能性は完全に無効です。以下の3つのコンセプトは、従来から提供されているほぼすべてのデータベースに当てはまります。

移動するターゲット

データベースのデータは通常、データファイルに格納されており、ホストしているサーバやVMのファイルシステムで見ることができます。これらのファイルは、何かがデータベースを更新している限り、常に変化しています。つまり、他のファイルのようにバックアップを取ることはできないのです。

ポイントインタイムバックアップとリストア

ほとんどのデータベースバックアップ方式は、毎晩22時など、コピーを作成した時点のデータベースのコピーを作成します。つまり、その時点までのデータベースしか復元できないのです。

特定時点からのロールフォワード、バックワード

より厳しいRPOを満たすために、ほとんどのデータベースにはトランザクションのログがあり、ポイントインタイム・リストアの後にそれを再生して、その時点を指定したより新しい時点に移動させることができます。このログは、データベースがクラッシュして一貫性のない状態で起動した場合に、トランザクションをロールバックするためにも使用できます。

これら3つの一般的な概念は、あなたが管理するサーバやVM上で動作するほぼすべてのデータベースの背後にあるものですが、すべてのルールには例外があります。データファイルはブロックデバイスであって全くファイルでないこともありますし、データベースが変化していても変化しないこともあります。従来から提供されているデータベースのバックアップを正しく行うための鍵は、データベースが上記の3つの課題をどのように解決しているかを理解することにあります。

従来から提供されているデータベースのバックアップで最も一般的な方法は、夜間コピー（フルまたはインクリメンタル）、それに続くトランザクションログの継続的なバックアップです。ダンプによってデータベース全体を復元し、ログによって物事がうまくいかなくなった時点までトランザクションをロールフォワードすることができるようになります。

プラットフォーム・アズ・ア・サービス（Platform-as-a-Service)

データベースを提供する第二の方法は、プラットフォーム・アズ・ア・サービス（PaaS）モデルで、ユーザはアプリケーションだけを見ることができ、その背後にあるインフラへのアクセスは制限されているか、全くできない。Amazon Relational Database Service（RDS）はPaaSの一例で、Oracle、MySQL、PostgreSQL、MariaDB、Auroraデータベースを提供するように設定することが可能である。AzureでもSQL Server、MySQL、PostgreSQLなどをPaaS構成で提供しています。

PaaSデータベースのバックアップオプションは、通常、非常に簡単です。各PaaSは、バックアップとリカバリをサポートするメカニズムを提供する。バックアップは毎日自動的に実行され、通常はそのベンダーのオブジェクトストレージにコピーが作成されるものもある。また、バックアップを実行するために、ユーザがバックアップを設定する必要があるものもある。したがって、PaaSのデータベースが自動的にバックアップされてはいません。

実際、どのインフラストラクチャもバックアップされているとは考えない方がよいでしょう。使用中の各 PaaS データベースを調査し、どのようなバックアップとリカバリのオプションがあるか確認してください。PaaS データベースのデフォルトのバックアップ方法のほとんどは、データベースが動作しているのと同じアカウントとリージョンにバックアップをコピーします。これは、2つのデータセンターを破壊したOVHの火災のようなものからあなたを保護する良いアイデアです。

サーバレスデータベース

サーバレスデータベースは、PaaSをさらに一歩進め、顧客からさらに多くの管理要件を取り除き、より使いやすいエクスペリエンスを実現します。AWS DynamoDB、Aurora Serverless、Azure Cosmos DBはすべて、このようなデータベースの例です。

サーバレスデータベースでは、何も設定する必要がありません。文字通り、データを入れ始めるだけです。計算機やストレージのリソース、データベースのパーティショニングの決定などは、自動的に決定されプロビジョニングされます。あまりにマジックのようなので、バックアップも自動的に処理されると思い込んでいる人が多いのですが、必ずしもそうではありません。

PaaSデータベースと同様、バックアップ方法はデータベースを提供するベンダーによって決定されます。したがって、ベストプラクティスは同じです。また、データを別のリージョンやアカウントにコピーする方法も確認しておきましょう。

クラウドは魔法ではありませんが、データベースのバックアップとリカバリーが非常に簡単になったことは確かです。データベース全体のバックアップを簡単に作成できるため、たとえ数百のノードに存在するパーティションのバックアップであっても、従来の環境ですべてを管理する場合に比べ、はるかに簡単に行えるようになった。ただ、あまりに簡単すぎて、思い込みが激しくならないようにしましょう。それは常にバックアップの失敗の元となります。

関連したトピックス

• AWSデータベースの新たなレベルとしてのAurora
• ユーザ・データベースの最適化とOracle支出の削減
• Azure Database for PostgreSQLを使い始めるにあたって
• DPA(Database Performance Analyzer) for Open-Source Database: MySQL, MariaDB, Percona, PostgreSQL
• 進化するクエリと PostgreSQLの台頭：そのデータベー スパフォーマンス重要性
• PostgreSQLとMySQLのデータベースとしての機能の違い
• データウェアハウスの利点とヒント
• データベースのトラブルシュートを加速化させる方法について
• [DBMoto]Amazon Auroraを正式サポート！オンプレミスDBからの移行やDB間の連携に！
• PostgreSQLパフォーマンス・チューニング・ツール（クエリアナライザ付き) [DPA]