square.gif システムメンテナンス

homeicon.gif Print Page commentsicon.gif

バックアップの自動化方策

Table of Contents: 表示

このドキュメントは GroundWork Monitor システムのバックアップ手順を自動化するための高度な構成設定について触れ、上記の目次でリストアップしたトピックを説明します。

ベストプラクティス

RPM システムの初期インストールおよび多くのパッチは、それらを適用するための明確な手順と共にRPMパッケージで提供されます。何もない(地金の)状態からのシステムの基本的なインストレーションであれば、正確に繰り返すことができるでしょう。このレベルのリカバリを行うには、元媒体と特定の構成要素(IPアドレス、名前、DNS など)についての変更作業記録などが必要です。

データベース  GroundWork Monitorは、構成、制御および監視ステータスとイベント保存のためのデータベースエンジンとして、MySQL Professional を利用しています。下記にいくつかのデータベースの名前を挙げますが、完全な一覧ではなく、より多くのプロジェクトを統合するのに合わせ、追加されるでしょう。これらのデータベースそれぞれは、GroundWork Monitor の機能に重要であり、バックアップやリカバリの方針に含まれている必要があります。

ファイル   GroundWork Monitorは、製品インストールのための RPM に含まれたり、カスタマイズ中に追加されたりしたファイルを使用します。RPM パッケージは、それらのほとんどがリビルドできるので、チューニングや現地語化は、明確に RPM インストール後に行われる必要があります。つまり、これらのファイルについても認識し、バックアップとリカバリの方法で一緒に取り扱う必要があります。このようなファイル例として下記のものがあります:

結論  バックアップとリカバリでうまく操作をするために、初期インストレーション、データベースおよび構成ファイルを異なる方法で扱う必要があります。

データベースのバックアップとリストア

データベースのバックアップ

バックアップとリストアのために下記の方法を推奨します。データベースのサイズによっては、もっと頻繁にバックアップを行ても良いでしょう。

  1. 下記の例のような記述を用いて、 MySQL  データベースの完全なバックアップを実施する 'cron' ジョブを実行します。これは、タイムスタンプの付いたひとつのバックアップファイルとして、その時の全データベースのイメージを生成します。下記の cron ジョブの例は、自動的に5日以上古いイメージのディレクトリを自動的に取り除きます。

0 */12 * * * date=`date -Iminutesf`; mysqldump -h 127.0.0.1 --user=admin --opt --all-databases --single-transaction | gzip -c > /backup/mysql/groundwork$date.sql.gz; find /backup/mysql -mtime +5 -exec /bin/rm -rf {} \;

  1. 一日に一度、変更が極端に少ない場合は変更の度毎に、'cron' ジョブから下記の一覧の重要なデータベースのバックアップを個別に実施します。この記述では、既存のファイルを上書きするので、それらのバックアップは保持されません。

0 1 * * * mysqldump -h 127.0.0.1 --user=admin --single-transaction monarch | gzip -c > /backup/mysql/monarch_backup_file.sql.gz

10 1 * * * mysqldump -h 127.0.0.1 --user=admin --single-transaction GWCollageDB | gzip -c > /backup/mysql/GWCollage_backup_file.sql.gz

20 1 * * * mysqldump -h 127.0.0.1 --user=admin --single-transaction dashboard | gzip -c > /backup/mysql/dashboard_backup_file.sql.gz

  1.  最後に、Monarch を使う通常の運用において Cmmit(コミット)を実施する前に必ずバックアップを行ってください。上述の cron ジョブで生成されるのと機能的に同等のバックアップが作成され(すべてのバックアップのリストを保持するのと同様)行われた全ての変更を管理する利点があります。例中のターゲットディレクトリの場所を決めることは重要です。それには以下の条件を満たす必要があるでしょう:

注意:

データベースのリストア

どのバックアップイメージを使用するかは、あなたがどのような問題に直面しているかによって変わります。状況を評価し、リカバリーのための作業が最も少なくなるイメージを選んでください。リカバリーの手順は下記の通りです

MySQL全体を失った場合

新しいサーバを立ち上げるか、正常なファイルシステムで MySQL の稼動中ポイントまでのリカバリを実施します。

  1. 新しいサーバを立ち上げるか、正常なファイルシステムで MySQL の稼動中ポイントまでのリカバリを実施します。

  2. 何らかのアプリケーション( gwservicesなど)が稼動していれば停止させます。

  3. 最新の mysqldump ファイルを適当なファイルの上で unzip(解凍)します。

  4. 下記を投入してリカバリを実施します。 xxx は、ダンプのファイル名です:

mysql < xxx

  1. mysql エンジンと関連する GW サービスをリスタートします。

/usr/local/groundwork/ctlscript.sh restart mysqld

/usr/local/groundwork/ctlscript.sh restart gwservices

  1. ブラウザを再起動した後、ブラウザのキャッシュをクリアする必要があります。

ひとつのコンポーネントの欠落

  1. 上記の置き換え文字 xxx があるステップで、リカバリーに関連する特定ファイルで行います。例: GWCollageDB そして、 xxx はダンプのファイル名です:

mysql GWColllageDB < xxx

  1. MySQL エンジンと関連するGW サービスをリスタートします。

/usr/local/groundwork/ctlscript.sh restart mysqld

/usr/local/groundwork/ctlscript.sh restart gwservices

  1. ブラウザを再起動した後、ブラウザのキャッシュをクリアする必要があります。

構成設定のバックアップとリストア

構成設定のバックアップ

インストレーションには、事故やアップグレードのために欠落してしまう事象のために置き換えなければならない、構成ファイルやカスタマイズが含まれています。ここに、そのような事故やアップグレード後の構成ファイルとカスタマイズのリストアを支援する推奨手順があります。

最低限、単一の変更管理ファイルや、CF エンジンや CVS などの管理スキームにあるすべての構成ファイルを、パスと名前で特定します。安全なリソース上にこれらの変更されたファイルのバックアップを作り、同時に、将来のリカバリーのためにデータベースをバックアップします。定期的に保存ファイルの正しさの確認を実施し、定常的にアップデートをします。

下記に、非常に単純化した変更ファイル手法を使った、cron ジョブの例を示します(通常のプロジェクトを外れたより専門的な体制を作ることをお勧めします)。

0 1 * * * date=`date -Iminutes`; tar ?cT yyy | gzip -c > /backup/configs/groundwork-$date.gz; find /backup/configs -mtime +5 -exec /bin/rm -rf {} \;

yyy は変更したファイルのリストを含むファイルのパスと名前で置き換えます。そのバックアップファイルが、バックアップを行おうとしている装置の一部でないものの上のあることを確認してください。定期的にサイトのコピーを取ることを考慮してください。

構成設定のリストア

復旧は、アップグレード中に上書きされた、あるいは、サーバ損傷後に最初からリビルドされた全体インストレーション内のいくつかのファイルの置き換えとなるでしょう。どちらの場合でも、上書きする前に最新のバックアップをテンポラリのファイルシステム(/tmp)に untar してリカバーしたファイルをひとつひとつ確認し、どれがどれと対応するかを比較することを推奨します。

データファイルのバックアップとリストア

データファイルのバックアップ

長期間分析のための値が入った RRD ファイルがあります。これらのファイルは運用中に監視プロセスによって頻繁にアップデートされます。バックアップを成功させるにはファイルが一部が書き換え中でない時に変更を捕まえることが必要です。どのように変更を捕らえるかは要件定義で行う必要があります。

GroundWork Monitor がコントロールするアクティブやパッシブチェックは、RRD ファイルを生成します。これらをうまくバックアップするために、(Nagiosのための)ファイルベースのパフォーマンスデータ処理とバックアップを統合することを推奨します。これには最小限の Nagios の生成プロセス停止が必要です。この後にバックアップを行います。そして、しかるべきデーモンや cron ジョブをリスタートします。

データファイルのリストア

バックアップを作るのと同様に、生成プロセスとリストア間の衝突を回避するための注意が必要です。デーモンを停止し、リストアを実施してからデーモンをリスタートします。