3.3. GFS2 ファイルシステムのバックアップ
ファイルシステムのサイズに関係なく、緊急時に備えて GFS2 ファイルシステムのバックアップを定期的に作成することが重要です。多くのシステム管理者は、RAID、マルチパス、ミラーリング、スナップショット、その他の形式の冗長性で保護されているため安全だと感じていますが、安全性は十分ではありません。
ノードまたはノードセットのバックアップを作成するプロセスには通常、ファイルシステム全体を順番に読み取る必要があるため、バックアップの作成に問題が生じる可能性があります。シングルノードからこれを行うと、クラスター内の他のノードがロックの要求を開始するまで、そのノードはキャッシュ内のすべての情報を保持します。クラスターの稼働中にこのタイプのバックアッププログラムを実行すると、パフォーマンスが低下します。
バックアップの完了後にキャッシュを削除すると、他のノードがクラスターのロックとキャッシュの所有権を再取得するのに必要な時間が短縮されます。ただし、バックアッププロセスが開始する前に、キャッシュしていたデータのキャッシュを他のノードが停止するため、これは理想的ではありません。バックアップ完了後に次のコマンドを実行すると、キャッシュを削除できます。
echo -n 3 > /proc/sys/vm/drop_caches
タスクがノード間で分割されるように、クラスターの各ノードがそれ自体のファイルのバックアップを作成する方が高速です。これは、ノード固有のディレクトリーに rsync コマンドを使用するスクリプトで実現できます。
Red Hat では、SAN でハードウェアスナップショットを作成し、そのスナップショットを別のシステムに提供してそこにバックアップを行うことで、GFS2 バックアップを作成することを推奨しています。バックアップシステムはクラスターには含まれないため、-o lockproto=lock_nolock で、スナップショットをマウントする必要があります。ただし、Red Hat は、実稼働環境でシングルノードファイルシステムとして GFS2 を使用することはサポートしていません。このオプションは、クラスターの最小サイズ で説明されているように、バックアップ目的またはセカンダリーサイトの障害復旧ノードにのみ使用してください。このオプションを使用する場合は、必ず GFS2 ファイルシステムが一度に 1 つのシステムによって使用されるようにしてください。
