Threat Grid アプライアンス（v2.2.4 以降）は、NFS 対応ストレージへの暗号化されたバックアップ、NFS 対応ストレージからのデータの初期化、さらに、データベースを空の状態にリセットして前述のバックアップのロードを可能にする機能をサポートしています。

（注）	リセットは、アプライアンスのワイププロセスとは異なっており、アプライアンスが情報漏えいなしで顧客構内に出荷されるようにするために使用され、バックアップ準備のためにも使用されます。その目的に適したワイププロセスは、リカバリブートローダーにすでに存在していますが、バックアップを復元するためのシステムの準備には適していません。

コンテンツは、サードパーティ製オープンソース製品である gocryptfs を使用して暗号化されます。

（注）	パフォーマンス上の理由から、ファイル名の暗号化は無効になっています。Threat Grid 内のサンプルとその他のコンテンツは、どのような状況でも元の名前では保存されないため、顧客の所有データが漏洩することはありません。

ご使用の前に、ドキュメントをよくお読みいただくことを強くお勧めします。バックアップの機能に関する詳細ドキュメントを入手できます。使用する前によくお読みいただくことを強くお勧めします。追加の技術情報と手順については、Cisco.com で『Threat Grid Appliance Backup Notes and FAQ』と『Cisco Threat Grid Appliance Setup and Configuration Guide』を参照してください。

NFS バックアップストレージへの暗号化されたバックアップを実現するには、次の NFS 要件を満たす必要があります。

• Threat Grid アプライアンス管理インターフェイスからアクセス可能な TCP 経由の NFSv4 プロトコルを実行している必要があります。

• 設定されたディレクトリは、nfsnobody（UID 65534）によって書き込み可能である必要があります。

• NFSv4 サーバは、10 GB 管理インターフェイス経由でアクセス可能である必要があります。

• 十分なストレージが使用可能である必要があります（「バックアップストレージの要件」を参照）。

• 次のマウントパラメータが無条件で使用されます。rw、sync、nfsvers=4、nofail

  （注）	これらのパラメータを手動で入力する必要はありません。これらと競合するパラメータを手動で入力することがサポートされないのは明白で、未定義の動作が発生する可能性があります。

• 無効な NFS 設定（または誤って設定された NFS サーバへのサービスをポイントした設定）の結果として、多くの場合、設定を適用するプロセスに失敗します。OpAdmin でのこの設定を修正して再適用すると成功します。

• nfsnobody による書き込みへのファイルの公開は安全です。nfsnobody または nfsnobody として実行されている Threat Grid アプライアンスでの唯一のプロセスは、データの暗号化に関するプロセスです。プレーンテキストデータは、最小権限の原則に基づいて、さまざまなサブツリーの個別のユーザアカウントで公開されます。アプライアンス上の PostgreSQL サービスは、Elasticsearch データやフリーザにアクセスできません。Elasticsearch サービスは、PostgreSQL やフリーザデータにアクセスできません。

• nfsnobody アカウントを使用すると、設定が簡素化され、カスタマーサイトごとに idmap.conf を構築する必要がなくなり、ローカルとリモートのアカウント名が一緒にマッピングされます。

Threat Grid アプライアンス（v2.7 以降）では、プライマリファイルシステムとして XFS が使用されます。リセットされていない古いアプライアンスで使用されていた ZFS ファイルシステムは使用されません。この変更は、特に記載されている場合を除き、既存のアプライアンスには影響しません（「データリセットプロセス」を参照）。

バックアップストアに合計で 5.6 TB を超えるストレージは必要ありません。バックアップ ストアは、次のコンポーネントで構成されています。

• オブジェクトストア：通常、使用されるストレージの大部分を占めています。バックアップストアの一括コンポーネントでのデータ保持は、使用中の Threat Grid アプライアンスリリース向けに文書化されたものと同じポリシーと制限に従っており、このコンポーネントの最大ストレージ使用量は 4.1 TB です。『Threat Grid Appliance Data Retention Notes』を参照してください。

• PostgreSQL データベースストア：PostgreSQL ストアの 2 つの完全バックアップと、保持されている完全バックアップのうち一番古いものから再生するのに十分な一連の WAL ログが含まれます。合計 500 GB 未満にする必要があります。

• Elasticsearch スナップショットストア：合計 1 TB 未満にする必要があります。

次のバックアップで予想される成果を考慮する必要があります。

バックアップの際、次のようにデータが保持されます。

• PostgreSQL：最後の 2 つの正常なバックアップと、それらのバックアップ以降のすべての WAL セグメントが保持されます。

• Elasticsearch：最新の 5 分ごとのスナップショット 2 回分が保持されます。

• バルクストレージ：単一の Threat Grid アプライアンス向けに使用され文書化されるものと同じ保持ポリシーが、共有ストアに対して使用されます。

長期間にわたって履歴データを保持する場合は、ファイルシステムレイヤまたはブロックレイヤのスナップショットをサポートする NFS サーバを使用することを強くお勧めします。

データベースのベースバックアップは、新しいベースバックアップが正常に作成されるまで保持されます。

（注）

バルクストレージでの障害発生後のリセット時に使用するため、仮想マシンイメージのバックアップコピーが RAID-1 ストレージアレイ上に作成されます。初期の Cisco Threat Grid アプライアンスモデル（UCS C220-M3 プラットフォームをベースとする）は、後のモデルよりもストレージが小さく、Threat Grid アプライアンス v2.9 のインストール後に、他のユニットが使用できる空き容量が、RAID-1 ファイルシステムのディスク容量の 25 % 未満になる可能性が高くなります。その場合、サービス通知がトリガーされます。 後のモデルのハードウェアで、v2.9 リリースのインストール後に、RAID-1 アレイの空きストレージが 25 % 未満になる場合、これは正常な状態ではないため、カスタマーサポートに問い合わせる必要があります。

アプライアンスを復元ターゲットとして使用する前に、事前設定された状態にする必要があります。アプライアンスは、この状態で出荷されます。ただし、設定した後に事前設定された状態に戻すには、明示的な管理操作が必要になります。

注意	このプロセスを実行すると、お客様が所有するデータが破棄されます。タスクを実行する前にすべてのマニュアルを読み、慎重に作業を続行してください。.

（注）	リセットは、リカバリモードで使用できるセキュアワイプと同じものではありません。DLP 再イメージ化センターに発送する前に、お客様が所有するデータをマシンから完全に削除するのに適しているのは、リカバリモードでのセキュアワイプのみです。ただし、リカバリモードでのセキュアワイプは、リセットに代わるものではありません。セキュアワイプでは、再イメージ化されるまで使用できなくなるアプライアンスが処理され、リセットでは、アプライアンスがバックアップを復元する準備が行われます。

バックアッププロセス中に、次のサービス通知が表示される場合があります。

• 「Network storage not mounted（ネットワークストレージがマウントされていません）」：バックエンドとして使用されているネットワーク ファイル システムが完全に動作していることを確認して、OpAdmin で設定を再適用するか、アプライアンスを再起動します。

• 「Network storage not working（ネットワークストレージが動作していません）」：バックエンドとして使用されているネットワーク ファイル システムが完全に動作していることを確認します。システムが NFS サーバの問題の修正から 15 分以内に回復しない場合は、アプライアンスを再起動してください。

• 「Backup file system access failure（バックアップ ファイル システムのアクセスに失敗しました）」：カスタマーサポートまでお問い合わせください。

• PostgreSQL のバックアップが見つかりません：これは、バックアップ ストアが設定された時間内のポイントと（自動的に 24 時間サイクルで実行される）最初のベース バックアップが行われる時間内のポイント間で正常な状態です。これが完了するまで、バックアップ完了とは見なされず、復元することはできません。このメッセージが 48 時間を超えて続く場合または続く場合に限り、カスタマー サポートに連絡してください。

• 「Newest PostgreSQL base backup more than two days old（最新の PostgreSQL ベース バックアップは 3 日以上前です）」：システムが PostgreSQL の新しいベースバックアップの生成に成功していないことを示します。修正されない場合、（古くなりつつあるバックアップ ポイントから復元するために必要な書き込みの完全なチェーンを保持するための）バックアップ ストアでの使用が制限されなくなり、行われる復元に必要な処理時間が許容できる長さを超えます。カスタマー サポートに連絡してください。

• 「Backup Creation Messages（バックアップ作成メッセージ）」：バックアップの開始またはトリガーの際に検出されたエラーを反映しています。

• 非アクティブの ES バックアップ（作成）：Elasticsearch が開始して、バックアップ ストアが使用不可能であることを示します。この状態は、アプライアンスを再起動するか、（NFS と暗号化サービスが機能している場合）TGSH にログインして restart elasticsearch.service コマンドを実行することで改善できます。

• 「Backup Maintenance Messages（バックアップ メンテナンス メッセージ）」：以前に作成されたバックアップのステータスを確認する際に検出されたエラーを反映しています。

• 「ES Backup (Maintenance) snapshot (...) status FAILED（ES バックアップ（メンテナンス）スナップショット（...）のステータスが [FAILED] になっています）」：Elasticsearch データベースのバックアップの最近の更新で、インデックスが正常に書き込まれなかったことを示します。NFS サーバが機能していて空き領域があることを確認します。問題を特定できず、解決しない場合は、カスタマー サポートにお問い合わせください。

• 「ES Backup (Maintenance) snapshot (...) status INCOMPATIBLE（ES バックアップ（メンテナンス）スナップショット（...）のステータスが [INCOMPATIBLE] になっています）」：アプライアンスのアップグレードで新しいバージョンの Elasticsearch がインストールされた直後にのみ発生します。バックアップストアがアップグレードされて、新しいリリースとの互換性を持つようになるまで表示されます。この状態の間に障害が発生した場合、互換性のないバックアップからの復元には、カスタマーサービスの支援が必要になることがあります。

• 「ES Backup (Maintenance) snapshot (...) status PARTIAL（ES バックアップ（メンテナンス）スナップショット（...）のステータスが [PARTIAL] になっています）」：本文に次の 2 つのメッセージのうちのいずれかが含まれています。「No prior successful backups seen, so retaining（以前に成功したバックアップが見つからないため、そのまま保持します）」（バックアップは存在するものの部分的でしかない場合）。または「Prior successful backups exist, so removing（以前に成功したバックアップが存在するため、削除します）」（後で再試行するために部分的なバックアップを破棄しようとしている場合）。

• 「ES Backup (Maintenance) - Backup required (...) ms（ES バックアップ（メンテナンス）：バックアップに（...）分間かかります）」：バックアップに 60 秒を超える時間が必要な場合に発生します。これは必ずしもエラーとは限りません。Elasticsearch では定期的なメンテナンスを実行し、これがアイドル状態のシステムにも重要な書き込み負荷を発生させることがあります。ただし、これが負荷が少ない期間で一貫して発生する場合は、ストレージ パフォーマンスを調査するか、サポートが必要な場合はカスタマー サービスに連絡してください。

• 「ES Backup (Maintenance) - Unable to query Elasticsearch snapshot status（ES バックアップ（メンテナンス）：Elasticsearch スナップショット ステータスのクエリを実行できませんでした）」：Elasticsearch に接続できませんでした。この障害は、バックアップの作成が正常に開始された後に発生します。一般に、他のアプライアンスの障害と同時に発生するため、それらの問題の修復に重点を置く必要があります。アプライアンスが他の点では完全に機能しているときにこのエラーが発生し、自分では解決できない場合は、カスタマー サポートに問い合わせてください。