復元操作は、選択した構成のバックアップを取得し、対応するすべてのシステム設定を変更してバックアップに反映します (バックアップ時には存在しなかった構成要素を削除するなど)。管理者は復元を計画する際に、次のガイドラインに従う必要があります。
クロスプラットフォーム復元: 1 つのアプライアンスプラットフォームからバックアップされた構成を別のアプライアンスプラットフォームに復元することはできません。たとえば、ZS4-4 構成のバックアップを ZS3-2 アプライアンスに復元することはできません。構成を別のプラットフォームに復元しようとすると、通常の状態に戻すために出荷時リセットが必要となるいくつかの障害が発生します。
定期的な停止時間 - 復元プロセスは完了までに数分かかり、アクティブなネットワーク構成およびデータプロトコルが再構成されると、クライアントへのサービスが影響を受けます。そのため、構成の復元は開発システム上でのみ、またはスケジュールされた停止時間中にのみ使用するようにしてください。
サービスの中断 - クライアントが NFS などのデータプロトコルを使ってシステム上のデータにアクセスすると、ネットワークが再構成されてサービスが再起動するときに、サービスの中断が発生します。選択されたバックアップコピーが、管理者によってサービスが無効にされていたときに取得された場合は、その設定が復元されるため、そのプロトコルのクライアントセッションは終了します。
セッションの中断 - 復元が Web ブラウザから開始された場合は、ネットワークが再構成されると、その Web ブラウザセッションも復元プロセス中に切断されます。復元された構成に現在のブラウザ接続で使用されているものと同じルーティングおよびネットワークアドレス設定が含まれていない場合や、ブラウザが DHCP で管理されているネットワークアドレスに接続されている場合は、ブラウザセッションが復元中に中断されます。復元プロセスはバックグラウンドで完了しますが、続行するにはリロードするか、またはブラウザに新しい、復元されたネットワークアドレスを指定する必要があります。このため、複雑な構成の復元は、CLI を使用してサービスプロセッサのシリアルコンソールから開始することが望ましい場合があります。
クラスタ化解除、復元、および再クラスタ化 - クラスタに参加しているアプライアンスの構成のバックアップが開始される場合がありますが、システムがクラスタ化されている間は構成の復元は使用されない可能性があります。クラスタ化プロセスでは、クラスタピア間で設定が同期化される一方、各ピアアプライアンスはプライベート設定も保持しています。このため、最初に 2 つのシステムをクラスタ化解除する必要があります。データ損失の可能性があるため、クラスタ化の構成を解除する場合は Oracle サポートに連絡してください。次に、選択されたヘッド上で構成バックアップを復元してから、2 つのシステムを再クラスタ化します。この時点で、もう一方のシステムが復元された構成で自身を自動的に同期化します。
root 権限が必要 - 構成のバックアップにはすべてのシステムメタデータが含まれているため、作成または適用するための権限および承認がすべて必要です。したがって、ほかの委任管理オプションとは異なり、root ユーザーのみが構成のバックアップまたは復元の実行を承認されています。
新規機能の設定の確認 - システム更新を新規バージョンのアプライアンスソフトウェアに適用する前に保存された構成を復元することが許可されています。場合によっては、バックアップの時点で存在していたサービスやプロパティーの効果が異なっていたり、新しいソフトウェアに、バックアップの時点では存在しなかった新しいサービスやプロパティーが存在したりすることがあります。システム更新プロセスと同様に、構成の復元プロセスでは、適用可能な設定を転送し、バックアップの時点では存在しなかったプロパティーに妥当なデフォルト値を適用するためにあらゆる努力を行います。ソフトウェアバージョンをまたがって復元する場合、管理者は復元のあと、新機能のための設定を手動で確認するようにしてください。
パスワードの保持 - root パスワードは変更されたり、バックアップ時と異なる場合でも元に戻されたりしません。現在の root パスワードは、復元のあともシステム上に保持されます。パスワードについての詳細は、セキュリティーに関する注意のサマリーを参照してください。