test

Solstice Backup 5.1 管理者ガイド

スケジュールされたバックアップの構成

この節では、自動的なグループバックアップとカスタマイズ可能なバックアップスケジュールなどの、Backup のスケジュールされたバックアップの機能を設定する方法について説明します。

バックアップグループの構成

Backup のバックアップグループを使うと、クライアントのバックアップの開始時刻を指定できます。クライアントセーブセットをバックアップグループに割り当てて、どのクライアントセーブセットをいつバックアップするかを指定できます。また、クライアントのセーブセットを複数のグループに割り当てることも可能です。

クライアントマシンの数が特に多い場合は、ネットワークトラフィックを軽減するために、開始時刻が異なる複数のグループを作成することを検討してください。たとえば、エンジニアリング部門のマシンを含むグループのバックアップを朝の 4 時に開始し、ネットワーク上のこの部門以外の全クライアントを含むグループのバックアップを真夜中に開始することもできます。

複数のグループを作成する場合は、サーバーの負荷が高くならないように、開始時刻をずらします。1 つのグループがバックアップを終える前に次のグループが開始することのないように、十分な間隔をあけてください。Backup は、先に開始したグループがすべて終了するまでは、次のグループのバックアップを開始しません。「例 : 大規模なクライアントファイルシステムのスケジュール」を参照してください。

グループを新たに作成するには

Backup にはいくつかの事前構成済みのグループがあります。これとは異なるグループ構成が必要な場合は、状況に合わせて新しいグループを作成できます。独自のグループをカスタマイズして作成し使用するには、次の操作を行います。

  1. 「Groups」リソースにグループを作成します。

  2. 「Pools」リソースで既存のプールを編集するか、新しいプールを作成します。「Groups」属性で新しく作成したグループを選択します。

  3. 「Clients」リソースで、グループに入れたいセーブセットを含んでいるクライアントマシンのクライアントリソースを編集または作成します。「Groups」属性で新しく作成したグループを選択します。

    注意 - 注意 -

    グループ名にはスペースは使用できません。

Backup によるバックアップグループの使用方法

各バックアップグループの中のクライアントセーブセットは、指定されたグループの開始時刻にスケジュールされたバックアップを自動的に開始します。個々のグループにどのクライアントを入れるかを決めるときに、クライアントのバックアップスケジュールを考慮することで、バックアップの負荷を調整できます (個々のクライアントがフルバックアップを行う日をずらすようにスケジュールを作成する方法については、「スケジュールの構成」を参照)。

図 3-1 に、Backup がバックアップグループを使って複数のクライアントセーブセットをバックアップする方法を示します。

図 3-1 Backup がグループを使って複数のクライアントをバックアップする方法

Graphic

この例では、Oak、Elm、および Fir の 3 つのクライアントマシンが、真夜中にスケジュールされたバックアップを自動的に開始する Weekly Full というグループに属しています。クライアント Oak は毎月曜日にすべてのセーブセットのフルバックアップを、その他の曜日には差分バックアップを行います。クライアント Elm は火曜日にすべてのセーブセットのフルバックアップを、その他の曜日には差分バックアップを行います。クライアント Fir は水曜日にすべてのセーブセットのフルバックアップを、その他の曜日には差分バックアップを行います。各クライアントはフルバックアップを別々の曜日に行うので、サーバーに過度な負荷がかかることはありません。

第 2 のグループ Accounting は、クライアントを部門ごとにグループ化する例を示しています。Accounting グループには、クライアントマシン Birch と Pine があり、経理部門のマシンがバックアップできるようになる 7:00 p.m. にバックアップを開始します。この 2 台のクライアントマシンは同じ曜日にフルバックアップを行いますが、Pine はセーブセット /usr/home だけをバックアップするようにスケジュールされているのに対し、マシン Birch ではすべてのセーブセットがバックアップされます。バックアップに要する時間を推定することで、次のグループの開始時刻をいつに設定すべきかがわかります。

各グループのセーブセットは、ストレージデバイスにマウントされている適切なボリュームに書き込まれます。Backup はボリュームのプールを使ってセーブセットの編成、追跡、および格納を行い、グループを使って各クライアントがスケジュールされたバックアップをいつ開始するかを指定します。

Backup のデフォルトグループ設定

Backup には「Default」という名前の事前構成済みのグループがあります。Backup は、すべてのデータがバックアップされるように、すべてのクライアントを自動的に「Default」グループに追加します。ただし、Backup でデフォルトグループをバックアップするためには、このグループを有効にする必要があります。各クライアントを、必要に応じてこの「Default」グループに残すことも、カスタマイズしたグループ (複数でもよい) に入れることもできます。

「Start Time」属性と「Autostart」属性は、重要です。「Default」グループの「Start Time」属性は、毎日のバックアップを 3:33 a.m. に開始するように設定されています。この「Start Time」属性は変更できます。「Default」グループに限らず、Backup にあるグループに対してスケジュールされたバックアップを実行するためには、そのグループの「Autostart」属性を有効にする必要があります。

「Client Retries」

Backup サーバーがクライアントに接続できない場合、「Groups」リソースの「Client Retries」属性で、サーバーがクライアントへの接続を試みる回数を指定します。この回数だけ再試行を行なった後は、接続は失敗したと見なされます。(少なくとも) すべてのクライアントに交信してから、最初の再試行が行われます。「Groups」リソースの「Inactivity Timeout」属性は、クライアント上でバックアップが確実に行われるまでの Backup サーバーの待機時間を分単位で指定します。サーバーがバックアップ実行情報を受け取らないまま、この属性で指定されている時間が経過すると、サーバーはそのセーブセットのバックアップ操作を放棄します。

注 -

放棄されたセーブセットのバックアップが終了していても、savegrp が自動的に作成するレポートには、バックアップが完了したとは報告されません。たとえば、クライアントがネットワークファイルシステム (Network Filesystem, NFS) 接続経由でバックアップ中に NFS サーバーがクラッシュしてリブートした場合、Backup のバックアップ処理はハングアップし、タイムアウトとなります。Backup サーバーはこのセーブセットを「放棄された」としてマークしますが、バックアップ操作は NFS サーバーが再起動した時点で続行され、完了します。

「Default」グループの事前構成済みの属性値については、「「Groups」リソース」で説明しています。「Default」グループの属性はいずれも変更できますが、このグループそのものは削除できません。ただし、グループは必要に応じていくつでも作成または削除できます。

グループスケジュールを使ってクライアントの通常のバックアップスケジュールを変更する方法

グループの「Level」属性と「Schedule」属性を使って、クライアントの通常のバックアップスケジュールを変更できます。たとえば、クライアントの通常のバックアップスケジュールとは関係なく、適切な日にグループ内のすべてのクライアントのフルバックアップを行うことが可能です。「Level」属性で指定したエントリは、グループ内の各クライアントのバックアップレベルの設定値よりも優先されます。

あるいは、複数のクライアントに、各クライアントの個々のスケジュールではなく、同じバックアップスケジュールをグループとして適用することもできます。複数のクライアントのグループに、個々のクライアントのスケジュールではなく、デフォルトのスケジュール (毎日曜日にフルバックアップ) を設定できます。グループの「Level」属性と「Schedule」属性が空白になっている (事前構成済みの設定値) と、クライアントは個々のバックアップスケジュールに従います。

グループバックアップの監視と管理

Backup 管理プログラムの「Group Control」ウィンドウを使うと、バックアップ中に、スケジュールされたグループを監視できます。「Group Control」機能、セーブグループ完了メッセージ、ブートストラップの出力、およびシステムコンソールログなどの機能によって、スケジュールされたバックアップの成否と、データの復旧に必要な情報が得られます。

「Group Control」機能は状態情報を提供するもので、、スケジュールされたバックアップグループのプレビュー、停止、および開始のためのコントロールが用意されています。

最も新しく開始されたバックアップグループに関しては、次のいずれかの状態情報が表示されます。

動作の監視

Backup 管理プログラムの「Group Control Details」機能を使うと、完了したグループバックアップに関する詳しい情報を表示できます。この機能を使って、どのクライアントセーブセットがバックアップに成功し、どのセーブセットが失敗したのかを知ることができます。

「Group Control Details」 ウィンドウは、バックアッププロセスにおけるクライアントセーブセットの状態を、次の 3 つのメッセージフィールドのいずれかに表示します。

「Group Control Preview」機能を使うと、特定のグループのバックアップのシミュレーションを行えます。この機能により、Backup がグループバックアップを実行する前に、どのような問題が起こりうるかを知ることができます。Backup 管理プログラムでバックアップグループのプレビューを行うには、「Group Control」ウィンドウを表示し、「Preview」ボタンをクリックします。バックアップグループをコマンド行からプレビューするには、Backup サーバーでスーパーユーザーになり、シェルプロンプトで savegrp -p group-name コマンドを入力します。

Backup は、完了したグループバックアップに関する過去の情報ではなく、次のスケジュールされたバックアップの際にグループのバックアップがどのように実行されるかという情報を表示します。

スケジュールされたバックアップグループをただちに開始する方法

スケジュールされたバックアップグループを必要に応じて手動で開始すると、Backup は次のスケジュールされたバックアップのレベル (フル、レベル [1〜9]、差分など) でバックアップを実行します。

グループバックアップをただちに開始するには、次の 2 つの方法があります。

「Start Now」コントロールを使用すると、Backup は「Groups」リソースでスケジュールされている開始時刻を無効にし、グループ内のクライアントのバックアップをただちに開始します。

スケジュールされたバックアップグループの停止と再開

「Group Control」ウィンドウで「Stop」をクリックすると、Backup は現在行われているセーブセットのバックアップを完了し、残りのセーブセットのスケジュールされたバックアップを停止し、「Group Control」 ウィンドウの「Status」フィールドに「Not Finished」と表示します。

「Group Control」ウィンドウで「Restart」をクリックすると、Backup はそのグループのスケジュールされたバックアップを再開し、「Status」フィールドに「Running」と表示します。

スケジュールされたバックアップの際のオープン状態のファイルの管理

スケジュールされたバックアップの過程で、クライアントがオープンしているファイルが変更された場合、変更前バージョンのファイルがバックアップされ、これらのファイルが変更中であることが通知されます。「Group Control Details」ウィンドウには、次のような警告メッセージが表示されます。


warning: file filename changed during save

ファイルに対して行われた変更内容はバックアップされません。変更されたファイルをバックアップするには、バックアップグループを再起動するか、あるいは次のスケジュールされたバックアップの際に Backup でクライアントをバックアップします。

セーブグループ完了メッセージ

バックアップが完了すると、Backup はスケジュールされたバックアップが正常に終了した旨のレポートを出力します。Backup はスーパーユーザーに対して自動的に通知を送信し、Backup 管理プログラムにも同じ情報を表示します。

ブートストラップの生成と出力

バックアップグループに Backup サーバーからのデータが含まれていると、Backup は、サーバーファイルインデックス、メディアデータベース、および構成ファイルを含む、ブートストラップと呼ばれる特別なセーブセットを生成します。ブートストラップ情報は障害復旧に必須です。デフォルトでは、ブートストラップは Backup サーバーのデフォルトプリンタを使って印刷されます。デフォルトプリンタを変更するには、「Groups」リソースの「Printer」属性を変更します。

このブートストラップの出力は、サーバーを含むグループに対するスケジュールされたバックアップの際に、あるいはそのサーバーがアクティブグループに属していなければ、他のスケジュールされたバックアップのあとに作成されます。ブートストラップの出力は、スケジュールされたバックアップが自動的に開始された場合も、手動で開始された場合も生成されます。

ブートストラップをファイルに保存するには

ブートストラップは、ファイルに保存したり、1 つまたは複数のユーザー ID に対して電子メールで送信したりできます。

  1. nwadmin を実行し、「Customize」メニューで「Notifications」を選択します。

  2. 「Bootstrap」を選択します。

    「Action」属性が表示されます。


    /usr/bin/lp -s -c -t bootstrap -d%PRINTER

  3. ファイルを保存するには、これを次のように変更します。


    /bin/cat >> /directory/filename

  4. ブートストラップファイルを複数のユーザー ID に電子メールで送信するには、この行を次のように変更します。


    /usr/ucb/Mail -s "nwserver bootstrap" user-name@corp.com

システムコンソールログ

UNIX システムログには Backup から渡されたメッセージが表示されます。Backup をインストールすると、構成ログファイル (syslog.conf) に、システムログ機能がどのファイルやユーザーに、どのタイプの通知を行うかを指示する行が追加されます。次に例を示します。


daemon.notice                   /dev/console
daemon.notice                   /nsr/logs/messages
daemon.notice                   operator
local0.notice                   /nsr/logs/summary
local0.alert                    root, operator

スケジュールの構成

Backup サーバーは、各クライアントに割り当てられているバックアップスケジュールに基づいて、ネットワーク上の各クライアントシステムのバックアップされるデータの量を判断します。これらのスケジュールは、ユーザーの環境に応じて、単純にも、複雑にもなります。すべてのクライアントが同じスケジュールを共有することも、各クライアントが独自のスケジュールを持つこともあります。「Schedules」リソースを使用して独自のスケジュールを作成し、「Clients」リソースを使ってこのスケジュールをクライアントセーブセットに適用してください。「Clients」リソースとクライアント構成の詳細は、第 5 章「Backup クライアントの操作」を参照してください。

Backup によるバックアップスケジュールの使用方法

Backup は、クライアントのバックアップスケジュールを使用して、指定されたセーブセットに対して、特定の日に、どのレベルのバックアップ操作を行うべきかを決定します。バックアップ操作が開始される日付は、そのクライアントセーブセットが関連付けられている「Group」リソースに割り当てられている「Start Time」属性によって決まります。

Backup は 4 つのタイプのバックアップレベルをサポートしています。

(バックアップレベルの詳細は、「バックアップレベル」を参照してください)。

「Schedules」リソースを使うと、必要に応じてバックアップスケジュールをカスタマイズできます。たとえば、一部のクライアントに対しては、3 日おきに「フル」のレベルでバックアップを行い、それ以外の日は差分バックアップを行います。その他の、重要性が低いデータを含んでいるクライアントに対しては、1 か月に 1 回だけフルバックアップを行い、それ以外の日には差分バックアップか、レベル 1〜9 のバックアップを行います。

フルバックアップから次のフルバックアップまでの期間は「バックアップサイクル」と呼ばれます。図 3-2 は、1 週間のバックアップサイクルを示しています。この例では、毎日曜日にクライアントのフルバックアップを行い、その他の曜日には差分バックアップを行なっています。

図 3-2 バックアップサイクルが 1 週間の場合

Graphic

バックアップスケジュールを使って、Backup サーバーの負荷を調整し、分散させることができます。ネットワークの大きさによっては、すべてのクライアントに同じスケジュールを適用できます。たとえば、すべての社員が休んでいる休日にフルバックアップを行う場合は、すべてのクライアントにデフォルトのスケジュールを適用できます。デフォルトのスケジュールでは、日曜日にフルバックアップを行い、それ以外の曜日には差分バックアップを行います。図 3-3 は、クライアント A、クライアント B、およびクライアント C の 3 つのクライアントでの、デフォルトのスケジュールの例を示しています。

図 3-3 複数のクライアントで Backup のデフォルトのスケジュールを使用する場合

Graphic

フルバックアップに長時間かかる場合には、バックアップを分散させることができます。たとえば、クライアント A のフルバックアップを日曜日に行うスケジュール、クライアント B のフルバックアップを火曜日に行うスケジュール、そしてクライアント C のフルバックアップを木曜日に行うスケジュールを設定します。図 3-4は、複数のクライアントでバックアップスケジュールを分散させる方法を示しています。

図 3-4 複数のクライアントのスケジュールを 1 週間に分散させる場合

Graphic

Backup サーバーの負荷を調整し、分散させると、サーバーの効率が向上します。また、クライアントのグループごとに異なる開始時刻を指定することも、サーバーの効率向上に役立ちます。

バックアップスケジュール

Backup では、独自のバックアップスケジュールを簡単に設定できます。ただし、自分の環境に最も適したバックアップスケジュールを決めるためには、慎重に画を立てる必要があります。

バックアップスケジュールを作成するときには、次の事柄を検討します。

さらに、ファイルの復旧に関するポリシーを決定する必要があります。たとえば、ユーザーが、少なくとも 3 か月の間に失われたファイルを復旧する場合 (3 か月の保持ポリシー) には、メディアデータベースの中にすべてのセーブセットを 3 か月間保存する必要があります。一方、過去 1 か月のデータを復旧するだけでよいのであれば、レベル 1〜9 バックアップを使って、保存しなければならないボリュームの量を減らすことができます。

Backup が復旧に使用するデータが保存されている期間は、各クライアントに関連付けられているブラウズポリシーと保持ポリシーによって決まります。Backup がデータライフサイクルをどのように管理するかについては、「ブラウズポリシーと保持ポリシーによるデータライフサイクルの管理方法」を参照してください。

例 : 大規模なクライアントファイルシステムのスケジュール

400 KB/秒という平均的なバックアップ速度では、10G バイトのデータを持つクライアントのフルバックアップには、終了までに約 5.5 時間必要となります。このようにバックアップに要する時間が長いクライアントセーブセットでは、毎回フルバックアップを行うスケジュールは不適当です。

この場合には、クライアントのディスクボリュームを複数のバックアップグループに分割し、それぞれ別のタイミングでバックアップするようにスケジュールを立てます。1 台のクライアントのセーブセットを複数のバックアップグループに分割すると、クライアントのすべてのファイルが何回かに分けてバックアップされることになります。これはすべてのローカルデータを一回でフルバックアップするよりも時間の節約になります。

クライアントのファイルシステムを個別にバックアップするには、「Clients」リソースに個々のファイルシステムをアドレス指定して、同じクライアントのエントリの追加と構成を繰り返します。たとえば、ファイルシステム /usr のバックアップについては、あるグループのバックアップスケジュールを使って第 1 のクライアントリソースを構成します。さらに、別のファイルシステム /var のバックアップスケジュールについては、別のグループで別のバックアップスケジュールを使って第 2 のクライアントリソースを構成します。

注意 - 注意 -

複数のバックアップスケジュールを作成し、セーブセットを明示的に指定すると、その指定リストに含まれていないファイルやファイルシステムはバックアップから除外されます。これには、システムに新たに追加されたディスクボリュームも含まれます。「Save Set」属性に特別な値「All」を指定すれば、このような危険は生じません。Backup は新しいディスクボリュームを自動的にバックアップに追加します。

スケジュール構成属性

カスタマイズしたバックアップスケジュールを作成するには、「Schedule」リソースで次のスケジュール構成値を定義する必要があります。

バックアップスケジュールの構成の順序

独自にカスタマイズしたスケジュールを使用する場合には、スケジュールを構成したあとに、「Clients」リソースの中のクライアントまたはセーブセットと関連付ける必要があります。毎日自動的に行われるスケジュールされたバックアップの開始時刻は、クライアントセーブセットが関連付けられているバックアップグループによって決まります。データがブラウズまたは復旧に使用できる期間は、スケジュールではなく、クライアントのセーブセットに対して構成されているブラウズポリシーと保持ポリシーによって決まります。

バックアップレベル

フルバックアップを毎日行うのは現実的または効率的でない場合があるので、Backup では、その自動的に実行されるスケジュールされたグループバックアップの際のバックアップ操作のレベルを指定できるようになっています。フルバックアップが行われる回数を制限することで、サーバーの効率を損なわずに、データを保護できます。各種のバックアップレベルを使って、バックアップの完了に必要なボリュームの数および時間と、ディスククラッシュからの復旧に必要なボリュームの数および時間を調整できます。

Backup は、ファイルシステムデータに関して、次の 4 種類のバックアップレベルをサポートしています。

Backup によるバックアップレベルの使用方法

バックアップスケジュールによって、バックアップサイクル中の指定した日に、どのレベルのバックアップが行われるかを定義します。これらのバックアップレベルを 1 つ以上組み合わせて、バックアップスケジュールをカスタマイズできます。カスタマイズしたスケジュールの中でバックアップレベルの使用を検討している場合には、次のことに注意して、自分の環境に合ったスケジュールを作ってください。

注意 - 注意 -

オンラインクライアントファイルインデックス、サーバーインデックス、およびメディアデータベースは、Backup サーバーがバックアップされるたびにバックアップされます。一般に、これはサーバーのバックアップレベルに準拠します。たとえば、Backup サーバーのバックアップレベルが「フル」ならば、オンラインクライアントファイルインデックス、サーバーインデックス、およびメディアデータベースもフルバックアップが行われます。Backup サーバーのバックアップが「レベル 5」ならば、オンラインクライアントファイルインデックス、サーバーインデックス、およびメディアデータベースのバックアップもレベル 5 です。ただし、サーバーのバックアップレベルが「差分」ならば、オンラインクライアントファイルインデックス、サーバーインデックス、およびメディアデータベースのバックアップはレベル 9 です。

バックアップレベルによる動作

バックアップレベルはクライアントのバックアップスケジュールと関連しています。バックアップレベルの定義は、ディスククラッシュからの復旧に要する時間や、必要となるバックアップボリュームの数などに直接に影響します。

これ以降の説明では、バックアップレベルの動作と、データの損失時の復旧に必要となるデータの量を、図示しています。

10 月 2 日にフルバックアップが行われます。10 月 3 日には、フルバックアップ以降に変更されたすべてのデータが差分バックアップによって保存されます。10 月 4 日には、10 月 3 日以降に変更されたすべてのデータが差分バックアップによって保存されます。10 月 5 日には、レベル 7 バックアップによって、フルバックアップ以降に変更されたすべてのデータが保存されます。10 月 5 日にディスククラッシュから完全に復旧するためには、フルバックアップのボリュームとレベル 7 のボリュームの 2 つのボリュームだけが必要です。10 月 3 日と 4 日のボリュームに入っているデータは、レベル 7 バックアップに含まれているので、これらのボリュームは不要です (図 3-5 を参照)。

図 3-5 例 : 10 月 2 日から 10 月 8 日までのバックアップ

Graphic

10 月 6、7、および 8 日は、レベル 7 バックアップ以降に変更されたすべてのデータが差分バックアップによって保存されます。10 月 9 日には、図 3-6 に示すように、レベル 5 バックアップによって、フルバックアップ以降に変更されたすべてのデータが保存されます。10 月 9 日にディスククラッシュから完全に復旧するためには、フルバックアップのボリュームとレベル 5 のボリュームの 2 つのボリュームだけが必要です。レベル 7 バックアップのボリュームと、それ以降の差分バックアップのボリュームに入っているデータは、レベル 5 のボリュームに含まれているので、これらのボリュームは不要です。

図 3-6 例 : 10 月 2 日から 10 月 15 日までのバックアップ

Graphic

10 月 12 日に、レベル 7 バックアップによって、これよりも若い番号の直前のバックアップ以降に変更されたすべてのデータがバックアップされます。この例では 10 月 9 日のレベル 5 バックアップがこれに該当します。10 月 12 日にディスククラッシュから復旧するためには、フルバックアップのボリューム、レベル 5 のボリューム、および新しいレベル 7 のボリュームの 3 つのボリュームが必要となります (図 3-6 を参照)。

10 月 16 日に、レベル 5 バックアップによって、これよりも若い番号の直前のバックアップ以降に変更されたすべてのデータがバックアップされます。これよりも若い番号 (レベル 1 〜 4) のバックアップは行われていないので、レベル 5 バックアップによって、フルバックアップ以降に変更されたすべてのデータがバックアップされます。10 月 16 日にディスククラッシュから復旧するためには、フルバックアップのボリュームと新しいレベル 5 のボリュームの 2 つのボリュームが必要となります (図 3-7 を参照)。

図 3-7 例 : 10 月 2 日から 10 月 16 日までのバックアップ

Graphic

レベル 1-9 バックアップを使うことで、使用しなければならないボリュームの数を制御できます。バックアップ方法を慎重に計画することで、ボリュームの数を最小限に抑えながら、すべてのデータをディスクに復旧することが可能になります。ディスククラッシュからの復旧に必要なボリュームの数が少ないほど、ディスクの復旧に費やされる時間も削減できます。

また、バックアップのデータを圧縮し、不要なデータを削除するディレクティブを使うことで、データのバックアップに要する容量と時間を制御できます。たとえば、バックアップの実行時に、特定のファイルまたはファイルシステムを省略するよう Backup に指示できます。ディレクティブの詳細は、「ディレクティブとは」を参照してください。