Sabemos que hay varios métodos que podemos usar para hacer copias de seguridad en Firebird, entonces: ¿por qué usar GBAK?
La ventaja de usar GBAK es que no solamente realiza la copia de seguridad (o backup) sino que también deja a la Base de Datos restaurada en perfecto estado de salud.
Esto es así porque:
- GBAK no copia la basura de la Base de Datos original en el archivo de backup. El archivo de backup está siempre sin basura, totalmente limpio de basura.
- GBAK copia los nombres de los índices y sus definiciones, pero no las páginas que contienen a esos índices. Cuando realiza la restauración allí sí crea cada índice. De esta manera se consigue que: a) el archivo de backup sea más pequeño porque no contiene las páginas de datos de los índices, b) que el archivo de backup se genere más rápido porque no tiene páginas de datos de los índices, c) que al restaurar, todos los índices se encuentren perfectamente balanceados y que las estadísticas de los índices sean exactas.
- GBAK cuando restaura el backup verifica que todas las filas contengan datos válidos. Si descubre un error (por ejemplo que una columna definida como NOT NULL tiene un valor NULL) enseguida lo notifica y finaliza la restauración.
Las páginas de la Base de Datos que contienen índices pueden ser miles y miles, entonces al no copiarlas en el archivo de backup se ahorra mucho espacio en el disco duro y se gana en velocidad. Cada página de la Base de Datos, como ya habíamos visto en otro artículo, tiene un tamaño fijo de bytes. Por ejemplo, cada página ocupa 4096 bytes en el disco duro.
¿Cómo funciona GBAK?:
GBAK puede realizar el backup mientras los usuarios están usando la Base de Datos. El archivo de backup contendrá lo que tenía la Base de Datos original en el momento en que se inició GBAK. Lo que después hagan los usuarios se guardará en un archivo auxiliar, llamado «delta». Cuando GBAK finalice su tarea, todo lo que se grabó en el archivo «delta» se copiará en la Base de Datos original.
Este funcionamiento de GBAK tiene una ventaja y una desventaja:
- La ventaja es que mientras GBAK se está ejecutando los usuarios pueden continuar trabajando con la Base de Datos
- La desventaja es que el rendimiento de la Base de Datos decae, porque los usuarios trabajan con dos archivos: el de la Base de Datos original, y el temporario «delta». Es por ese motivo que se recomienda que se ejecute a GBAK cuando nadie está usando la Base de Datos (y si eso no es posible, al menos cuando muy pocos usuarios la estén usando).
GBAK crea una transacción en la Base de Datos original para realizar su tarea. Para la Base de Datos, GBAK se comporta como si de un usuario humano se tratara, no hay diferencia.
Cuando empieza el backup, GBAK bloquea a toda la Base de Datos. A partir de ese momento y hasta que GBAK finalice, la Base de Datos podrá ser consultada (con el comando SELECT) pero no se le podrán insertar, ni actualizar, ni borrar filas (con los comandos INSERT, UPDATE, DELETE, respectivamente). La ejecución de estos comandos se guardará en un archivo auxiliar llamado «delta». Cuando GBAK finalice su tarea de hacer el backup, la transacción que él inició finalizará con un COMMIT y el contenido de ese archivo «delta» será agregado a la Base de Datos original y ésta será desbloqueada, para que se pueda continuar trabajando normalmente con ella.
El archivo de backup que generó GBAK (y que usualmente tiene la extensión .FBK, aunque no es obligatorio que tenga esa extensión) no puede ser utilizado hasta que sea restaurado.
Resumiendo:
Al realizar el backup:
- Los usuarios pueden continuar usando la Base de Datos mientras GBAK está haciendo el backup
- GBAK crea un archivo que contendrá gran parte de lo que tiene la Base de Datos. El nombre de ese archivo puede ser cualquiera que admita el Sistema Operativo, y la extensión usualmente es .FBK (aunque no es obligatorio)
- GBAK bloquea totalmente a la Base de Datos, para que nada en ella pueda ser cambiado hasta que él finalice
- GBAK inicia una transacción en la Base de Datos
- GBAK crea un archivo temporario llamado «delta». A partir de ese momento, todos los INSERT, UPDATE, y DELETE, se guardarán en el archivo «delta», porque la Base de Datos está bloqueada
- GBAK copia en el backup todas las filas confirmadas de cada tabla
- GBAK no copia en el backup la basura
- GBAK copia en el backup los nombres de los índices y las definiciones de los índices
- GBAK no copia en el backup las páginas de índices
- El rendimiento de la Base de Datos decae mientras se usa GBAK porque los usuarios trabajan con dos archivos: el de la Base de Datos original y el temporario «delta»
- GBAK no verifica que las filas de las tablas que está copiando en el archivo de backup contengan datos válidos, las copia así como las encuentra, con todos los errores que pudieran tener
- Al terminar de crear el archivo de backup, GBAK finaliza con un COMMIT la transacción que había iniciado en la Base de Datos
- GBAK le agrega a la Base de Datos el contenido del archivo temporario «delta»
- GBAK desbloquea a la Base de Datos
Al restaurar:
- Se crea un archivo que contendrá una Base de Datos de Firebird válida
- Se puede cambiar el tamaño de cada página
- Primero se agregan los metadatos y luego los datos introducidos por los usuarios
- Todo el contenido del archivo de backup es tratado como si hubiera sido puesto por una sola transacción. Por ese motivo todas las filas de todas las tablas tienen un TID igual a 1
- Cuando se van agregando filas a las tablas se verifica que cumplan con las restricciones. Si se descubre algún error, se lo notifica inmediatamente
- Se agregan las páginas de índices
- Se calculan las estadísticas de los índices
- Se actualiza el valor del indicador NT (next transaction)
Artículos relacionados:
Los métodos para hacer backups
Entendiendo las páginas de la Base de Datos
Eligiendo el tamaño adecuado de las páginas de la Base de Datos
Entendiendo los identificadores de las transacciones
La Next Transaction después de un ciclo backup/restore
Firebird SQL 
Comentarios recientes