Skip To Content

データ ストアのバックアップの管理

データ破損やハードウェア故障などの問題が発生した場合にデータを復元できるように、バックアップを作成しておく必要があります。データ ストアのバックアップを作成して安全な場所に保存しておくと、何らかの原因でデータ ストアが強制終了した場合やデータ ストアが再起動できなくなった場合に、新しい ArcGIS Data Store を設定し、バックアップ ファイルにアクセスして、データを復元することができます。

バックアップを作成しておくと、サーバーが故障したり、サーバーが水浸しになって壊れたりした場合など、緊急事態が生じた場合にデータを復旧させることができます。ただし、水浸しになって壊れたサーバー上にバックアップが格納されている場合は、データを復旧させることができません。このため、データ ストアとは別のサーバー上にバックアップ ファイルを格納しておく必要があります。

注意:

バックアップ ファイルにはデータ ストアのみが含まれることに注意してください。バックアップ ファイルでは、GIS Server サイトのバックアップもポータルのバックアップも保持されません。バックアップは、データ ストア コンピューターが故障した場合やデータが破損した場合に、失われたデータの復旧に役立ちます。データが格納されているコンピューターが故障した場合でもホスト フィーチャ レイヤーおよびホスト シーン レイヤーが動作するようにしたい場合、追加データ ストア コンピューターを設定し、データ ストアを高度に利用可能にします。

リレーショナル データ ストアまたはタイル キャッシュ データ ストア (あるいはその両方) を使用する場合、Portal for ArcGIS とともにインストールされた webgisdr ツールを代わりに使用してバックアップを作成できます。webgisdr ツールを使用した場合、ポータルおよびホスティング サーバーのバックアップも作成されます。このツールの使用方法については、『Portal for ArcGIS 管理者ガイド』の「ArcGIS Enterprise バックアップ」をご参照ください。

バックアップの保存場所の定義

ArcGIS Data Store がバックアップ ファイルを配置する、セキュリティで保護された、共有されたバックアップの場所を登録します。データのバックアップを自動的に作成し、この定義された場所を必要とするように、リレーショナル データ ストアを構成します。 デフォルトでは、ArcGIS Data Store はリレーショナル データ ストアのバックアップを /usr/arcgisdatastore/backups に作成します。 つまり、バックアップ ファイルがリレーショナル データ ストアと同じコンピューターに保存されます。データ ストアやプライマリ コンピューターで障害が発生すると、バックアップ ファイルにアクセスできなくなるので、ホスト フィーチャ レイヤーのデータを復元できません。このため、デフォルト以外の場所にバックアップを保存する必要があります。

また、バックアップ ファイルをデータ ストアと同じコンピューター上に残すと、そのコンピューター上のディスク容量が急速に一杯になる可能性があることに注意してください。ディスク容量が不足した場合、データの破損を防ぐために、リレーショナル データ ストアが読み取り専用モードになります。タイル キャッシュ コンピューターおよびビッグ データ ストア コンピューター上で、ディスク容量が不足した場合、データ ストアがシャットダウンします。changedbproperties ユーティリティを使用して、リレーショナル データ ストアが読み取り専用モードになるディスク容量の閾値と、タイル キャッシュおよびビッグ データ ストアがシャットダウンするディスク容量の閾値を制御できます。

リレーショナル タイル キャッシュおよびビッグ データ ストアのバックアップを手動で作成できます。ビッグ データ ストアのバックアップを作成するには、共有ネットワークの場所を登録する必要があります。バックアップを作成する前に、タイル キャッシュのバックアップの場所を登録する必要もあります。タイル キャッシュ データ ストアの共有ネットワーク ロケーションの登録は任意ですが、強くお勧めします。

次の図は、データを保存するための 1 台のコンピューター (プライマリ サーバー) とバックアップ ファイルを保存するためのネットワーク ドライブで構成されるリレーショナル データ ストアを示します。データ ストアとは異なるコンピューターにバックアップ ファイルを保存しておくと、データ ストアを運用しているコンピューターで障害が発生した場合にバックアップ ファイルを失わずに済みます。

1 台のコンピューターとバックアップ ファイルを保存するためのネットワーク ドライブで構成される ArcGIS Data Store

以下の手順に従って、データ ストアのバックアップ ファイルを保存するための共有ディレクトリを構成します。

  1. バックアップ ファイルを保存するための別のコンピューター上の共有ディレクトリを作成します。

    注意:

    データ ストアのバックアップに含まれるすべてのファイルを十分に保持できる格納領域があることを確認します。ファイルの数とサイズは、使用しているデータ、およびデータ ストアのタイプによって変わります。タイル キャッシュ データ ストアは非常に大きくなる可能性があり、ビッグ データ ストアはさらに大きくなる傾向があります。リレーショナル データ ストアのバックアップは自動的に作成され、バックアップの場所が一杯になる速度は、バックアップ スケジュールおよびバックアップを維持する日数によって変わります。バックアップ ディレクトリのサイズを監視し、必要に応じてこれらの設定およびストレージ サイズを調整してください。

    同じ ArcGIS Data Store の配置内のすべてのビッグ データ コンピューターが、この共有ディレクトリにアクセスできる必要があることにも注意してください。

  2. 共有ネットワーク ディレクトリに対する読み取りアクセス権限および書き込みアクセス権限を、ArcGIS Data Store をインストールしたアカウントに付与します。
  3. configurebackuplocation ユーティリティを実行して、共有ディレクトリをデータ ストアのバックアップの出力場所として指定します。

    リレーショナル データ ストアを作成するときに、デフォルトのバックアップの場所が同時に作成されます。この共有されたバックアップの場所を構成する前に、ホスト フィーチャ レイヤーが公開されていた場合、configurebackuplocation ユーティリティは、既存のデータ ストアのバックアップ ファイルをデフォルトのバックアップの場所から共有ディレクトリに移動します。

    タイル キャッシュ データ ストアにも、作成されたときにデフォルトのバックアップの場所が存在します。ただし、タイル キャッシュ データ ストアのサイズが大きい可能性があるため、タイル キャッシュ データ ストアのバックアップの新しい場所を構成しても、既存のデータはコピーされません。そのため、シーン レイヤーを公開する前に、共有されたバックアップの場所を必ず指定してください。

    ビッグ データ ストアには、デフォルトのバックアップの場所がありません。ビッグ データ ストアのバックアップ ファイルを作成する前に、共有されたバックアップの場所を登録する必要があります。

    この例では、リレーショナル データ ストアのバックアップの保存場所が、sysshare というコンピューターの ds_backups という共有ディレクトリに変更されます。

    ./configurebackuplocation.sh --operation change --store relational 
    --location /net/sysshare/ds_backups
    You are going to change the backup location of the data store. Existing backups will be copied to the new location and it could take a few moments. Please do not interrupt the process once it has started.
    Do you want to continue (Yes or No)? Yes

    この例では、ビッグ データ ストア用のバックアップの場所が登録されます。この場所は、sysshare 上の bigdatabus という名前の共有ディレクトリです。

    ./configurebackuplocation.sh --operation register --store spatiotemporal 
    --location /net/sysshare/bigdatabus

ヒント:

リモート バックアップ ディレクトリが数分間以上オフラインになった場合は、共有バックアップの場所が利用可能になったら直ちに完全バックアップを手動で実行します。

データ ストアのバックアップの手動作成

backupdatastore ユーティリティを使用すると、データ ストア内のフィーチャ レイヤー データの完全バックアップを作成できます。データ ストアに多数の変更を加えたり、データ ストアを更新する前に、完全なバックアップを手動で作成することができます。また、データの特定の状態のコピー (たとえば、プロジェクトの最初のフェーズの終了時の状態) を保持するバックアップを作成することもできます。

タイル キャッシュ データ ストアに対して backupdatastore ユーティリティを最初に実行すると、既存のすべてのタイル キャッシュ データ ストア データベースのバックアップ コピーが作成されます。同様に、ビッグ データ ストアに対して backupdatastore ユーティリティを最初に実行すると、完全なバックアップが作成されます。これらの両方のタイプのデータ ストアは非常に大きくなる可能性があるため、backupdatastore ユーティリティを最初に実行した後に実行するたびに、最後にユーティリティを実行してから作成されたデータのみのバックアップ コピーが作成されます。

データ ストア コンピューターに接続して backupdatastore ユーティリティを実行する際に使用するログイン ユーザーに、データ ストアのバックアップの保存場所の読み取りアクセス権と書き込みアクセス権を付与する必要があります。

backupdatastore ユーティリティを実行する構文は次のとおりです。

backupdatastore [<backup_name>] --store {relational | tilecache | spatiotemporal}

データを復元する際にすぐに見つかるように、ファイルにわかりやすい名前を付けておきます。名前を指定しない場合、ユーティリティでファイルにデフォルトの名前が割り当てられます。デフォルトの名前の形式は「データ ストア名-タイムスタンプ」になります。たとえば、データ ストアの名前が「corpds」の場合に、2014 年 7 月 10 日の 14:25:49:554 UTC にバックアップを作成すると、バックアップ ファイルの名前が「corpds-20140710142549554」になります。

バックアップを作成するかどうかの確認を求められます バックアップの作成を開始する場合は、「yes」または「y」と入力します。

ヒント:

手動バックアップのスクリプトを記述する場合は、次の例に示されているように、確認メッセージを抑止するためのフラグを挿入します。

backupdatastore --store tilecache --prompt no

この例では、データ ストアのバックアップ ファイル名が生成されます。この名前は、バックアップ ファイル名の一意性を確保するためにスクリプトで必要となります。

リレーショナル データ ストアのバックアップ間隔の変更

デフォルトでは、ArcGIS Data Store は、4 日ごとにリレーショナル データ ストアの完全バックアップを作成しますが、データ ストアが完全バックアップを作成する頻度は、updatebackupschedule ユーティリティを実行することによって変更できます。お使いのユーザーで多数のホスト フィーチャ レイヤーを公開および編集する場合は、データ ストアの完全バックアップを作成する間隔を長くする必要があります。

10.5 以降、増分バックアップは無効化されます。特定時点への復元を再び有効化した場合、ログ ファイルが最大になるか、または 5 分ごとのいずれかが早く発生したときに、増分バックアップが作成されます。データベースが増分バックアップの作成を制御します。増分バックアップが作成される頻度をユーザーが制御することはできません。

バックアップの保存場所には、すべてのバックアップ ファイルを格納できる十分なサイズが必要です。バックアップのサイズは使用しているデータの量によって変わりますが、デフォルトのバックアップ設定を採用している場合は、バックアップ ディレクトリに 2 つの完全バックアップと 7 日分の増分バックアップ ファイルが格納されます。これらのファイルのサイズは、データの量とサイズによって異なります。特定時点への復元を再び有効化した場合、バックアップには、デフォルトで 7 日分の増分バックアップ ファイルも含まれます。

バックアップを手動で作成することにして、自動バックアップを無効にする場合は、バックアップ間隔を 0 に設定します。自動バックアップを無効にすると、ArcGIS Data Store はバックアップを何も作成しなくなります。ユーザー自身がバックアップを作成する必要があります。

updatebackupschedule ユーティリティは <ArcGIS Data Store installation directory>/datastore/tools ディレクトリにインストールされています。

  1. コマンド シェルを開きます。
  2. updatebackupschedule ユーティリティを実行して、必要なバックアップ間隔を指定します。

    このユーティリティを実行する構文は次のとおりです。

    updatebackupschedule --starttime <local server time> --frequency <number of days>

    たとえば、次のとおりに入力すると、毎日午前 3 時 (ローカル サーバー時間) に完全バックアップを作成するスケジュールが設定されます。

    ./updatebackupschedule.sh --starttime 03:00:00 --frequency 1

リレーショナル データ ストアのバックアップ ファイルの保持期間の変更

デフォルトでは、バックアップ ディレクトリにリレーショナル データ ストアのバックアップ ファイルが 7 日間保持されます。つまり、デフォルトのバックアップ間隔 (4 日間隔) と保持期間 (7 日間) をそのまま採用すると、バックアップ ディレクトリに 2 つの完全バックアップが格納されます。特定時点への復元を再び有効化した場合、バックアップ ディレクトリには、7 日分の増分バックアップ ファイルも含まれます。これらのファイルのサイズは、データの量とサイズによって異なります。バックアップを格納するコンピューターには、これらのファイルをすべて格納できるだけの十分な空き容量が必要です。バックアップ間隔を長くする場合には、バックアップ ファイルの保持期間を短くすることを検討してください。前のセクションでは、バックアップ間隔は毎日まで増やしました。バックアップ ディレクトリのサイズが大きくなりすぎないようにするには、バックアップ ファイルの保持期間を短くします。

updatebackupretaindays ユーティリティを実行する構文は次のとおりです。

updatebackupretaindays <number of days>

次の例では、バックアップ ファイルの保持期間が 4 日間に変更されます。

./updatebackupretaindays.sh 4

データ ストアのバックアップの手動削除

backupdatastore ユーティリティで作成したデータ ストアのバックアップ ファイルを保持する必要がなくなった場合は、listbackups ユーティリティを実行して特定のバックアップ ファイルの名前を取得した後、deletebackup ユーティリティを実行して不要なファイルを削除できます。たとえば、データ ストアを更新し、すべてのレイヤーが正常に動作していることを確認したら、アップグレードの前に作成したデータ ストアのバックアップを削除できます。

この例では、データベース「preupgrade1104_bu」が削除されます。

./listbackups.sh --store relational
Backup_Name                      Status           Backup_Time         Mode
====================================================================================
phase1proj_bu                    BackupComplete   2014-03-08 14:12    manual phase2proj_bu                    BackupComplete   2014-06-21 11:43    manual preupgrade_bu                    BackupComplete   2014-10-04 09:30    manual ds_gdt1oomh-20141103160748082    BackupComplete   2014-11-01 03:00    scheduled
/deletebackup preupgrade1104_bu You are attempting to delete backup 'preupgrade1104_bu'. This operation is irreversible.
Do you wish to continue (Yes or No)?yes
Operation completed successfully