データ破損やハードウェア障害などの問題が発生した場合にデータを復元できるように、バックアップを作成しておく必要があります。データ ストアのバックアップを作成して安全な場所に保存しておくと、何らかの原因でデータ ストアが強制終了した場合やデータ ストアが再起動できなくなった場合に、新しい ArcGIS Data Store を設定し、バックアップ ファイルにアクセスして、データを復元することができます。
「ArcGIS Data Store のバックアップの考慮事項」を参照してから、残りのセクションの情報を使用して ArcGIS Data Store のバックアップを構成および管理します。
- バックアップの保存場所を定義します。
- 自動バックアップを構成します。
- 必要に応じてバックアップを手動で作成します。
ArcGIS Data Store のバックアップの考慮事項
データ ストアのバックアップと復旧戦略を実装する際には、次の点に留意してください。
- バックアップを作成しておくと、サーバーが故障したり、サーバーが水浸しになって壊れたりした場合など、緊急事態が生じた場合にデータを復旧させることができます。ただし、水浸しになって壊れたサーバー上にバックアップが格納されている場合は、データを復旧させることができません。このため、データ ストアとは別のサーバー上にバックアップ ファイルを格納しておく必要があります。
- ArcGIS Data Store のバックアップ ファイルには、リレーショナル データ ストア、タイル キャッシュ データ ストア、またはビッグ データ ストアのみが含まれています。バックアップ ファイルでは、GIS Server サイト、ポータル、ArcGIS Server Manager または ArcGIS Desktop アプリケーションで GIS Server サイトに登録したデータ ストアのバックアップは保持されません。それらのコンポーネントのバックアップは、個別に作成する必要があります。
リレーショナル データ ストアまたはタイル キャッシュ データ ストア (あるいはその両方) を使用する場合、Portal for ArcGIS とともにインストールされた webgisdr ツールを使用してバックアップを作成できます。webgisdr ツールを使用した場合、ポータル、ホスティング サーバー、フェデレーション サーバーのバックアップも作成されます。このツールの使用方法については、『ArcGIS Enterprise 管理者ガイド』の「Portal for ArcGIS バックアップ」をご参照ください。ArcGIS Server Manager または ArcGIS Desktop アプリケーションで GIS Server サイトに登録したデータ ストアのバックアップは、個別に作成する必要があります。
- ArcGIS Data Store のバックアップは、ArcGIS Data Store コンピューターが故障した場合やデータが破損した場合に、失われたデータの復旧に役立ちます。高可用性は実現しません。1 台の ArcGIS Data Store コンピューターが故障した場合でも、ホスト フィーチャ レイヤー、ホスト ビッグデータストア レイヤー、ホスト シーン レイヤーを利用可能にする必要がある場合は、リレーショナル データ ストアおよびタイル キャッシュ データ ストアにスタンバイ コンピューターを追加して高可用性にします。ビッグ データ ストアは、複数のコンピューターを追加して高可用性にすることができます。
- 元の格納メカニズムや ArcGIS ソフトウェアでの変更のため、古いバージョンの ArcGIS Data Store で作成したデータ ストアのバックアップを使用して、データを新しいバージョンの ArcGIS Data Store に復元することはできません。そのため、ArcGIS Data Store をアップグレードした後は、各データ ストアの完全バックアップを作成する必要があります。
バックアップの保存場所の定義
バックアップの保存場所と振舞いは、データ ストアのタイプによって異なります。管理するデータ ストアのタイプに関連する情報をご参照ください。
- リレーショナル データ ストア
リレーショナル データ ストアの作成時には、データ ストアと同じコンピューター上にバックアップの保存場所が自動的に構成されます。デフォルトでは、ArcGIS Data Store はリレーショナル データ ストアのバックアップを c:\arcgisdatastore\backups\relational に作成します。 プライマリ データ ストア コンピューターで障害が発生すると、バックアップ ファイルにアクセスできなくなるので、ホスト フィーチャ レイヤーのデータを復元できません。
バックアップ ファイルをデータ ストアと同じコンピューター上に残しておいてはならないもう 1 つの理由は、これらのファイルによってコンピューター上のディスク容量が急速に満杯になる可能性があることです。ディスク容量が不足した場合、データの破損を防ぐために、リレーショナル データ ストアが読み取り専用モードになります。
そのため、デフォルトの場所ではなく、別のコンピューター上のセキュアな共有ファイル ディレクトリに自動バックアップのファイル ディレクトリを定義します。このファイル ディレクトリは、デフォルトのバックアップ場所と見なされます。ArcGIS Data Store によって自動的に作成されるバックアップは、常にデフォルトのバックアップ場所に保存されます。change ユーティリティで configurebackuplocation 操作を使用して、デフォルトのバックアップ場所を変更できます。
その他のファイル共有、Amazon Simple Storage Service (S3) バケット、Microsoft Azure Blob ストレージ コンテナーなど、ユーザー独自のリレーショナル データ ストアには、追加のバックアップ場所を登録できます。この追加の場所は、backupdatastore ユーティリティを使用して作成する完全バックアップの格納に使用できます。
- タイル キャッシュ データ ストア
タイル キャッシュ データ ストアの作成時には、バックアップの保存場所が自動的に構成されますが、これはデータ ストアと同じコンピューター上に配置されます。デフォルトでは、ArcGIS Data Store はタイル キャッシュ データ ストアのバックアップを c:\arcgisdatastore\backups\tilecache に作成します。 プライマリ データ ストア コンピューターで障害が発生すると、バックアップ ファイルにアクセスできなくなるので、シーン レイヤーのデータを復元できません。
バックアップ ファイルをデータ ストアと同じコンピューター上に残しておいてはならないもう 1 つの理由は、これらのファイルによってコンピューター上のディスク容量が急速に満杯になる可能性があることです。ディスク容量が不足した場合、タイル キャッシュ データ ストアがシャットダウンします。
そのため、デフォルトの場所ではなく、バックアップに別のコンピューター上のセキュアな共有ファイル ディレクトリを登録する必要があります。backupdatastore ユーティリティを使用してバックアップを作成する前に、自動バックアップの共有ファイル ディレクトリを定義します。このファイル ディレクトリは、デフォルトのバックアップ場所と見なされます。ArcGIS Data Store によって作成されるタイル キャッシュ データ ストアのバックアップは、常にこの場所に配置されます。change ユーティリティで configurebackuplocation 操作を使用して、デフォルトのバックアップ場所を変更できます。
- ビッグ データ ストア
ビッグ データ ストアの作成時には、デフォルトのバックアップの場所がありません。ビッグ データ ストアのバックアップ ファイルを作成する前に、バックアップの場所を少なくとも 1 つ登録する必要があります。ファイル共有、Amazon S3 バケット、Microsoft Azure Blob ストレージ コンテナーを登録できます。ビッグ データ ストアについては、複数のバックアップ場所を指定し、そのうち 1 つをデフォルトの場所として設定することも可能です。ArcGIS Data Store によって自動的に作成されるバックアップは、常にデフォルトのバックアップ場所に保存されます。この場所のディスク容量が不足した場合、ビッグ データ ストアがシャットダウンします。
backupdatastore ユーティリティを使用して作成する追加のバックアップ場所には、手動の完全バックアップを記述できます。そのためには、別のバックアップ場所を登録する必要があります。
デフォルトのバックアップ場所の登録
ArcGIS Data Store がスケジュールされた (自動) バックアップによってファイルを配置できる、セキュアな共有されたデフォルトのバックアップ場所を登録します。
以下の手順に従って、データ ストアのバックアップ ファイルを保存するための共有ディレクトリを構成します。
- バックアップ ファイルを保存するための別のコンピューター上の共有ディレクトリを作成します。
備考:
データ ストアのバックアップに含まれるすべてのファイルを十分に保持できる格納領域があることを確認します。ファイルの数とサイズは、使用しているデータ、およびデータ ストアのタイプによって変わります。タイル キャッシュ データ ストアは非常に大きくなる可能性があり、ビッグ データ ストアはさらに大きくなる傾向があります。データ ストアのバックアップは自動的に作成され、バックアップの場所が一杯になる速度は、バックアップ スケジュールおよびバックアップを維持する日数によって変わります。バックアップ ディレクトリのサイズを監視し、必要に応じてこれらの設定およびストレージ サイズを調整してください。
同じ ArcGIS Data Store の配置内のすべてのビッグ データ コンピューターが、この共有ディレクトリにアクセスできる必要があることにも注意してください。
- ArcGIS Data Store をインストールまたはアップグレードしたときにドメインの ArcGIS Data Store アカウントを指定しなかった場合は、ここでデータ ストア サービスがドメイン アカウントを使用して実行されるように設定し、そのアカウントに共有ネットワーク ディレクトリへの読み取りと書き込みのアクセス権を付与します。
- configurebackuplocation ユーティリティを実行して、共有ディレクトリをデータ ストアのバックアップのデフォルトの出力場所として指定します。
ビッグ データ ストアの作成時には、デフォルトのバックアップの場所がありません。ビッグ データ ストアのバックアップ ファイルを作成する前に、バックアップの場所を少なくとも 1 つ登録する必要があります。ファイル共有、Amazon S3 バケット、Microsoft Azure Blob ストレージ コンテナーを登録できます。
推奨される共有のバックアップ用ディレクトリを構成する前に、ユーザーがホスト フィーチャ レイヤーを公開し、自動バックアップが実行された場合、configurebackuplocation ユーティリティは、既存のリレーショナル データ ストアのバックアップ ファイルをデフォルトのバックアップの場所から共有ディレクトリに移動します。
タイル キャッシュ データ ストアのサイズが大きい可能性があるため、タイル キャッシュ データ ストアのバックアップの新しい場所を構成しても、既存のデータはコピーされません。そのため、ユーザーがシーン レイヤーを公開する前に、共有されたバックアップの場所を必ず指定してください。
この例では、リレーショナル データ ストアのバックアップの保存場所が、sysshare というコンピューターの ds_backups という共有ディレクトリに変更されます。
configurebackuplocation --operation change --store relational --location \\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 --operation register --store spatiotemporal --location \\sysshare\bigdatabus完全な構文とその他の例 (クラウド ストレージのバックアップ場所の構成例を含む) については、「ArcGIS Data Store ユーティリティ リファレンス」をご参照ください。
ヒント:
リモート バックアップ ディレクトリが数分間以上オフラインになった場合は、共有バックアップの場所が利用可能になったら直ちに完全バックアップを手動で実行します。
追加のバックアップ場所の登録
ビッグ データ ストアとリレーショナル データ ストアについては、追加のバックアップ場所を登録するオプションがあります。これらの場所は、backupdatastore ユーティリティを使用して手動で作成するバックアップの格納に使用できます。
備考:
ユーザーは手動バックアップのストレージ場所をクリーンナップする必要があります。ArcGIS Data Store はファイルを削除しないからです。
ビッグ データ ストアまたはリレーショナル データ ストア用に作成するバックアップ ファイル用に別の場所を追加するには、以下の手順を実行します。
- バックアップ ファイル用に別の場所を作成します。
- 共有ディレクトリを登録するには、別のコンピューター上にそのディレクトリを作成します。すべてのバックアップ ファイルを保持できるように格納領域の大きさを十分に確保し、backupdatastore ユーティリティを実行するために ArcGIS Data Store コンピューターに接続するときに使用するログインが、このディレクトリへの書き込みアクセス権を持つようにします。ビッグ データ ストア用に 2 つ目の共有ディレクトリを作成する場合、同じ ArcGIS Data Store 配置内のすべてのビッグ データ ストア コンピューターがこの共有ディレクトリへのアクセス権を持つようにします。
- S3 バケットを登録するには、Amazon Web Services アカウントにバケットを作成します。バックアップ ファイルに対応できるバケット サイズを選択します。
- Azure Blob ストレージ コンテナーを登録するには、Azure Blob ストレージ アカウントにコンテナーを作成します。
- configurebackuplocation ユーティリティで register 操作を実行して、この追加のバックアップ場所を登録します。
自動バックアップの管理
デフォルトでは、ArcGIS Data Store は、4 日ごとにデータ ストアの完全バックアップを作成しますが、データ ストアが完全バックアップを作成する頻度は、updatebackupschedule ユーティリティを実行することによって変更できます。
バックアップ間隔の変更
ポータル メンバーが多数のホスト レイヤーを公開および編集する場合や、大容量のストリーミング データをアーカイブする場合は、バックアップの頻度を増やします。
備考:
デフォルトでは、リレーショナル データ ストアに対する増分バックアップは無効になっています。特定時点への復元を有効化した場合、ログ ファイルがいっぱいになるか、または 5 分経過するかのいずれかが先に発生したときに、増分バックアップが作成されます。データベースが増分バックアップの作成を制御します。増分バックアップが作成される頻度をユーザーが制御することはできません。
バックアップの保存場所には、すべてのバックアップ ファイルを格納できる十分なサイズが必要です。バックアップのサイズは使用しているデータの量によって変わりますが、デフォルトのバックアップ設定を採用している場合は、バックアップ ディレクトリに 2 つの完全バックアップと 7 日分の増分バックアップ ファイルが格納されます。これらのファイルのサイズは、データの量とサイズによって異なります。リレーショナル データ ストアに対する特定時点への復元を再び有効化した場合、バックアップには、デフォルトで 7 日分の増分バックアップ ファイルも含まれます。
タイル キャッシュ データ ストアまたはビッグ データ ストアのバックアップ ファイルに対する自動クリーンナップは存在しないので、注意してください。これらのデータ ストアのバックアップ頻度を増やす場合には、バックアップ場所のクリーンナップ頻度も増やす必要が生じることがよくあります。
バックアップを手動で作成することにして、自動バックアップを無効にする場合は、バックアップ間隔を 0 に設定します。自動バックアップを無効にする場合は、ユーザー自身がバックアップを作成して、コンピューターの故障やその他のデータ災害発生時のデータの損失を防ぐ必要があります。
updatebackupschedule ユーティリティは <ArcGIS Data Store installation directory>\datastore\tools ディレクトリにインストールされています。
- [管理者として実行] オプションを使用して、コマンド プロンプトを開きます。
- updatebackupschedule ユーティリティを実行して、必要なバックアップ間隔を指定します。
このユーティリティを実行する構文は次のとおりです。
updatebackupschedule [--store relational|tileCache|spatiotemporal] [--starttime <local server time>] --frequency <number of days>たとえば、次のとおりに入力すると、毎日午前 3 時 (ローカル サーバー時間) にリレーショナル データ ストアの完全バックアップを作成するスケジュールが設定されます。
updatebackupschedule --store relational --starttime 03:00:00 --frequency 1この例では、ビッグ データ ストアのバックアップは、3 日間隔で午後 11 時 30 分 (ローカル サーバー時間) に実行されます。
updatebackupschedule --store spatiotemporal --starttime 23:30:00 --frequency 3
リレーショナル データ ストアの自動バックアップ ファイルの保持期間の変更
デフォルトでは、バックアップ ディレクトリにリレーショナル データ ストアのバックアップ ファイルが 7 日間保持されます。つまり、デフォルトのバックアップ間隔 (4 日間隔) と保持期間 (7 日間) をそのまま採用すると、バックアップ ディレクトリに 2 つの完全バックアップが格納されます。特定時点への復元を再び有効化した場合、バックアップ ディレクトリには、7 日分の増分バックアップ ファイルも含まれます。これらのファイルのサイズは、データの量とサイズによって異なります。バックアップを格納するコンピューターには、これらのファイルをすべて格納できるだけの十分な空き容量が必要です。バックアップ頻度を増やす場合には、バックアップ ファイルの保持期間を短くすることを検討してください。前のセクションでは、バックアップ頻度は毎日まで増やしました。バックアップ ディレクトリのサイズが大きくなりすぎないようにするには、バックアップ ファイルの保持期間を短くします。
updatebackupretaindays ユーティリティを実行する構文は次のとおりです。
updatebackupretaindays <number of days>
次の例では、バックアップ ファイルの保持期間が 4 日間に変更されます。
updatebackupretaindays 4
バックアップの手動での作成および削除
自動バックアップを使用する場合でも、システムのアップグレード前や、別の場所に 2 つ目の完全バックアップを作成する場合など、特定の目的で通常のバックアップ スケジュール以外にバックアップを作成する必要が生じることがあります。
自動バックアップを無効にする場合は、手動バックアップを定期的に作成する必要があります。
手動で作成するバックアップ ファイルはすべて、リレーショナル データ ストアであっても、手動で削除する必要があります。
データ ストアのバックアップ作成のためのユーティリティの実行
backupdatastore ユーティリティを使用すると、データ ストア内のフィーチャ レイヤー データの完全バックアップを作成できます。データ ストアに多数の変更を加えたり、データ ストアを更新する前に、完全なバックアップを手動で作成することができます。また、データの特定の状態のコピー (たとえば、プロジェクトの最初のフェーズの終了時の状態) を保持するバックアップを作成することもできます。
タイル キャッシュ データ ストアに対して backupdatastore ユーティリティを最初に実行すると、既存のすべてのタイル キャッシュ データ ストア データベースのバックアップ コピーが作成されます。同様に、ビッグ データ ストアに対して backupdatastore ユーティリティを最初に実行すると、完全なバックアップが作成されます。これらの両方のタイプのデータ ストアは非常に大きくなる可能性があるため、backupdatastore ユーティリティを最初に実行した後に実行するたびに、最後にユーティリティを実行してから作成されたデータのみのバックアップ コピーが作成されます。
データ ストア コンピューターに接続して backupdatastore ユーティリティを実行する際に使用するログイン ユーザーに、データ ストアのバックアップの保存場所の読み取りアクセス権と書き込みアクセス権を付与する必要があります。
backupdatastore ユーティリティを実行する構文は次のとおりです。
backupdatastore [<backup name>] [--store {relational|tileCache|spatiotemporal}] [--location <backup_arguments>] [--prompt <yes | no>]
--location パラメーターは、ビッグ データ ストアとリレーショナル データ ストアに対してサポートされています。このパラメーターに対する引数は次の通りで、それぞれをセミコロン (;) で区切らなければなりません。
- type=: 指定できるタイプとして、fs (ファイル共有)、s3 (Amazon Simple Storage Service (S3) バケット)、azure (Microsoft Azure Blob ストレージ コンテナー) があります。
- name=: ビッグ データ ストア用に構成したバックアップ場所に名前を与えた場合、backupdatastore ユーティリティに対しても、バックアップ ファイルの作成場所をこの名前で指定できます。
- location=: バックアップ場所の名前を指定しなかった場合は、バックアップの type と location を指定しなければなりません。ファイル共有の場合はファイル パスを指定します。S3 バケットの場合はバケット名を指定します。Azure Blob ストレージ コンテナーについては、コンテナー名を指定します。
データを復元する際にすぐに見つかるように、ファイルにわかりやすいバックアップ名を付けておきます。名前を指定しない場合、ユーティリティでファイルにデフォルトの名前が割り当てられます。デフォルトの名前の形式は「データ ストア名-タイムスタンプ」になります。たとえば、データ ストアの名前が「corpds」の場合に、2014 年 7 月 10 日の 14:25:49:554 UTC にバックアップを作成すると、バックアップ ファイルの名前が「corpds-20140710142549554」になります。
バックアップを作成するかどうかの確認を求められます バックアップの作成を開始する場合は、「yes」または「y」と入力します。
ヒント:
手動バックアップのスクリプトを記述する場合は、次の例に示されているように、確認メッセージを抑止するためのフラグを挿入します。
backupdatastore --store tilecache --prompt no
この例では、データ ストアのバックアップ ファイル名が生成されます。この名前は、バックアップ ファイル名の一意性を確保するためにスクリプトで必要となります。
データ ストアのバックアップの手動削除
backupdatastore ユーティリティで作成したデータ ストアのバックアップ ファイルを保持する必要がなくなった場合は、listbackups ユーティリティを実行して特定のバックアップ ファイルの名前を取得した後、deletebackup ユーティリティを実行して不要なファイルを削除できます。たとえば、データ ストアを更新し、すべてのレイヤーが正常に動作していることを確認したら、アップグレードの前に作成したデータ ストアのバックアップを削除できます。
この例では、データベース「preupgrade1104_bu」が削除されます。
listbackups --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 preupgrade1104_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