データベースに採用すべきバックアップ戦略について質問する人がよくいます。失敗することは決してないようです。さまざまなフォーラムで私が遭遇したこの種の質問には、回復要件が含まれることは一度もありません。バックアップ戦略を設計する前に、リカバリ要件を検討することにしばしば困惑しました。要件を求められると、たとえば次のようなバックアップ要件が発生することがよくあります。
- バックアップによってダウンタイムが発生することはありません
- アーカイブされたREDOログをバックアップできるようにする必要があります
- バックアップはテープに書き込む必要があります
これらの要件は適切ですが、私の意見では、最初にリカバリ要件を文書化し、管理の発生を取得することなく、バックアップ戦略を設計するべきではありません。
したがって、バックアップ戦略を設計するときに私が自問するいくつかの質問があります。これらの質問はすべて、物事の回復の側面に焦点を合わせていることに注意してください。
- データベースを復元するときに、どのくらいのデータ損失を許容できますか？データ損失ゼロ？データベースの復旧後、1時間のデータ損失は許容されますか？
- トランザクションをロールフォワードする必要がありますか？つまり、ポイントインタイムリストアを実行する必要がありますか？
- 他のスキーマをそのままにして、1つのスキーマの内容を復元する必要がありますか？
- 障害が発生した後、データベースを稼働させるにはどのくらいの時間がかかりますか？
- どのような障害から回復する必要がありますか？明らかに、サーバーの完全な障害やディスクの損失から復元できる必要があります。しかし、誤ってテーブルを削除した人のような人的障害から回復できる必要がありますか？
- 本番環境のコピーからデータベースを更新またはテストする一環として、バックアップを他のサーバーに復元する必要がありますか？
最近のOracleコミュニティのほとんどの人に尋ねると、データベースのバックアップにRMANを使用するように言われます。 RMANは優れた製品であり、多くの点で、古いスタイルのユーザー管理のホットバックアップまたはコールドバックアップよりも優れています。一部のOracleDBAは、RMANを使用してホットバックアップを実行し、本番データベースをアーカイブログモードで実行するように指示します。そうすることで、直面する可能性のある回復シナリオの多くをカバーできます。しかし、質問4に対する答えが、復旧して実行するのに1時間あり、データベースのサイズが10TBである場合はどうでしょうか。 RMANを使用して1時間で10TBデータベースの完全な復元を実行しようと頑張ってください。また、RMANはスキーマレベルでバックアップを行わないため、RMANは質問3を支援できません。
データベース内のデータをバックアップおよび回復するために、DBAが自由に使用できる多くのツールがあります。これらのツールには次のものが含まれますが、これらに限定されません。
- OracleのRecoveryManager（RMAN）
- Oracleユーザー管理バックアップ
- Oracleのエクスポート/インポートまたはデータポンプ
- ディスクベースのスナップショット
- ディスクベースのレプリケーション
- OracleのDataGuard
では、どちらを使用しますか？それぞれに長所と短所があります。リカバリ要件がわかれば、データベースをバックアップするためのツールがより明確になり始めます。また、すべてのリカバリ要件を満たすために、複数のバックアップツールを使用する必要がある場合があります。いくつかの提案として、アーカイブログモードのみのRMANを使用していて、マネージャーがあなたのところに来て、「この10TBデータベースを1時間でバックアップして実行する必要があります！」と言った場合。あなたの仕事はうまくいくかもしれません。
これが次のポイントにつながります。リカバリ要件を文書化し、サービスレベルアグリーメント（SLA）に組み込みます。 SLAを作成して検証するとき、管理者はデータ損失をゼロにしたいと言うかもしれません。この時点で、データ損失ゼロのソリューションを実装することの長所と短所を提示できます。また、コストについても言及できます。多くの企業は、データ損失ゼロのソリューションの高コストを躊躇しますが、他の企業の場合、トランザクションを失うことによる経済的負担と比較すると、コストは小さくなります。ここで、物々交換と物々交換が行われます。経営陣がデータ損失ゼロのソリューションを主張する場合、RMAN（無料）はそれを提供しないため、経営陣はそれをサポートするための資金を考え出す必要があります。リカバリ要件をSLAに文書化すると、バックアップ戦略でサポートするように設計されていないものをリカバリするように管理者から依頼することは困難になります。 SLAが実施されていて、すべてのトランザクションを回復するように求められ、バックアップ戦略でそれが許可されない場合は、データの損失をゼロにする必要がないことを示すドキュメントがあり、これにより作業を節約できます。
そうは言っても、リカバリ要件をSLAに文書化したら、バックアップ戦略によって、SLAに文書化されているすべてのリカバリシナリオを実行できることを確認してください。あなたの仕事はそれに依存するかもしれません。 SLAがデータ損失ゼロと言っており、経営陣がデータガードに資金を提供する意思があるにもかかわらず、Data Guardを実装しない場合、あなたが仕事を続けていなかったために、データガードがあなたを終了させる可能性があります。
最後に、徹底的にテストされない限り、バックアップ/リカバリ戦略は完了しません。 SLAに記載されているすべての要件を満たすことができることを確認するために、必要なすべてのリカバリ戦略をテストする必要があります。テストは、2つの理由で年に1回以上実行する必要があります。1つは、システムへの変更が必要なリカバリを実行する能力に悪影響を与えないことを確認すること、2つは、リカバリを実行する方法を最新の状態に保つことです。あなたが実際にそれをしなければならないなら、あなたは手順をいじくり回していません。テストでは、バックアップ方法論が必要なリカバリシナリオをサポートしていることがわかる場合がありますが、必要に応じて用意しておくと便利です。
そして、私はそれを十分に言うことはできません…。テスト、テスト、そしてテスト！