3.3. Copia de seguridad de un sistema de archivos GFS2

Es importante hacer copias de seguridad regulares de su sistema de archivos GFS2 en caso de emergencia, independientemente del tamaño de su sistema de archivos. Muchos administradores de sistemas se sienten seguros porque están protegidos por RAID, multipath, mirroring, snapshots y otras formas de redundancia, pero no hay nada suficientemente seguro.

Puede ser un problema crear una copia de seguridad ya que el proceso de copia de seguridad de un nodo o conjunto de nodos suele implicar la lectura de todo el sistema de archivos en secuencia. Si esto se hace desde un solo nodo, ese nodo retendrá toda la información en la caché hasta que otros nodos del cluster comiencen a solicitar bloqueos. Ejecutar este tipo de programa de copia de seguridad mientras el clúster está en funcionamiento tendrá un impacto negativo en el rendimiento.

La eliminación de las cachés una vez que se ha completado la copia de seguridad reduce el tiempo necesario para que los otros nodos recuperen la propiedad de sus bloqueos/cachés del clúster. Sin embargo, esto no es lo ideal, ya que los otros nodos habrán dejado de almacenar en caché los datos que estaban almacenando antes de que comenzara el proceso de copia de seguridad. Puede eliminar las cachés utilizando el siguiente comando una vez que se haya completado la copia de seguridad:

echo -n 3 > /proc/sys/vm/drop_caches

Es más rápido si cada nodo del clúster hace una copia de seguridad de sus propios archivos, de modo que la tarea se divide entre los nodos. Esto puede lograrse con un script que utilice el comando rsync en directorios específicos de cada nodo.

Red Hat recomienda hacer una copia de seguridad de GFS2 creando una instantánea de hardware en la SAN, presentando la instantánea a otro sistema y haciendo una copia de seguridad allí. El sistema de respaldo debe montar la instantánea con -o lockproto=lock_nolock ya que no estará en un cluster.