OpenStackバックアップポリシーを作成する際、標準的なバックアップのベストプラクティスが適用できます。例えば、どの程度の頻度でバックアップを行なうかは、どのくらい早くデータロスから復旧させる必要があるかに密接に関連しています。
![[注記]](../common/images/admon/note.png) | 注記 |
|---|---|
もし、いかなるデータロスも許されない場合、バックアップに加えて高可用性（High Avaialability）についても検討すべきです。 |
さらにバックアップの考慮点として以下があげられます。
いくつのバックアップを持つべきか?
オフサイトにバックアップを置くべきか?
どの程度の頻度でバックアップをテストすべきか?
バックアップポリシーと同じくらい大事なことは、リカバリーポリシーです (少なくともリカバリーのテストは必要です)。
OpenStackは多くのコンポーネントから構成され、注意を払うべき箇所もたくさんありますが、大事なデータのバックアップは非常に単純です。
この章では、OpenStackコンポーネントを動作させるのに必要な設定ファイルとデータベースについてのバックアップ方法のみを説明します。オブジェクトストレージ内のオブジェクトや、ブロックストレージ内のデータのバックアップについては説明していません。一般的にこれらの領域はユーザー自身でバックアップを行います。
参考アーキテクチャーでは、クラウドコントローラーを MySQL サーバにしています。このMySQL サーバーは Nova, Glance, Cinder, そして Keystone のデータベースを保持しています。全てのデータベースが一ヶ所にある場合、データベースバックアップは非常に容易となります。
# mysqldump --opt --all-databases >
openstack.sqlもし、単一のデータベースのみバックアップする場合は次のように実行します。
# mysqldump --opt nova > nova.sql
ここで nova はバックアップ対象のデータベースです。
以下のようなcronジョブを一日に一度実行することで、簡単に自動化することも出来ます。
#!/bin/bash
backup_dir="/var/lib/backups/mysql"
filename="${backup_dir}/mysql-`hostname`-`eval date +%Y%m%d`.sql.gz"
# Dump the entire MySQL database
/usr/bin/mysqldump --opt --all-databases | gzip > $filename
# Delete backups older than 7 days
find $backup_dir -ctime +7 -type f -deleteこのスクリプトは MySQL データベース全体をダンプし、7日間より古いバックアップを削除します。
このセクションは、サービスにより構成される、定期的にバックアップすべきファイルとディレクトリについて議論します。
クラウドコントローラー、および、コンピュートノードの /etc/novaディレクトリは定期的にバックアップされるべきです。
/var/log/nova については、全てのログをリモートで集中管理しているのであれば、バックアップの必要はありません。ログ集約システムの導入か、ログディレクトリのバックアップを強く推奨します
/var/lib/nova がバックアップする他の重要なディレクトリです。これの例外がコンピュートノードにある /var/lib/nova/instances サブディレクトリです。このサブディレクトリには実行中のインスタンスの KVM イメージが置かれます。このディレクトリをバックアップしたいと思うのは、すべてのインスタンスのバックアップコピーを保持する必要がある場合だけでしょう。多くの場合において、これを実行する必要がありません。ただし、クラウドごとに異なり、サービスレベルによっても異なる可能性があります。稼働中の KVM インスタンスのバックアップは、バックアップから復元したときでも、正しく起動しない可能性があることに気をつけてください。
/etc/glanceと/var/log/glanceはnovaの場合と同じルールに従います。
/var/lib/glanceもバックアップすべきです。 /var/lib/glance/imagesには特段の注意が必要です。もし、ファイルベースのバックエンドを利用しており、このディレクトリがイメージの保管ディレクトリならば特にです。
このディレクトリの永続性を保証するために二つの方法があります。一つ目はRAIDアレイ上にこのディレクトリを置くことで、ディスク障害時にもこのディレクトリが利用できます。二つ目の方法はrsyncのようなツールを用いてイメージを他のサーバーに複製することです。
# rsync -az --progress /var/lib/glance/images backup-server:/var/lib/glance/images/
/etc/keystoneと/var/log/keystoneは他のコンポーネントと同じルールになります。
/var/lib/keystoneは、使用されるデータは含まれていないはずですが、念のためバックアップします。
/etc/swiftは非常に重要ですのでバックアップが必要です。このディレクトリには、Swiftの設定ファイル以外に、RingファイルやRingビルダーファイルが置かれています。これらのファイルを消失した場合はクラスター上のデータにアクセスできなくなります。ベストプラクティスとしては、ビルダーファイルを全てのストレージノードにringファイルと共に置くことです。この方法でストレージクラスター上にバックアップコピーが分散されて保存されます。
バックアップのリカバリーは単純です。始めにリカバリー対象のサービスが停止していることを確認します。例を挙げると、クラウドコントローラー上のnovaの完全リカバリーを行なう場合、最初に全ての nova サービスを停止します。
# stop nova-api
# stop nova-cert
# stop nova-consoleauth
# stop nova-novncproxy
# stop nova-objectstore
# stop nova-schedulerその後、MySQLを停止します。
# stop mysql
以前にバックアップしたデータベースをインポートします。
# mysql nova < nova.sql
同様に、バックアップした nova のディレクトリをリストアします。
# mv /etc/nova{,.orig}
# cp -a /path/to/backup/nova /etc/ファイルをリストア後、サービスを起動します。
# start mysql
# for i in nova-api nova-cert nova-consoleauth nova-novncproxy nova-objectstore nova-scheduler
> do
> start $i
> done
他のサービスもそれぞれのディレクトリとデータベース名で同じ処理となります。
