test

Sun Java System Calendar Server 6.3 管理ガイド

第 9 章 自動バックアップ (csstored) の設定

設定時に、自動バックアップを有効にすることができます。ただし、自動バックアップは設定後にいつでも有効または無効にすることができます。データを保護し、運用停止時間を最小限に抑えるためには、すぐれたバックアップシステムの導入が不可欠です。

この章では、自動バックアップが実行されるように Calendar Server サービス csstored を設定する方法について説明します。

注 –

ここで説明する自動バックアッププロセスを使用しない場合は、独自のバックアップ計画を導入してデータを保護する必要があります。データを保護するためのほかの Calendar Server ツールの使用方法については、第 17 章「Calendar Server データのバックアップと復元」を参照してください。

csstored の概要については、『Sun Java Communications Suite 5 配備計画ガイド』を参照してください。

9.1 Calendar Server ストアサービス (csstored) の有効化

ストアサービスは、ics.conf ファイルで有効にする必要があります。次の ics. conf ファイルパラメータを "yes" に設定して、ストアサービスが有効になっていることを確認します。

local.store.enable

このパラメータが "yes" に設定されている場合、ストアにアクセスする各サービスは、正常に行われたストアサービスの起動によって異なります。

9.2 Calendar Server 6.3 システムでの自動バックアップの概要

この節では、Calendar Server システムで自動バックアップを実装する方法の概要について説明します。

この節の内容は、次のとおりです。

9.2.1 Calendar Server 6.3 システムでの自動バックアップの機能

Calendar Server システムでは、カレンダデータベースの各トランザクション (カレンダやそのプロパティーへの追加、変更、または削除) をトランザクションログファイルに記録します。あらかじめ決められた間隔で、このログファイルは書き込みのために閉じて、別のログファイルが作成されます。次に、システムでは、時間があるときに、もっとも古い閉じたトランザクションログのトランザクションを実際のカレンダデータベースに適用します。ログに含まれているすべてのトランザクションがデータベースに適用されると、そのログには「適用済み」というマークが付けられます。

ホットバックアップが設定されている場合、実際のデータベースのスナップショットが 24 時間ごとに取得されます。適用済みのログは、その後、データベースのホットバックアップのコピーに適用されます。ホットバックアップデータベースは、まだ適用されていないトランザクションを除いては最新の状態です。

9.2.2 Calendar Server 6.3 システムでのバックアップに対する csstored の機能

起動時に開始される Calendar Server サービスの 1 つに csstored があります。このサービスを設定すると、カレンダデータベースの自動バックアップ (ホットバックアップかアーカイブバックアップのどちらか、またはその両方) が実行されます。

csstored の自動バックアップ用の設定は、設定プログラム csconfigurator.sh を実行するときに行うことができます。その時点で自動バックアップのどちらかまたは両方を選択した場合は、これ以上の設定手順は必要ありません。

csstored が無効の場合、データベースにアクセスするその他のデーモンは機能しません。csstored デーモンは、データベースに必要なその他のタスクを実行します。このため、デーモンは無効にしないでください。

注 –

自動バックアップが無効になっているときは、循環ログの ics.conf パラメータである caldb.berkeley.circularlogging を "yes" に設定することをお勧めします。これにより、古いデータベーストランザクションログが破棄されるため、ディスク容量を節約できます。

9.2.3 Calendar Server 6.3 システムでの循環バックアップの機能

自動バックアップが有効になっている場合、csstored は、循環バックアップシステムを使用してバックアップデータベースファイルで保持されるバックアップコピーの数を自動的に管理します。

csstored は、バックアップコピーがその最大数まで蓄積されるか、許容される最大ディスク容量に達するまで、バックアップをバックアップデータベースディレクトリに格納します。どちらかの上限に達すると、保持されるコピー数が最小数になり、ディスク容量がしきい値を下回るまで、バックアップコピーは古いものから先に破棄されます。

循環バックアップの制御には、1 組の ics.conf パラメータが使用されます。これらのパラメータにはデフォルト値が用意されているため、特にカスタマイズは必要ありません。システム内でのバックアップの動作方法を調整する場合は、「21.7 自動バックアップの調整」を参照してください。

9.2.4 自動バックアップを有効にするための高レベルの手順

設定ファイルの実行時に自動バックアップを設定していなかった場合は、後で設定できます。この節には、設定プログラムの実行後、Calendar Server 6.3 システムで自動バックアップを有効にするために必要な高レベルの手順のリストを掲載しています。

高レベルの作業は、次のとおりです。

9.3 Calendar Server 6.3 のバックアップのためのトランザクションログファイルの設定

この節では、トランザクションログファイルの設定の概要と方法の両方を説明します。

この節の内容は、次のとおりです。

9.3.1 Calendar Server 6.3 のバックアップのためのトランザクションログファイルについて

トランザクションログファイルは、Calendar Server で最後のスナップショット以降にカレンダデータベースに対して行われた追加、変更、および削除をすべて取り込むために使用されます。トランザクションは実際には、ログファイルが書き込みのために閉じるまで、ライブデータベースに適用されることはありません。間隔を表すパラメータは、古いログファイルを閉じて、新しいログファイルを作成する頻度を指定します。

ログファイル名は、設定可能な名前の末尾に一意の番号を付けて表します。

ログファイルが閉じると、ライブデータベースにいつでも適用できます。ライブデータベースへの適用は非同期的に行われます。つまり、ログファイルの作成とそのファイルへのトランザクションの書き込みが「リアルタイム」で行われる一方で、トランザクションをデータベースに適用するプログラムが、ログファイルへのトランザクションの書き込みに関係なく単独で実行されます。システムがビジー状態の場合は、データベースへの適用を待機するログファイルの数が増加する可能性があります。システムに余力があるときは、トランザクションを適用するプログラムが遅れを「取り戻し」、実際にはアイドル状態で次のトランザクションログを待機していることもあります。

トランザクションは、ライブデータベースに適用されたあと、ホットバックアップのスナップショット (有効な場合) に適用されます。また、ログファイルはスナップショットが格納されているディレクトリと同じアーカイブディレクトリに書き込まれます。

Procedureトランザクションログファイルを設定するには

  1. コマンド行で、ics.conf が格納されているディレクトリに移動します。

    cd /etc/opt/SUNWics5/config

  2. トランザクションログ名を指定します。

    logfile.store.logname=storename.log

  3. トランザクションログディレクトリのディレクトリパスを指定します。

    デフォルトの値は、次のとおりです。logfile.logdir="logs"

  4. ics.conf ファイルの編集が終わったら、Calendar Server を再起動します。

    cal-svr-base/SUNWics5/cal/sbin/start-cal

9.4 Calendar Server 管理者の電子メールアドレスの指定

この節では、Calendar Server 管理者の電子メールアドレスの設定の概要と方法について説明します。

この節の内容は、次のとおりです。

9.4.1 管理者に送信される電子メールメッセージ

なんらかのイベントまたはエラーが発生すると、電子メールによって管理者に通知します。

電子メールメッセージが生成されるイベントは次のとおりです。

ProcedureCalendar Server 6.3 システム管理者の電子メールアドレスを設定するには

  1. 設定を変更する権限を持つ管理者としてログインします。

  2. stop-cal コマンドを発行して Calendar Server サービスを停止します。

  3. /etc/opt/SUNWics5/cal/config ディレクトリに移動します。

  4. 古い ics.conf ファイルをコピーして名前を変更し、保存します。

  5. 次の ics.conf パラメータを編集して、管理者の電子メールアドレスを指定します。

    alarm.msgalarmnoticercpt="admin@email_address "

  6. ファイルを ics.conf として保存します。

  7. Calendar Server を再起動します。

    cal-svr-base/SUNWics5/cal/sbin/start-cal

9.5 Calendar Server 6.3 データベースのホットバックアップの有効化

この節では、設定プログラムの実行時にホットバックアップを設定していなかった場合の、Calendar Server 6.3 データベースのホットバックアップの有効化の概要と方法について説明します。

この節の内容は、次のとおりです。

9.5.1 Calendar Server バージョン 6.3 のホットバックアップとは

ホットバックアップは、現在書き込み中のトランザクションログを除くすべてのトランザクションログが適用されている最新のスナップショットで構成されていることが理想的です。しかし、システムのビジー状態によっては、トランザクションログの適用が遅れることがあります。このため、データベースにもホットバックアップにも適用されていないログファイルがいくつか存在する可能性があります。

このようにライブデータベースと「ほぼ同じ内容」にするのは、なんらかの大惨事が発生した場合やデータベースの破損が見つかった場合に停止時間とデータの損失を最小限に抑えるためです。

新しいホットバックアップは、24 時間ごとに新しいスナップショットが取得されるときに開始されます。古いホットバックアップは検証され、破棄されるまで保存されます。詳細は、「9.2.3 Calendar Server 6.3 システムでの循環バックアップの機能」を参照してください。

ProcedureCalendar Server 6.3 システムのホットバックアップを有効にするには

  1. 設定を変更する権限を持つ管理者としてログインします。

  2. stop-cal コマンドを発行して Calendar Server サービスを停止します。

  3. コマンド行で、ics.conf が格納されているディレクトリに移動します。

    cd /etc/opt/SUNWics5/config

  4. 次の ics.conf パラメータを "yes" に設定して、ホットバックアップを有効にします。

    caldb.berkeleydb.hotbackup.enable="yes"

  5. ホットバックアップディレクトリのディレクトリパスを指定します。

    caldb.berkeleydb.hotbackup.path=
   /var/opt/SUNWics5/hotbackup_directory

    Calendar Server のデフォルトのホットバックアップディレクトリは、Solaris の場合は /var/opt/SUNWics5/csdb、Linux の場合は /var/opt/sun/calendar/csdb です。csdb ディレクトリは Communications Suite インストーラが認識できる便利なサブディレクトリであるため、このインストーラはデフォルトでアーカイブやホットバックアップディレクトリをこのディレクトリに置きます。

    注 –

    サイズの問題により、Calendar Server 管理者はアーカイブやホットバックアップを csdb ディレクトリ以外のディスク、ボリューム、またはパーティションに置くことを強くお勧めします。

    アーカイブおよびホットバックアップのディレクトリの数は設定可能です。このため、アーカイブとホットバックアップにそれぞれ 6 つのディレクトリを選択した場合、csdb ディレクトリには、ライブデータベースのコピーが 6 + 6 + 1 個できます。csstored ユーティリティーは、csdb のある物理ディスクと csdb ディレクトリのコンテンツのサイズに基づいて、必要なアーカイブとホットバックアップのサイズを計算します。

    アーカイブとホットバックアップのディレクトリは、使いやすいようにデフォルトで csdb ディレクトリ内にインストールされます。しかし、実際の配備では、csdb の外のディレクトリに配置してください。

    一次ディスクドライブにハードウェア障害が発生した場合に備えて、ホットバックアップを別のディスクまたはディスクサブシステムで行うこともできます。こうすることにより、一次ドライブまたはサブシステム上で発生する I/O の競合も減少する場合があります。

    高可用性 (HA) の設定を行なっている場合は、このパスを共有ストレージ (/global/cal/) のサブディレクトリとして指定します。第 6 章「Calendar Server 6.3 ソフトウェアでの高可用性 (フェイルオーバーサービス) の設定」も参照してください。

  6. ics.conf ファイルの編集が終わったら、Calendar Server を再起動します。

    cal-svr-base/SUNWics5/cal/sbin/start-cal

9.6 Calendar Server 6.3 データベースのアーカイブバックアップの有効化

この節では、設定プログラムの実行時にアーカイブバックアップを設定していなかった場合の、Calendar Server データベースのアーカイブバックアップの有効化の概要と方法について説明します。

この節の内容は、次のとおりです。

9.6.1 Calendar Server バージョン 6.3 のアーカイブバックアップとは

アーカイブバックアップは、スナップショットと、そのために作成されたログファイルから構成されます。ログファイルは、スナップショットには適用されません。アーカイブデータベースは、破棄されるまでディスクに残ります。「9.2.3 Calendar Server 6.3 システムでの循環バックアップの機能」を参照してください。

ProcedureCalendar Server 6.3 システムのアーカイブバックアップを有効にするには

  1. 設定を変更する権限を持つ管理者としてログインします。

  2. stop-cal コマンドを発行して Calendar Server サービスを停止します。

  3. コマンド行で、ics.conf が格納されているディレクトリに移動します。

    cd /etc/opt/SUNWics5/config

  4. 次の ics.conf パラメータを “yes” に設定して、アーカイブバックアップを有効にします。

    caldb.berkeleydb.archive.enable=”yes”

  5. アーカイブディレクトリのディレクトリパスを指定します。

    caldb.berkeleydb.archive.path=
   /var/opt/SUNWics5/archive_backup_directory

    一次ディスクドライブにハードウェア障害が発生した場合に備えて、アーカイブバックアップを別のディスクまたはディスクサブシステムで行うこともできます。こうすることにより、一次ドライブまたはサブシステム上で発生する I/O の競合も減少する場合があります。

    高可用性 (HA) の設定を行なっている場合は、このパスを共有ストレージ (/global/cal/) のサブディレクトリとして指定します。第 6 章「Calendar Server 6.3 ソフトウェアでの高可用性 (フェイルオーバーサービス) の設定」も参照してください。

  6. ics.conf ファイルの編集が終わったら、Calendar Server を再起動します。

    cal-svr-base/SUNWics5/cal/sbin/start-cal

    ics.conf ファイルを編集するときにカレンダサービスを停止する必要はありませんが、変更を適用するためにサービスを再起動する必要があります。