データベースのバックアップの基本

データベースのバックアップを実現するやり方

バックアップと復元は、ファイルや、プログラミングライブラリなどのバイナリオブジェクトの場合、比較的シンプルに実行できます。オブジェクトを通常は別のロケーションにある別個のストレージアレイにコピーするだけで済みます。復元が必要であれば、それをコピーして戻します。データベースの場合、それほどシンプルではありません。データベースのバックアップには、データ自体以外にも、複雑で相互依存関係にあるシステム要素の複製も伴います。

データベースバックアップが極めて重要であることを認識する

データがビジネスにとって重要であるということは何度も耳にする話ですが、そのすべてのデータが1つの特定の場所に存在しなければならないという点は忘れられがちです。また、非リレーショナルデータベース、データレイクなどがコーポレートITに取り入れられつつありますが、現状のところ、ほとんどの通常のビジネスデータは標準的なリレーショナルデータベース管理システム（RDBMS）内に存在しています。Microsoft SQL Server、IBM DB2、Oracle、MongoDBなどがこれに該当します。 

これらのRDBMS向けに信頼性の高いデータベースバックアップを作成することはビジネスにとって極めて重要であり、その理由は多岐にわたります。第一に、ほとんどのビジネス取引はRDBMSに記録されます。会社の財務記録に加え、顧客データなど専有性のあるビジネス情報も、必ずRDBMSの行と列に記録され保存されています。このデータを失ってしまったとしたら、会社は財務履歴を喪失することになります。会計処理と財務報告が不可能となり、現代の経営に不可欠とされているデータ分析も、分析の種類を問わずできなくなります。 

また、データベースを正常な状態に復旧できなければ、事業運営を継続する能力も事業者は失います。そうなってしまうのは、データベースが通常、販売注文管理システムやERPソリューションなどのトランザクションシステムに接続されているためです。データベースが存在しなければ、トランザクションシステムも稼働できなくなります。

データベースのバックアップが難易度の高いタスクとなりうる理由

データベースのバックアップは二重のプロセスであるため、難易度の高いタスクになりがちです。バックアッププロセスにおいては、データをバックアップすること以外に、さまざまな構成や設定などのメタデータも考慮に入れる必要があります。ここでいうメタデータとは、アプリケーション内に存在するものの、データベース自体に属してはいないメタデータのことです。システム全体を、別個のインフラストラクチャへと安全にコピーしなければなりません。さらに、ホスティング場所の問題があります。データベースは今日、いくつものオンプレミスサーバーやクラウドベースのインスタンスにまたがって分散していることもあり、この傾向は特に大規模組織でよく見受けられます。 

また、データベースは必ず、少なくとも1つの他のシステムと連携しています。CassandraやNoSQLを実行しているのでしたら、これらはスタンドアロンのアプリケーションではありません。LinuxやWindows Serverなどのサーバー上で実行されます。基盤となるサーバーの構成がデータベースの正常な動作に不可欠であり、これも完全かつ正確にバックアップしなければなりません。そうしておかないとデータベースの復元できなくなります。一般に、RDBMSもERPなど運営管理のための業務システムと連携しています。データベースのバックアップを行う際には、この連携設定もバックアップする必要があります。さもないと、この場合も、復元はできても要件に沿った動作をしません。 

一方で、バックアップのウィンドウは短く、一般に縮小傾向にあります。事業内容によっては、データベースのバックアップを1時間ごとに行う場合があり、それどころか数分おきに行う場合もあります。金融サービス機関など特定の種類の企業では、RTOとRPOが秒単位で測定されていることもあります。

データベースのバックアップのためのベストプラクティス 

データベースのバックアップのためのベストプラクティスは、必要なデータの3つのコピーを2種類のストレージモード（うち1つはオフサイトの場所）で保持するという「3-2-1バックアップルール」を含みますが、それにとどまるようなものではありません。使いやすさ、定期的なテストや、ベンダーに対する適切なサポートなども、すべて必要です。しかしながら、信頼性の高いデータベースバックアップの目標、すなわち、システム全体とそのデータを、たとえ何が起きても機能できるようにバックアップすることを実現させるには、より深い洞察に基づくベストプラクティス一式が必要となります。そのためには、特に以下のことが必要です。

• データベースの詳細なマップを作成して維持すること。これには、デプロイ先や、他のシステムとの連携方法も含まれます。このマップに変更を加える場合は、その変更内容に対応させてバックアップ手順の内容も変更する必要があります。

• 復元されたバージョンのデータベースの実行可能性に影響を与える設定やカスタマイズのインベントリを作成して維持すること。ほんの些細な構成ミスでも、少なくとも問題が検出されるまで、復元されたデータベースを運用不能の状態にしてしまう可能性があります。

Rubrikの優れたセキュリティ機能

Rubrikは、業界をリードするすべてのRDBMSに対応したネイティブコネクタによるデータベースバックアップを可能にします。また、データベース保護をシンプルなタスクにし、手間のかかるスクリプト作成やジョブスケジューリングを不要にします。データベースバックアップ管理者は単に、保護するデータベースを指定するだけで済みます。あるいは、保護するデータベースサーバーを指定するだけでも済みます。Rubrikは堅牢なSLAポリシーエンジンにより、トポロジに変更があれば自動的に調整して適応します。また、データベースバックアップのための複雑なワークロードをシングルペイン・オブ・グラス（単一管理画面）から処理できます。そのため、管理上の複雑さを、物理環境、仮想環境、およびクラウドのワークロードのすべてにわたり、単一のUI駆動型インターフェースを通じて減らすことが可能です。

Rubrikがデータベースバックアップソリューションを通じてデータベースの保護にどのように役立つかについて、詳細をご確認ください。