Guía rápida para la copia de seguridad y restauración con Gbak

¿Qué es gbak?

Gbak es una herramienta estándar de línea de comandos de Firebird (consulte su documentación oficial aquí), diseñada para realizar 1) copia de seguridad completa de la base de datos: lee cada registro en la base de datos y los almacena en el archivo de copia de seguridad, 2) restaurar la copia de seguridad a una nueva base de datos.

Para desarrolladores y administradores con experiencia en otros RDBMS, el término “copia de seguridad” podría ser un poco confuso, ya que gbak no produce una copia exacta de la base de datos, sino un archivo en formato no-database, solo con datos (los índices se almacenan como declaraciones).

Para crear una base de datos a partir del archivo de copia de seguridad de gbak, se debe realizar el proceso de restauración con gbak.

1. Dominando las copias de seguridad con Gbak

1.0. Preparación

Creemos la carpeta C:\data y coloquemos allí alguna base de datos. Usaremos una base de datos de 5Gb de la prueba Firebird OLTP-EMUL, pero puede usar su propia base de datos, por supuesto.

Para usuarios de Linux: creemos la carpeta /db y cambiemos su propietario a “firebird”, y copiemos la base de datos allí (asegúrese de que su propietario también sea firebird).

Code

mkdir /db
chown firebird -R /db

1.1 La copia de seguridad más simple de Firebird con el comando gbak

Windows

Code

gbak -b c:\Data\test1.fdb C:\data\backup1.fbk -user SYSDBA -pass masterkey

Linux

Code

gbak -b /db/test1.fdb /db/backup1.fbk -user SYSDBA -pass masterkey

En este ejemplo, la herramienta gbak accede al archivo de base de datos usando acceso local o embebido.

Firebird 3.0: El acceso embebido en la configuración predeterminada para Firebird 3.0 (con el parámetro en firebird.conf ServerMode = SuperServer) intentará poner un bloqueo exclusivo en la base de datos, por lo que otras conexiones no podrán acceder a la base de datos (o el intento de gbak fallará debido a las conexiones activas).

Firebird 2.5: Con Firebird 2.5 en Windows, el comando funcionará bien a través del protocolo XNET (si tiene la única instancia de Firebird ejecutándose, por supuesto). En Linux, Firebird intentará usar acceso embebido; si no está disponible, automáticamente (e implícitamente) intentará conectarse a través de TCP/IP. (Si no sabe qué significan XNET, INET, etc., consulte la Hoja de referencia de cadenas de conexión de Firebird).

Nota 1: Este comando se ejecuta bajo la cuenta del usuario del sistema operativo (es decir, la suya) y usa sus permisos para acceder a los archivos de copia de seguridad y base de datos.

Normalmente, el servicio de Firebird en Windows se ejecuta con la cuenta LocalSystem, y en Linux bajo el usuario “firebird”, pero la consola generalmente se ejecuta bajo su propia cuenta de usuario.

Si esta cuenta de usuario no tiene acceso a la ruta de la base de datos o a la ruta de la copia de seguridad, gbak fallará con el error “Cannot open backup file” (consulte el ejemplo en el Apéndice A. Errores, #5).

Nota 2: gbak -b sobrescribe silenciosamente el archivo de copia de seguridad. Por lo tanto, si ya tiene backup1.fbk, será sobrescrito.

Nota 3: En Linux, este comando gbak creará un archivo de copia de seguridad con el propietario igual al usuario de la consola.

Tiempo para copia de seguridad con este comando: 120 segundos

1.2. Copia de seguridad local con gbak que se puede realizar en línea en Windows

¡Esta sección es solo para usuarios de Windows! Generalmente, necesitamos realizar la copia de seguridad mientras tenemos conexiones activas a la base de datos, por lo que en lugar de conexión embebida, es mejor especificar explícitamente el protocolo local para evitar poner un bloqueo exclusivo en el archivo de base de datos por el propio gbak en Firebird 3, es decir, XNET.

Para Firebird 3.0:

Code

gbak -b xnet://c:\Data\test1.fdb C:\data\backup1.fbk -user SYSDBA -pass masterkey

Para Firebird 2.5, podemos usar una cadena de conexión local, y usará XNET también:

Code

gbak -b c:\Data\test1.fdb C:\data\backup1.fbk -user SYSDBA -pass masterkey

En Linux, Firebird no admite un protocolo local específico como XNET en Windows, por lo que es necesario usar una cadena de conexión TCP/IP (consulte la sección 1.3).

Además, XNET funciona solo para la instancia única de Firebird, por lo que si ejecuta varias instancias de Firebird en Windows, podría ser más fácil usar una cadena de conexión estilo INET para especificar la instancia del servidor de destino.

Tiempo para copia de seguridad: 139 segundos

1.3. Copia de seguridad con gbak con cadena de conexión TCP/IP

Este es el comando gbak más universal para realizar copias de seguridad en línea.

Windows

Code

gbak -b localhost:c:\Data\test1.fdb C:\data\backup1.fbk -user SYSDBA -pass masterkey

Linux

Code

gbak -b localhost:/db/test1.fdb /db/backup1.fbk -user SYSDBA -pass masterkey

En este caso, al especificar localhost: al comienzo de la ruta de la base de datos, la conexión se realiza a través del subsistema de red de Firebird.

Es ligeramente más lento que el acceso local, pero funciona en todos los casos cuando tenemos un servidor en ejecución que acepta conexiones.

Puerto no estándar para Firebird

Si tiene Firebird ejecutándose en un puerto no estándar (por ejemplo, 3051 en lugar de 3050), puede hacer la copia de seguridad de esta manera:

Windows

Code

gbak -b localhost/3051:c:\Data\test1.fdb C:\data\backup1.fbk -user SYSDBA -pass masterkey

Linux

Code

gbak -b localhost/3051:/db/test1.fdb /db/backup1.fbk -user SYSDBA -pass masterkey

Tiempo para copia de seguridad: 182 segundos

1.4. Copia de seguridad más rápida con gbak con Service Manager

¿Cómo podemos lograr la universalidad de la conexión TCP/IP, con soporte de puerto no estándar, y una copia de seguridad local rápida? ¡Usemos Service Manager! Service Manager, en palabras simples, es la forma de ejecutar herramientas estándar a través del motor de Firebird. Tenga en cuenta que, en el caso de Service Manager, no es necesario especificar el nombre del servidor en la ruta a la base de datos, solo en el parámetro -se.

Windows

Code

gbak -b -se localhost:service_mgr c:\Data\test1.fdb  c:\Data\backup1.fbk -user SYSDBA -pass masterkey

Linux

Code

gbak -b -se localhost:service_mgr /db/test1.fdb /db/backup1.fbk -user SYSDBA -pass masterkey

Este comando usa el interruptor -service para especificar que queremos usar el Service Manager de la instancia de Firebird en el puerto 3050 para realizar la copia de seguridad.

En este caso, la copia de seguridad se realizará directamente dentro del proceso de Firebird (tiene una copia del código de gbak), y dado que la comunicación dentro del proceso es mucho más rápida, la copia de seguridad será significativamente más rápida en este caso.

Si Firebird se ejecuta en un puerto no estándar (por ejemplo, 3051), el comando puede verse así:

Code

gbak -b -se localhost/3051:service_mgr c:\Data\test1.fdb  c:\Data\backup1.fbk -user SYSDBA -pass masterkey

Nota: Hay una limitación significativa en Firebird 2.5 y Firebird 3.0.0-3.0.5 (eliminada solo en 3.0.6): la línea de comandos (todos los parámetros y rutas para la base de datos y para la copia de seguridad) debe tener menos de 256 símbolos.

Si alcanza este límite, por ejemplo, debido a rutas largas de la base de datos y la copia de seguridad, puede declarar un alias para la base de datos en databases.conf (3.0 y superior) o aliases.conf (2.5):

Code

mydb1=c:\Data\test1.fdb #Windows

Code

mydb1=/db/test1.fdb  #linux

y luego usarlo en nuestro comando:

Windows

Code

gbak -b -se localhost:service_mgr mydb1 c:\Data\backup1.fbk -user SYSDBA -pass masterkey

Linux

Code

gbak -b -se localhost:service_mgr mydb1 /db/backup1.fbk -user SYSDBA -pass masterkey

Tiempo para copia de seguridad: 115 segundos

1.5. La copia de seguridad más rápida con gbak con recolección de basura inhibida

Para hacer la copia de seguridad aún más rápida, agreguemos el interruptor -g

Code

 -G(ARBAGE_COLLECT)    inhibit garbage collection

Entonces, el comando de copia de seguridad será el siguiente

Windows

Code

gbak -b -se localhost:service_mgr -g mydb1 c:\Data\backup1.fbk -user SYSDBA -pass masterkey

Linux

Code

gbak -b -se localhost:service_mgr -g mydb1 /db/backup1.fbk -user SYSDBA -pass masterkey

El interruptor -g obliga al motor de Firebird a deshabilitar la recolección de basura para el proceso de copia de seguridad en el archivo de base de datos.

No significa que las versiones de registros basura se almacenarán en el archivo de copia de seguridad; significa que el servidor no intentará limpiar la basura existente en la base de datos durante la copia de seguridad, y la copia de seguridad será más rápida.

Recomendamos encarecidamente usar este interruptor, porque creemos que la recolección de basura y la limpieza asociada deben realizarse con sweep (gfix -sweep o autosweep), por lo que es mejor no considerar gbak como una alternativa al sweep.

Tiempo para copia de seguridad: 105 segundos

1.6. Copia de seguridad en un recurso compartido de red o ubicación de red

¿Qué pasa si necesitamos colocar el archivo de copia de seguridad en un recurso compartido de red?

En Windows

La confusión frecuente de los nuevos usuarios de Firebird: la copia de seguridad manual (cuando inicia el comando desde un símbolo del sistema), con simple gbak -b, al recurso compartido de red funciona bien, pero la versión rápida de gbak con -se localhost:service_mgr, no funciona.

La razón es que Firebird en Windows se ejecuta bajo la cuenta LocalSystem, que no tiene acceso a las ubicaciones de red (a menos que estos recursos compartidos de red tengan configurado el acceso para el grupo “Everyone”, pero esto es muy, muy peligroso en nuestra era de ransomware).

La solución es ejecutar el servicio de Firebird en Windows bajo una cuenta con suficientes derechos para acceder al recurso compartido de red y, simultáneamente, suficientes derechos para acceder a los archivos locales de la base de datos y a los archivos del sistema en C:\ProgramData\Firebird. Además, una buena idea es configurar el parámetro RestrictAccess en firebird.conf.

En Linux

Dado que Firebird en Linux se ejecuta bajo la cuenta “firebird”, monte el recurso compartido de red con mapeo al usuario “firebird”, para que el servicio de Firebird pueda acceder a la ubicación de red de la misma manera que a una unidad local.

1.7. Copia de seguridad simple desde el servidor remoto a la máquina local

Es posible realizar una copia de seguridad de la base de datos desde el servidor remoto a la máquina local.

El comando de ejemplo a continuación se inicia en una computadora con Windows, accede a la base de datos en un servidor Linux (con dirección IP 192.168.0.108, aunque también se puede usar el nombre de host del servidor, por supuesto), y el archivo de copia de seguridad se almacena en la carpeta C:\Data en Windows):

Code

gbak -b -user SYSDBA -pass masterkey 192.168.0.108:/db/test1.fdb c:\data\remotebackup1.fbk

Tiempo de copia de seguridad: 568 segundos

Este comando generalmente será mucho más lento que la copia de seguridad local, porque gbak lee los datos del servidor remoto y transfiere los registros a través de la red.

1.8. Copia de seguridad más rápida desde el servidor remoto a local con Service Manager

El comando a continuación es más rápido que la copia de seguridad tradicional desde el servidor remoto a la máquina local, descrita en #1.7

Code

gbak -b -se 192.168.0.108:service_mgr -user SYSDBA -pass masterkey /db/test1.fdb stdout > C:\Data\remoteback1.fbk

Utiliza Service Manager para realizar la copia de seguridad en el servidor remoto, pero la salida se envía a la tubería stdout y luego se redirige al archivo local.

Este comando suele ser 15%-20% más rápido que el de #1.7 (Copia de seguridad simple desde el servidor remoto a local), debido a lo siguiente:

realiza la copia de seguridad a través de Service Manager en el servidor remoto, por lo que todas las operaciones de lectura y compresión se realizan de la manera más rápida,
transfiere a través de la red solo el archivo de copia de seguridad resultante, con un tamaño menor que los datos en la base de datos

Sin embargo, con este comando, no es posible habilitar el modo verbose y almacenar la salida detallada en el archivo de registro.

Tiempo de copia de seguridad: 473 segundos

1.9. Copia de seguridad de la base de datos Firebird en el servidor remoto al mismo servidor remoto usando Service Manager

Con Service Manager, es posible invocar la copia de seguridad gbak de la base de datos en el servidor remoto y almacenarla también en el mismo servidor remoto.

Code

gbak -b -se  192.168.0.108:service_mgr -user SYSDBA -pass masterkey /db/test1.fdb /db/back12.fbk

Este comando, a través de Service Manager, invoca la copia de seguridad en el servidor remoto, con la instrucción de almacenar el archivo de copia de seguridad también en el mismo servidor de red.

Por supuesto, la ubicación de la copia de seguridad debe ser accesible por el servicio de Firebird (en Linux se ejecuta como usuario “firebird”, en Windows como cuenta LocalSystem).

1.10. Copia de seguridad de la base de datos Firebird 6 veces más rápida con copia de seguridad multiproceso en Firebird 5 (o HQbird 2.5/3.0/4.0/5.0)

Si aún no está satisfecho con el rendimiento de copia de seguridad de Firebird gbak, considere migrar a Firebird 5 (o use la distribución empresarial de Firebird: HQbird para otras versiones).

Admite copia de seguridad multiproceso, que permite operaciones de copia de seguridad hasta 6 veces más rápidas con gbak.

Code

gbak -b -par 8  -se localhost:service_mgr -g C:\Data\testbigdb1.fdb c:\Data\backup1.fbk -user SYSDBA -pass masterkey

Como puede ver, hay un nuevo parámetro -par 8, que hace que gbak use 8 hilos para crear una copia de seguridad.

HQbird realiza tareas de mantenimiento (sweep, copia de seguridad, restauración) mucho más rápido (los resultados en la figura a continuación son de una base de datos diferente, por supuesto):

2. Restauración con la herramienta Gbak

Tenemos el archivo de copia de seguridad backup1.fbk, creado por uno de los comandos anteriores, y necesitamos restaurarlo de manera rápida y eficiente.

Supongamos que el archivo está en C:\Data\backup1.fbk en caso de Windows, o /db/backup1.fbk en caso de Linux.

2.1. El comando de restauración más simple

En Windows

Code

gbak -c C:\Data\backup1.fbk C:\data\new1.fdb -user SYSDBA -pass masterkey

En Linux

Code

gbak -c /db/backup1.fbk /db/new1.fdb -user SYSDBA -pass masterkey

En primer lugar, tenga en cuenta que gbak -c no sobrescribe el archivo de base de datos, y si existe el archivo C:\data\new1.fdb o /db/new1.fdb, gbak devolverá un error indicando que la base de datos ya existe.

Luego, este comando en realidad funciona de manera muy diferente en 2.5/3.0+ y Windows/Linux.

En Linux, este comando utilizará acceso embebido a la base de datos creada (si no cambió el orden de los proveedores de Firebird en firebird.conf, por supuesto) tanto para 3.0 como para 2.5.

En Windows, en Firebird 3.0 con el orden predeterminado de proveedores, será acceso embebido, en 2.5 - XNET.

Luego, este comando crea un archivo con los derechos del usuario que inició gbak, esto es especialmente importante en Linux - si ejecuta dicho gbak como root, el propietario del archivo de base de datos será root, y el proceso de Firebird, que se ejecuta bajo el usuario “firebird”, no podrá acceder al archivo restaurado.

Nota para usuarios de Linux

Muchas personas, para “arreglar” la propiedad, aplican permisos para que todos puedan acceder a la base de datos restaurada, es decir, algo como “chmod 777 database”, pero esto es muy inseguro; la forma adecuada es cambiar el propietario de la base de datos a firebird, con el siguiente comando

Code

chown firebird /db/new1.fdb

En general, este comando es suficientemente bueno para la restauración simple de bases de datos no productivas (utilizadas para pruebas o en desarrollo).

Tiempo de restauración: 275 segundos

2.2. Restauración con cadena de conexión localhost

La opción de restauración más universal, pero no la más rápida, es la siguiente:

Windows

Code

gbak -c C:\Data\backup1.fbk localhost:C:\data\new1.fdb -user SYSDBA -pass masterkey

Linux

Code

gbak -c /db/backup1.fbk localhost:/db/new1.fdb -user SYSDBA -pass masterkey

Puerto no estándar

Si Firebird se ejecuta en un puerto no estándar, por ejemplo, 3051, se puede especificar en el comando de restauración:

Windows

Code

gbak -c C:\Data\backup1.fbk localhost/3051:C:\data\new1.fdb -user SYSDBA -pass masterkey

Linux

Code

gbak -c /db/backup1.fbk localhost/3051:/db/new1.fdb -user SYSDBA -pass masterkey

Tiempo de restauración: 1225 segundos

2.3. Restauración con XNET en Windows

Para hacer la restauración un poco más rápida, en Windows podemos usar XNET (para Firebird 3.0 y superior):

Code

gbak -c C:\Data\backup1.fbk xnet://C:\Data\New2.fdb -user SYSDBA -pass masterkey

En Firebird 2.5 en Windows, se usará acceso XNET con la línea de comandos simple (si solo se está ejecutando una instancia de Firebird):

Code

gbak -c C:\Data\backup1.fbk C:\data\new1.fdb -user SYSDBA -pass masterkey

Tiempo de restauración: 585 segundos

2.4. Restauración más rápida con Service Manager

Y la forma más rápida de restaurar es usar Service Manager

Windows

Code

gbak -c -se localhost:service_mgr C:\Data\backup1.fbk C:\data\new1.fdb -user SYSDBA -pass masterkey

Linux

Code

gbak -c -se localhost:service_mgr /db/backup1.fbk localhost:/db/new1.fdb -user SYSDBA -pass masterkey

Con el interruptor -se, invocamos Service Manager en la dirección localhost y le indicamos que realice el código de restauración dentro del motor de Firebird.

Cuando la restauración la realiza Service Manager, el archivo de base de datos creado será propiedad de la cuenta de la instancia de Firebird en ejecución (proceso) - es “firebird” en Linux y LocalSystem en Windows.

Tiempo de restauración: 244 segundos

2.5. Interruptor no recomendado

En algún momento podría tener la tentación de usar el siguiente interruptor:

Code

   -R(ECREATE_DATABASE) [O(VERWRITE)] create (or replace if OVERWRITE used)                               database from backup file (restore)

Code

para forzar el reemplazo de la base de datos existente con la nueva.

En nuestra experiencia, este interruptor aumenta enormemente las posibilidades de sobrescribir accidentalmente la base de datos de producción.

Recomendamos encarecidamente restaurar la base de datos cada vez con un nombre nuevo y renombrarla, así como eliminar la base de datos antigua, explícitamente.

Incluso no proporcionaremos el ejemplo del comando con este interruptor.

2.6. Restauración de la base de datos usando un alias

Es posible restaurar la base de datos usando el alias, declarado en databases.conf (o aliases.conf en Firebird 2.5)

Por ejemplo, tenemos la siguiente declaración

Code

restdb=c:\Data\newrest1.fdb  #Windows

restdb=/db/newrest1.fdb  #Linux

Así que podemos ejecutar el siguiente comando para restaurar la copia de seguridad a la ruta especificada por el alias

Windows

Code

gbak -c -se localhost:service_mgr C:\Data\backup1.fbk restdb -user SYSDBA -pass masterkey

Linux

Code

gbak -c -se localhost:service_mgr /db/backup1.fbk restdb -user SYSDBA -pass masterkey

2.7. Restauración de copia de seguridad local al servidor remoto

Es posible restaurar el archivo de copia de seguridad local al servidor Firebird remoto.

En este ejemplo, restauramos el archivo de copia de seguridad almacenado en Windows, al servidor Linux (su dirección IP 102.168.0.108):

Code

gbak  -c C:\Data\backup1.fbk 192.168.0.108:/db/newdb1.fdb -user SYSDBA -pass masterkey

Tiempo de restauración: 7009 segundos

Como puede notar, el proceso de restauración remota funciona muy lento, ¿podemos acelerarlo con Service Manager?

2.8. Restauración de la copia de seguridad local al servidor remoto con Service Manager

Para restaurar la copia de seguridad local en el servidor remoto con Service Manager, es necesario hacer el truco con el flujo de entrada stdin:

Code

gbak -c -se 192.168.0.108:service_mgr -user SYSDBA -pass masterkey stdin /db/new3.fdb <  C:\Data\backup1.fbk

Este comando invoca la restauración en el servidor remoto con la entrada estándar stdin como fuente de la copia de seguridad - y suministra la entrada usando la parte < C:\Data\backup1.fbk del comando.

¿Parece un poco complicado? ¡Pero es una manera fácil de aumentar 10 veces el rendimiento de gbak para restaurar al servidor remoto!

Tiempo de restauración: 450 segundos

2.9. Restauración de tablas extremadamente largas

Si tiene una base de datos realmente grande con un número total de filas superior a 2 mil millones, es necesario especificar el interruptor -o[ne_at_a_time], para restaurar cada tabla en una transacción separada, para evitar algún desbordamiento interno.

Code

gbak -c -se localhost:service_mgr -one C:\Data\backup1.fbk C:\data\new44.fdb -user SYSDBA -pass masterkey

3. Ajuste y registro de procesos de copia de seguridad y restauración

3.1. Gbak con salida verbose

Por defecto, gbak es una herramienta muy silenciosa, no devuelve nada en caso de ejecución exitosa. Para hacerla verbose, podemos agregar el interruptor -v[erify]

Code

gbak -b -se localhost/3050:service_mgr -g mydb1  c:\Data\backup1.fbk -v -user SYSDBA -pass masterkey

Como resultado, habrá más detalles. El problema menor pero molesto es que imprimir la salida en la consola puede hacer que la copia de seguridad verbose sea significativamente más lenta que la variante silenciosa, así que una buena idea será guardar el registro en el archivo con el interruptor - y logfile:

Code

gbak -b -se localhost/3050:service_mgr -g -v mydb1  c:\Data\backup1.fbk -user SYSDBA -pass masterkey -y C:\data\backuplog1.txt

Nota: ¡gbak no sobrescribirá el archivo de registro existente! Si ya tiene C:\data\backuplog1.txt en este ejemplo, la copia de seguridad generará un error (ver #3 en el Apéndice A).

Nota 2: existe la opción -verbint para controlar el intervalo para informar el número de registros procesados durante la copia de seguridad o restauración.

3.2. Agregar estadísticas de rendimiento a la salida verbose

En la salida verbose de gbak para copia de seguridad y restauración, podemos ver mensajes como estos:

Code

gbak:    writing data for table COUNTRY
gbak:16 records written

para cada tabla y otros objetos de la base de datos.

Es interesante descubrir qué tablas/objetos toman la mayor parte del tiempo, ¿verdad?

Para esto, es necesario usar el interruptor -st(atistics):

Code

 -ST(ATISTICS) TDRW    show statistics:
     T                 time from start
     D                 delta time
     R                 page reads
     W                 page writes

Code

gbak -b -se localhost/3050:service_mgr -g -v mydb1 -st tdrw c:\Data\backup1.fbk -user SYSDBA -pass masterkey -y C:\data\backuplog1.txt

Cuando se aplica, agregará al registro las siguientes columnas:

Code

gbak: time   delta  reads  writes

para que podamos ver el tiempo y la E/S gastados en cada línea.

3.3. Excluir tablas de la copia de seguridad y/o de la restauración

Si cree que algunas tablas pueden excluirse de la copia de seguridad (un buen ejemplo es una tabla de registro muy larga), puede especificarlas en el parámetro SK[IP_DATA], con una expresión regular como parámetro.

En el ejemplo siguiente, excluimos los datos de las tablas COUNTRY y JOB de la copia de seguridad:

Code

gbak -b -se localhost/3050:service_mgr -g -v mydb1 -SKIP_D ‘(COUNTRY|JOB)’ c:\Data\backup1.fbk -user SYSDBA -pass masterkey -y C:\data\backuplog1.txt

Y, en el ejemplo siguiente, excluimos la tabla CLIENT de la restauración:

Code

gbak -c -se localhost:service_mgr C:\Data\backup1.fbk C:\data\new33.fdb -user SYSDBA -pass masterkey -SKIP_D "CLIENT"

Tenga en cuenta que el parámetro para SKIP_DATA debe transmitirse como un único parámetro, ¡por lo que debe ir entre comillas!

En Linux, las comillas deben ser simples; en Windows, dobles.

Precauciones al excluir tablas de la copia de seguridad y/o restauración

Recomendamos encarecidamente verificar la condición de la expresión regular antes de usarla, con la siguiente consulta: devolverá una lista de tablas que corresponden a la condición del filtro (en la consulta, las comillas siempre son simples)

Code

SQL> SELECT RDB$RELATION_NAME FROM RDB$RELATIONS WHERE TRIM(RDB$RELATION_NAME) SIMILAR TO '(COUNTRY|JOB)';

RDB$RELATION_NAME
===============================
COUNTRY
JOB

Tenga en cuenta que las tablas se excluirán de la copia de seguridad o restauración independientemente de las restricciones existentes (claves foráneas), por lo que, si no planificó dicha exclusión cuidadosamente, es muy fácil recibir el error “Cannot commit foreign key index” durante el proceso de restauración.

3.4. Obtener la contraseña para copia de seguridad o restauración desde un archivo

Si no es un gran fanático de la idea de exponer la contraseña a cualquiera que vea sus comandos, le gustará el siguiente modificador: -fetch passwordfile

Creemos el archivo con la contraseña en C:\Data\passfile.txt y usémoslo (aquí usamos una variante integrada muy simple; por supuesto, el modificador también funcionará con Service Manager):

Code

gbak -b c:\Data\test1.fdb c:\Data\backup5.fbk -user SYSDBA -fetch C:\Data\passfile.txt

Hay 2 beneficios prácticos:

Si almacenamos la contraseña en un único archivo, podemos asegurar que todos nuestros archivos de comandos usarán siempre la contraseña actual.
No exponemos la contraseña en cada archivo de comandos.

4. Copia de seguridad-restauración en un solo paso

A menudo, el objetivo de la copia de seguridad es realizar la restauración inmediata, para obtener una nueva base de datos fresca, por ejemplo, para aplicar un nuevo tamaño de página a la base de datos, o para migrar la base de datos existente de 2.5 a 3.0.

En este caso, es posible realizar la copia de seguridad-restauración con un solo comando, utilizando la entrada y salida estándar como fuentes para los comandos apropiados, para evitar la creación del archivo de copia de seguridad intermedio, reducir los requisitos de espacio libre y acelerar el proceso.

El comando es el siguiente:

Code

gbak -b -se localhost:service_mgr -g -user SYSDBA -password masterkey C:\Data\test1.fdb stdout | gbak -c -se localhost:service_mgr -user SYSDBA -password masterkey stdin C:\Data\new10.fdb

En esencia, aquí hacemos 2 comandos, unidos por el símbolo |,

el primero para la copia de seguridad a stdout:

Code

gbak -b -se localhost:service_mgr -g -user SYSDBA -password masterkey C:\Data\test1.fdb stdout

y el segundo, para la restauración desde stdin:

Code

gbak -c -se localhost:service_mgr -user SYSDBA -password masterkey stdin C:\Data\new10.fdb

Este comando es la forma más rápida de realizar una copia de seguridad-restauración en la misma instancia de Firebird.

Tenga en cuenta: para convertir bases de datos con copia de seguridad-restauración en un solo paso de 2.5 a 3.0, es necesario usar 2 instancias de Firebird, consulte los detalles aquí.

5. Resumen de rendimiento

La siguiente figura contiene información sobre la velocidad de diferentes comandos de copia de seguridad local de la base de datos de prueba:

Como puede ver, la forma más rápida de realizar una copia de seguridad local es usar Service Manager (modificador -se[rvice]) e inhibir la recolección de basura (modificador -ig).

Para la copia de seguridad desde un servidor remoto a la máquina local, Service Manager también es la mejor opción:

La situación con el rendimiento de la restauración es similar: Service Manager es la forma más rápida de restaurar.

En cuanto al caso bastante raro en el que la restauración se realiza desde una copia de seguridad local a un servidor remoto, usar Service Manager con el truco de stdin es la única opción viable:

Pregunta muy frecuente sobre VM y copias de seguridad de Firebird

¿Por qué debería usar las herramientas de copia de seguridad de Firebird, cuando hay herramientas de copia de seguridad populares disponibles que prometen respaldarlo todo?

O bien, hago una copia de seguridad de la imagen completa de la Máquina Virtual, ¿por qué debería preocuparme por la copia de seguridad de la base de datos de Firebird?

La respuesta está aquí.

Apéndice A. Errores durante la copia de seguridad/restauración

Un intento de ejecutar gbak sin parámetros, o con un usuario que no sea propietario de la base de datos/no SYSDBA, provocará el siguiente error:

Code

gbak: ERROR:Unable to perform operation.  You must be either SYSDBA or owner of the database
gbak:Exiting before completion due to errors

Si especifica una contraseña incorrecta, se producirá el siguiente error:

Code

gbak: ERROR:Your user name and password are not defined. Ask your database administrator to set up a Firebird login.
gbak:Exiting before completion due to errors

Se produce un error cuando se especifica un archivo existente como destino del registro detallado

Code

gbak: ERROR:cannot open status and error output file C:\data\backuplog1.txt
gbak: ERROR:    Exiting before completion due to errors
gbak:Exiting before completion due to errors

Se produce un error si se especifica una base de datos existente en el comando de restauración de gbak como destino

Code

gbak: ERROR:database C:\data\new1.fdb already exists.  To replace it, use the -REP switch
gbak:Exiting before completion due to errors

Se produce un error cuando gbak intenta escribir una copia de seguridad en una ubicación donde no tiene derechos suficientes para escribir.

Code

gbak: ERROR:cannot open file  /db/test1.fbk
gbak:Exiting before completion due to errors

Cuando gbak intenta acceder al archivo sin permiso para hacerlo, por ejemplo, el archivo tiene otro propietario distinto del usuario “firebird” en Linux

Code

gbak: ERROR:no permission for read-write access to database /db/test1.fdb
gbak: ERROR:    IProvider::attachDatabase failed when loading mapping cache
gbak:Exiting before completion due to errors

Intento de usar salida detallada

Code

C:\HQbird\Firebird30>gbak -se 192.168.0.108:service_mgr -v -st tdrw -user SYSDBA -pass masterkey /db/test1.fdb stdout  >
 c:\data\rembackup2.fbk
gbak: ERROR:standard output is not supported when using split operation or in verbose mode
gbak: ERROR:    Exiting before completion due to errors
gbak:Exiting before completion due to errors

Intento de hacer una copia de seguridad con Service Manager en el servidor remoto con modo detallado habilitado y guardando en el archivo de registro.

Code

C:\HQbird\Firebird30>gbak -se 192.168.0.108:service_mgr -v -st tdrw -y lg1.txt  -user SYSDBA -pass masterkey /db/test1.f
db stdout  > c:\data\rembackup2.fbk
gbak: ERROR:Invalid clumplet buffer structure: string length doesn't match with clumplet
gbak:Exiting before completion due to errors

Error en la copia de seguridad-restauración en un solo paso cuando la copia de seguridad falla por alguna razón:

Code

gbak: ERROR:No request from user for stdin data
gbak:Exiting before completion due to errors

Si intenta pasar algo que no es una copia de seguridad a gbak

Code

gbak: ERROR:unavailable database
gbak:Exiting before completion due to errors
gbak: ERROR:expected backup description record
gbak:Exiting before completion due to errors

La copia de seguridad de un archivo de base de datos corrupto con la página incorrecta informará el siguiente error (el número y el archivo de base de datos diferirán, por supuesto)

Code

gbak: ERROR:database file appears corrupt (E:\DATABASE1.FDB)
gbak: ERROR:    wrong page type
gbak: ERROR:    page 9294588 is of wrong type (expected 8, found 0)
gbak: ERROR:gds_$get_segment failed
gbak:Exiting before completion due to errors
gbak: ERROR:Unexpected I/O error while reading from backup file
gbak:Exiting before completion due to errors

Contactos

No dude en contactarnos con cualquier pregunta, o informar de cualquier error o errata: [email protected]