Backup Service(バックアップ・サービス)の概要

Backup Service(バックアップ・サービス)を使用すると、DSEクラスター・データのバックアップと復元を実行できます。

OpsCenterを使用して、登録されているすべてのDataStax Enterpriseクラスターにわたりバックアップのスケジュールと管理、バックアップからの復元を行います。Backup Service(バックアップ・サービス)には以下の機能があります。

  • REST APIを使用して、またはOpsCenter UIで視覚的に、すべての関数を実行する
  • コミット・ログのバックアップを含む、完全なデータ保護を常に保証するスマート・バックアップを提供する
  • ローカル・サーバー(サーバー内)、Amazon S3、またはローカル・ファイル・システム上のカスタムの場所にデータをバックアップする
  • バックアップ・ファイルを圧縮してストレージを節約する
  • スケジュール・バックアップの保持ポリシーを指定できる
  • 管理者は、クラスター全体の復元、テーブル・レベルの復元、または特定時点の復元を簡単に実行できる
  • バックアップまたは復元の操作が失敗した場合、運用スタッフに通知する
  • クラスター間のデータの複製(実稼働クラスターから開発クラスターへのデータのコピーなど)、または定義された他の場所(Amazon S3またはローカル・ファイル・システム)からのデータの複製をサポートしている
  • バックアップと復元の詳細なレポートと履歴を提供する

バックアップは、データ・ディレクトリーに格納されているすべてのオンディスク・データ・ファイル(SSTableファイル)のスナップショットです。バックアップは各ノード(サーバー内)にローカルに格納され、スナップショット・データがコピーされる、ローカル・ファイル・システムやAmazon S3のようなクラウド・バックアップ・サービスなどの場所を追加して指定することができます。

システムがオンライン状態の間に、データ・センターごと、キースペースごと、選択した複数のキースペース、またはクラスター内のすべてのキースペースのバックアップを作成できます。
注: バックアップの作成と復元を行う場合、以下の点に注意してください。
  • システム・キースペースのみを含むスナップショットを復元することはできません。復元するスナップショットには、システムと非システム・キースペースの両方が含まれているか、非システム・キースペースのみが含まれている必要があります。
  • テーブル定義を含まないスナップショットを復元することはできません。
  • スナップショットを十分なディスク領域がない場所に復元すると失敗します。復元レポートには、十分な領域がないノードと、復元を正常に行うために必要な領域が表示されます。予防措置の詳細とヒントについては、「バックアップを復元するための十分なディスク領域の監視」を参照してください。
データ・ファイルのスナップショットの作成に対応するには、ノードに十分な空きディスク領域が必要です。空きディスク領域が不十分で指定された割合以下の場合はバックアップが開始されないように空きディスク領域のしきい値を構成します。スナップショット1つではディスク領域をほとんど必要としません。ただし、スナップショットは使わなくなったデータ・ファイルが削除されるのを防ぐため、時間の経過に伴ってディスク使用量が急増する原因となります。各バックアップ場所の保持ポリシーを設定して、スナップショット・データを保持する期間を指定します。
注: OpsCenterのデータ・バックアップでは、nodetoolスナップショット・コマンドを使用して行われた手動のスナップショットは表示または管理されません。

クラスターにDSE SearchノードまたはDSE Analyticsノードが含まれている場合、DSE Searchデータを含むキースペース、またはAnalyticsノードのcfsキースペースを含むバックアップ・ジョブにより、SearchデータとAnalyticsデータは保存されます。Solrインデックスは、復元時に再作成されます。

OpsCenterは、ファイルの重複を防ぐためにバックアップ・データをインテリジェントに格納します。バックアップでは、まず、すべてのインメモリー書き込みをディスクにフラッシュしてから、各キースペースのSSTableファイルのハード・リンクを作成します。完全バックアップと、最後に行った完全バックアップとの差分を使用したインクリメンタル・バックアップを使用する従来のバックアップ・システムとは異なり、OpsCenterのアプローチでは、ファイルの重複なしに、各バックアップ時のデータベースの状態を完全に再作成できます。ローカル・ファイル・システムまたはS3の場所を追加して構成した場合、OpsCenterはそのバックアップ内のSSTableのリストを含む各バックアップのマニフェストを作成し、新しいSSTableファイルのみをアップロードします。

定期的に自動バックアップを実行するようにスケジュールすることも、1回限りのバックアップをスケジュールして、またはアドホック・バックアップとして手動で実行することもできます。

特定時点の復元のコミット・ログ・バックアップ

また、Backup Service(バックアップ・サービス)ではキースペース・バックアップに加えてコミット・ログ・バックアップも使用でき、バックアップ・データを詳細に制御するための特定時点の復元が容易になります。特定時点の復元は、コミット・ログ・バックアップを有効にした後、キースペース・バックアップと併せて使用できます。キースペース・バックアップと同様、コミット・ログ・アーカイブは構成可能な保持ポリシーに基づいて保持されます。

注: 特定時点の復元は、バックアップを復元する特定時点以降にクラスター・トポロジーが変更されていない場合にのみサポートされます。

バックアップ保持ポリシー

各スケジュール・バックアップには、OpsCenterが古いバックアップ・データのファイルを処理する方法を定義する保持ポリシーがあります。デフォルトのポリシーでは、サーバー内のバックアップ・ファイルは30日間保持されます。Amazon S3とローカル・ファイル・システムのデフォルトのポリシーでは、すべて保持されます。スケジュール・バックアップ・タスクと構成された場所ごとに、スナップショット・データを保持する構成可能な期間を設定できます。OpsCenterでは、この保持期間として分単位、時間単位、日数単位、および週単位をサポートしています。たとえば、30日間、26週間、3時間などを経過した古いスナップショット・データを削除する保存ポリシーを定義できます。すべてのバックアップを保持する場合、OpsCenterには、バックアップ・ファイルを無期限で保持する「すべて保持」ポリシーがあります。

時間制限付き保持ポリシーが構成されたバックアップが完了すると、OpsCenterはスナップショット・データをスキャンして、他のスナップショットに属していない古いファイルを検出し、次回のスケジュール・バックアップで削除します。

たとえば、スケジュール・バックアップがS3にデータを送信し、このバックアップが毎週実行され、3日を経過した古いバックアップを削除する保持ポリシーが設定されているとします。S3バケット内のレイアウトは以下のようになります。

mybucket/
  snapshots/
    node-id1/
      sstables/
        MyKeyspace-MyTable-ic-4-Data.db
        MyKeyspace-MyTable-ic-5-Data.db
        MyKeyspace-MyTable-ic-6-Data.db
        MyKeyspace-MyTable-ic-7-Data.db
        ...
      1234-ABCD-2015-01-25-01-00/
        backup.json #includes 4-Data and 5-Data
        MyKeyspace/schema.json
      1234-ABCD-2015-02-01-01-00/
        backup.json #includes 5,6,7-Data
        MyKeyspace/schema.json
   

2月1日のバックアップが完了した後、OpsCenterは保持ポリシーに従って古いファイルについてSSTableをスキャンします。1月25日のバックアップ・ファイルはOpsCenterで削除される可能性があります。MyKeyspace-MyTable-ic-4-Data.dbは1月25日のバックアップに含まれているが、2月1日のバックアップには含まれていないため、このファイルは削除されます。MyKeyspace-MyTable-ic-5-Data.dbは1月25日のバックアップに含まれていますが、最新のバックアップにも含まれているため、定義された保持ポリシーを満たすまで保持されます。

Amazon S3へのバックアップ

Amazon S3バケットをバックアップ・スナップショットを格納するための場所として追加すると、エージェントはスナップショット・ファイルを自動的にS3バケットに送信します。特定のノードとテーブルのすべてのSSTableは、ストレージ・スペースを最適化するためにS3に1回だけ格納されます。
重要: Backup Service(バックアップ・サービス)は、デスティネーションの場所のデータと構造を制御する必要があります。AWS S3バケットとローカル・ファイル・システムのデスティネーションは、OpsCenterのみの専用とする必要があります。これらのデスティネーションに他のディレクトリーやファイルを追加すると、Backup Service(バックアップ・サービス)がバックアップ操作または復元操作を適切に実行できなくなる可能性があります。

バックアップ・ファイルは、S3に以下の階層構造で格納されます。

  mybucket/
    snapshots/
      node-id1/
        sstables/
          MyKeyspace-MyTable-ic-5-Data.db
          ...
          MyKeyspace-MyTable-ic-5-TOC.txt
          MyKeyspace-MyTable-ic-6-Data.db
          ...
        1234-ABCD-2014-10-01-01-00/
          backup.json
          MyKeyspace/schema.json
        1234-ABCD-2014-09-30-01-00/
          backup.json
          MyKeyspace/schema.json
       node-id2/
         sstables/
           MyKeyspace-MyTable-ic-1-Data.db
           ...
           MyKeyspace-MyTable-ic-2-Data.db
           ...
         1234-ABCD-2014-10-01-01-00/
           backup.json
           MyKeyspace/schema.json
         1234-ABCD-2014-09-30-01-00/
           backup.json
           MyKeyspace/schema.json
   commitlogs/
     node1/
       1435432324_Commitlog-3-1432320421.log
       1435433232_Commitlog-3-1432320422.log
       ...
   
backup.jsonファイルには、そのバックアップに含まれるバックアップされたSSTableのメタデータが含まれています。
注: Backup Service(バックアップ・サービス)は、OpsCenterバージョン6.1からAWS SDKに切り替わりました。現在のヒープのデフォルトでは、S3にバックアップする場合、1 TBの最大SSTableファイル・サイズがサポートされています。

OpsCenterでS3へのバックアップ時にエラーが発生した場合、無効なAWS認証情報などの回復不能なエラーが発生しない限り、構成可能な回数(デフォルトでは3回)だけバックアップをリトライします。AWS認証情報とバケット名はcluster_name.confに格納されます。権限のないユーザーがこのファイルを読み取ることができないように、適切なセキュリティ対策を講じてください。

cluster_name.conf

cluster_name.confファイルの場所は、インストールのタイプによって異なります。

  • パッケージ・インストール:/etc/opscenter/clusters/cluster_name.conf
  • tarボール・インストール:install_location/conf/clusters/cluster_name.conf