Dicas e macetes com o gbak

O que é o gbak?
1. Dominando Backups com o Gbak
1.0 Preparação
1.1 O backup mais simples com o gbak
1.2. Backup local com a base em uso no Windows
1.3. Backup usando uma string de conexão TCP/IP
1.4. Backup rápido usando o Service Manager
1.5. Backup mais rápido usando Service Manager e sem coleta de lixo
1.6. Backup para um compartilhamento de rede
1.7. Backup simples de um servidor remoto para uma máquina local
1.8. Backup rápido de um servidor remoto para uma máquina local usando Service Manager
1.9. Backup de um servidor remoto para o mesmo servidor remoto usando Service Manager
1.10. Backup 6x mais rápido usando o HQbird
2. Restaurando com o gbak
2.1. A forma mais simples de restore
2.2. Restore usando localhost no string de conexão
2.3. Restore com XNET no Windows
2.4. Restore rápido usando o Service Manager
2.5. Opções não recomendadas
2.6. Restaurando usando alias
2.7. Restaurando um backup local para um servidor remoto
2.8. Restaurando um backup local para um servidor remoto usando Service Manager
2.9. Restaurando tabelas enormes
3. Ajustando e logando o processo de backup e restore
3.1. Gbak com verbose output
3.2. Adicionando estatísticas de performance ao verbose output
3.3. Excluir tabelas de um backup ou restore
3.4. Recuperando a senha para um backup/restore através de um arquivo
4. Backup/Restore em um único passo
5. Resumo de performance
Perguntas frequentes sobre máquinas virtuais e backups
Apêndice A. Erros durante o backup/restore

O que é o gbak?
O Gbak é uma ferramenta padrão de linha de comando doFirebird (veja a documentação oficial aqui)
projetada para executar:

1. Backup completo do banco de dados: lê todos os registros no banco de dados e armazena-os no

arquivo de backup
2. Restaurar um backup criando um novo banco de dados.

Para desenvolvedores e administradores com experiência em outros RDBMS, o termo "backup" pode ser
um pouco confuso, já que o GBAK não produz uma cópia exata do banco de dados, mas sim um arquivo
com formato próprio, contendo apenas as declarações de metadata e os dados das tabelas. Para criar um
banco de dados a partir do arquivo de backup gerado pelo gbak, o processo de restauração deve ser feito
também pelo gbak.
1. Dominando os backups com o gbak
1.0. Preparação

Vamos criar uma pasta C:\data e colocar nela alguma base de dados. Usaremos uma base de 5Gb que está
em Firebird OLTP-EMUL test, mas obviamente você pode usar sua própria base de dados, se quiser. 

Para usuários Linux – criaremos uma pasta /db e mudaremos o owner para "firebird", copiando em
seguida a base de dados para lá (tenha certeza que o owner do arquivo também seja o firebird).
mkdir /db
chown firebird -R /db

1.1 O comando mais simples de backup com o gbak

Windows
gbak -b c:\Data\test1.fdb C:\data\backup1.fbk -user SYSDBA -pass masterkey
Linux
gbak -b /db/test1.fdb /db/backup1.fbk -user SYSDBA -pass masterkey
Nesse exemplo, o gbak acessa a base de dados usando o protocolo local ou com uma conexão embedded.

Firebird 3.0: O acesso com conexão embedded é o padrão no Firebird 3.0 (quando o parâmetro
ServerMode = SuperServer no firebird.conf) e abrirá a base em modo exclusivo, portanto, outras
conexões não poderão acessar a base de dados durante esse processo (se a base já estiver em uso, o gbak
vai reportar um erro).

Firebird 2.5: No Windows usará uma conexão XNET (isso se você tiver apenas uma instância do
Firebird sendo executada, é claro). No Linux, o Firebird tentará conectar através de uma conexão
embedded, e se não conseguir, tentará automaticamente conectar usando TCP/IP. Se você não sabe o que
significa XNET, INET, etc, leia o artigo Connection Protocols in Firebird 3.

Nota 1: O comando é executado sob o usuário logado no sistema operacional (ex: o seu), usando as
permissões dele para acessar o arquivo de backup e da base de dados. Normalmente, o serviço do
Firebird no Windows roda na conta LocalSystem, e no Linux com o usuário “firebird”, mas o console é
executado geralmente com a conta do usuário logado. Se a conta do usuário não tiver permissão para
acessar a base de dados ou o path do backup, o gbak falhará com o erro “Cannot open backup file” (veja
o exemplo #5 no apêndice A deste artigo).

Note 2: gbak -b sobrescreve um arquivo de backup sem qualquer tipo de aviso, portanto, se já existir o
arquivo backup1.fbk, ele será sobrescrito.

Note 3: No Linux, esse comando do gbak criará o arquivo de backup com o owner sendo o usuário
logado.

Tempo de execução do comando: 120 segundos

1.2. Backup local com a base em uso no Windows

Esta seção é apenas para usuários do Windows!

Normalmente, precisamos realizar o backup enquanto temos conexões ativas no banco de dados, por isso,
em vez de usar uma conexão embedded, é melhor especificar explicitamente o uso do protocolo local, ou
seja, XNET, para evitar que o gbak acabe abrindo a base de dados com acesso exclusivo no Firebird 3.
Para Firebird 3.0: 

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

Para o Firebird 2.5, basta usar o string de conexão local para que ele automaticamente conecte usando
XNET:
gbak -b c:\Data\test1.fdb C:\data\backup1.fbk -user SYSDBA -pass masterkey

No Linux, o Firebird não suporta um protocolo local específico, como o XNET no Windows, por isso é
necessário usar uma conexão TCP/IP (ver seção 1.3).
Além disso, o XNET funciona apenas para a instância única do Firebird, portanto, se você executar várias
instâncias do Firebird no Windows, pode ser mais fácil usar a sequência de conexão estilo INET para
especificar a instância do servidor de destino desejado.

Tempo de execução: 139 segundos

1.3. Backup usando uma string de conexão padrão TCP/IP

É o comand do gbak mais universal para realizar um backup com a base em uso.

Windows

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

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

Neste caso, especificando o localhost: no início do caminho da base de dados, a conexão é feita através
do subsistema de rede do Firebird.
É um pouco mais lento do que o acesso local, mas funciona em todos os casos quando temos um servidor
em execução aceitando conexões.

Firebird usando porta não padrão

Se o Firebird estiver rodando em uma porta que não seja a padrão (por exemplo a 3051, ao invés da
3050), você pode fazer o backup da seguinte forma:

Windows

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

masterkey
Linux
gbak -b localhost/3051:/db/test1.fdb /db/backup1.fbk -user SYSDBA -pass masterkey
Tempo de execução: 182 segundos

1.4. Backup rápido com o Service Manager

Como poderíamos alcançar a universalidade da conexão TCP/IP, com suporte à uma porta não padrão e
ainda conseguir um backup local rápido? Vamos usar o Service Manager! O Service Manager,
resumidamente, é a maneira de executar as ferramentas padrões do Firebird dentro da engine do processo
do FB que está em execução. Observe que, no caso do Service Manager, não há necessidade de
especificar o nome do servidor no caminho para a base de dados, apenas no parâmetro -se.

Windows

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

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

Este comando usa o switch -service para especificar que queremos usar o Service Manager da instância
Firebird na porta 3050 para executar o backup.

Neste caso, o backup será realizado diretamente dentro do processo Firebird (o FB tem uma cópia do
código do gbak), e como a comunicação dentro de um processo é muito mais rápida, o backup também
será significativamente mais rápido neste caso.

Se o Firebird estiver em uma porta não padrão (por exemplo, 3051), o comando será:

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

SYSDBA -pass masterkey

Note: Há uma limitação significativa no Firebird 2.5 e firebird 3.0.0-3.0.5 (removido apenas na 3.0.6): a
o tamanho da linha de comando (incluindo todos os parâmetros e caminhos para os arquivos) deve ser
inferior a 256 caracteres.

Se você atingir esse limite, por exemplo, devido à longos caminhos para o banco de dados e/ou backup,
você pode declarar um apelido (alias) para o banco de dados no databases.conf (3.0 e superior)
ou aliases.conf (2.5):

mydb1=c:\Data\test1.fdb #Windows
ou
mydb1=/db/test1.fdb #linux

e então usar o apelido no comando anterior:

Windows

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

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

Tempo de execução: 115 segundos

1.5. A forma mais rápida de backup sem coleta de lixo

Para deixar o backup ainda mais rápido, vamos adicionar o parâmetro -g

-G(ARBAGE_COLLECT) inhibit garbage collection

O comando de backup será:

Windows

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

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

Switch -g força o Firebird a desativar a coleta de lixo para o processo de backup no arquivo do banco de
dados.
Isso não significa que as versões de registro (lixo) serão armazenadas no arquivo de backup, ma sim que
o servidor não tentará limpar o lixo existente no banco de dados durante o backup, portanto, o processo
de backup será mais rápido.

Recomendamos fortemente o uso deste parâmetro, pois acreditamos que a coleta de lixo e a limpeza
associada devem ser realizadas por sweep (gfix -sweep ou pelo sweep automático), por isso é melhor não
considerar o gbak como um substituto do sweep.

Tempo de execução: 105 segundos

1.6. Backup para um compartilhamento de rede

E se precisarmos colocar o backup em um compartilhamento de rede?

No Windows

Pode haver uma certa confusão para os novos usuários do Firebird: um backup manual (quando você
inicia o comando a partir de um prompt de comando) simplesmente com gbak -b funciona bem em um
compartilhamento de rede, mas a variação mais rápida do gbak, com -se localhost:service_mgr, não
funciona.

A razão é que o Firebird no Windows é executado sob a conta LocalSystem, que não tem acesso aos
drives mapeados da rede (a menos que esses compartilhamentos de rede estejam configurados com
acesso ao grupo "Todos", mas isso é muito perigoso nessa era de ransomwares). A solução é executar o
serviço Firebird no Windows sob uma conta com direitos suficientes para acessar o compartilhamento de
rede e, simultaneamente, direitos suficientes para acessar os arquivos de banco de dados locais e arquivos
de sistema em C:\ProgramData\Firebird. Além disso, uma boa ideia é configurar o parâmetro
RestrictAccess no firebird.conf.

No Linux

Como o Firebird no Linux é executado sob a conta "firebird", monte o compartilhamento da rede
mapeada para o usuário "firebird", assim o serviço Firebird poderá acessar o local da rede da mesma
forma que uma unidade local.

1.7. Backup simples de um servidor remoto para uma máquina local

É possível fazer backup do banco de dados do servidor remoto para a máquina local.
O comando no exemplo abaixo é executado em um computador Windows, acessa o banco de dados no
servidor Linux (com endereço IP 192.168.0.108, mas o nome de host do servidor também pode ser usado,
é claro), e o arquivo de backup é armazenado na pasta C:\Data no Windows):

gbak -b -user SYSDBA -pass masterkey 192.168.0.108:/db/test1.fdb

c:\data\remotebackup1.fbk

Tempo de execução: 568 segundos

Este comando geralmente será muito mais lento do que um backup local, porque o GBAK lê os dados do
servidor remoto e transfere os registros através da rede.

1.8. Backup mais rápido de um servidor remoto para máquina local usando o Service
Manager

O comando abaixo é mais rápido do que a forma tradicional do exemplo 1.7: 

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

Ele usa o Service Manager para fazer o backup no servidor remoto, mas a saída está sendo enviada para o
stdout e, em seguida, redirecionada para o arquivo local.
Este comando geralmente é de 15% à 20% mais rápido do que o do item #1.7, pelo seguinte:

1. Executa backup através do Service Manager no servidor remoto, para que todas as operações de
leitura e compressão sejam realizadas da maneira mais rápida.
2. Tansfere através da rede apenas o arquivo de backup resultante, com tamanho menor do que os
dados no banco de dados.

No entanto, com este comando, não é possível habilitar o modo verbose a fim de armazenar a saída
detalhada para o arquivo de log.

Tempo de execução: 473 segundos

1.9. Backup do servidor remoto para o próprio servidor remoto usando o Service
Manager

Com o Service Manager, é possível invocar o gbak do servidor remoto e armazenar o backup no mesmo
servidor.

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

/db/back12.fbk

Este comando através do Service Manager invoca o backup no servidor remoto, com a instrução de
armazenar o arquivo de backup no mesmo servidor de rede.
É claro que o local do backup deve ser acessível pelo serviço Firebird (no Linux ele é executado com o
usuário "firebird", no Windows com a conta LocalSystem).

1.10. Backup 6x mais rápido com o HQbird Enterprise

Se você ainda não está satisfeito com o desempenho do backup do gbak tradicional, considere usar a
distribuição corporativa do Firebird: HQbird.
Ela oferece backups multi-thread, o que permite operações de backup até 6x mais rápidas com gbak.

gbak -b -par 8 -se localhost:service_mgr -g C:\Data\testbigdb1.fdb

c:\Data\backup1.fbk -user SYSDBA -pass masterkey

Como você pode observar, no comando do gbak do HQBird existe um novo parâmetro -par 8, que instrui
o gbak à usar 8 threads durante o processo de backup.

2. Restaurando com o gbak

Temos o arquivo de backup backup1.fbk, criado por um dos comandos acima, e precisamos restaurá-lo,
de forma rápida e eficiente.

Vamos supor que o arquivo esteja em C:\Databackup1.fbk no caso do Windows ou /db/backup1.fbk no

caso do Linux.
2.1. Comando de restore simples

No Windows
gbak -c C:\Data\backup1.fbk C:\data\new1.fdb -user SYSDBA -pass masterkey
No Linux
gbak -c /db/backup1.fbk /db/new1.fdb -user SYSDBA -pass masterkey

Em primeiro lugar, observe que o gbak -c não substitui o arquivo do banco de dados, e se houver um
arquivo C:\datanew1.fdb ou /db/new1.fdb, o gbak retornará um erro dizendo que o banco de dados já
existe.

Esse comando atualmente funciona de forma diferente no FB 2.5/3.0+ e no Windows/Linux:

 No Linux, este comando usará acesso embedded ao banco de dados criado (se você não alterou a
ordem dos providers no em firebird.conf, é claro) tanto para 3.0 quanto 2.5.
 No Windows, no Firebird 3.0 com a ordem padrão dos providers, o acesso será embedded, e
XNET no FB 2.5.

Em seguida, este comando cria um arquivo com os direitos do usuário que rodou o gbak, isso é
especialmente importante no Linux – se você executar o gbak como root, o proprietário do arquivo de
banco de dados será o root, e o processo Firebird, que é executado sob o usuário "firebird", não poderá
acessar o arquivo restaurado.

Nota para usuários Linux

Muitas pessoas, a fim de "corrigir" a propriedade do arquivo, aplicam permissão para que todos acessem
o banco de dados restaurado, ou seja, algo como "chmod 777 basededados.fdb", mas isso é muito
inseguro! A maneira correta é mudar o proprietário do banco de dados para firebird, com o seguinte
comando:

chown firebird /db/new1.fdb

De forma geral, esse comando é suficiente para restaurar de forma simples bases de dados em servidores
que não sejam de produção (usados para teste ou desenvolvimento, por exemplo).

Tempo de execução: 275 segundos

2.2. Restore com localhost no string de conexão

O comando mais universal, mas não o mais rápido:

Windows

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

Linux

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

Porta não-padrão

Se o Firebird estiver rodando em uma porta não padrão, por exemplo, a 3051, podemos especificá-la no
comando de restore:

Windows
gbak -c C:\Data\backup1.fbk localhost/3051:C:\data\new1.fdb -user SYSDBA -pass
masterkey
Linux
gbak -c /db/backup1.fbk localhost/3051:/db/new1.fdb -user SYSDBA -pass masterkey
Tempo de execução: 1225 segundos

2.3. Restore com o XNET no Windows

Para deixar o restore mais rápido no Windows, podemos usar o XNET (para o Firebird 3.0 ou superior):
gbak -c C:\Data\backup1.fbk xnet://C:\Data\New2.fdb -user SYSDBA -pass masterkey
No Firebird 2.5 no Windows, o acesso via XNET pode ser obtido simplesmente com o comando abaixo
(se houver apenas uma instância do Firebird em execução):
gbak -c C:\Data\backup1.fbk C:\data\new1.fdb -user SYSDBA -pass masterkey
Tempo de execução: 585 segundos

2.4. Restore mais rápido com o Service Manager

A forma mais rápida de restaurar um backup é usando o Service Manager

Windows

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

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

Com o switch -se, invocamos o Service Manager no endereço localhost de forma que o processo de
restore seja executado dentro da engine do Firebird.

Quando a restauração for feita pelo Service Manager, o arquivo de banco de dados criado será de
propriedade da conta vinculada ao processo do Firebird – ele é "firebird" no Linux e LocalSystem no
Windows.

Tempo de execução: 244 segundos

2.5. Parâmetro não recomendado

Em algum momento você pode ficar tentado a usar o seguinte parâmetro:

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

para forçar a substituição de uma base existente por uma nova.

Em nossa experiência, essa mudança aumenta consideravelmente as chances de substituir acidentalmente

o banco de dados de produção.

Recomendamos fortemente restaurar o banco de dados sempre com um novo nome e renomeá-lo, bem
como excluir o banco de dados antigo, explicitamente.

Nem vamos fornecer o exemplo do comando com este switch :-)

2.6. Restaurando usando alias

É possível restaurar a base de dados usando um alias declarado no databases.conf (ou no aliases.conf se
for o Firebird 2.5)

Por exemplo temos a seguinte declaração:

restdb=c:\Data\newrest1.fdb #Windows
restdb=/db/newrest1.fdb #Linux

Podemos restaurar a base usando o alias, através dos comandos abaixo:

Windows

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

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

2.7. Restaurar backup local em servidor remoto

É possível restaurar o arquivo de backup local para um servidor firebird remoto.

Neste exemplo, restauramos o arquivo de backup armazenado localmente no Windows, para o servidor
Linux (endereço IP 102.168.0.108):

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

Tempo de execução: 7009 segundos

Como podemos observar, o processo é bem lento.

Será que podemos acelera-lo com o uso do Service Manager?

2.8. Restaurar backup local em servidor remoto com o Service Manager

Para resturar um backup local em um servidor remoto com o Service Manager, é necessário usar um
macete através do stdin:
gbak -c -se 192.168.0.108:service_mgr -user SYSDBA -pass masterkey stdin
/db/new3.fdb < C:\Data\backup1.fbk

Este comando invoca a restauração no servidor remoto usando a entrada padrão stdin como fonte de
dados do backup – e fornece os dados através da parte < C:\Databackup1.fbk do comando.

Parece um pouco complicado? Mas é uma maneira fácil de aumentar 10x o desempenho do gbak para
restaurar em um servidor remoto!

Tempo de execução: 450 segundos

2.9. Restaurar tabelas enormes

Se você tem um banco de dados muito grande, com o número total de linhas superiores a 2 bilhões, é
necessário especificar o parâmetro -o[ne_at_a_time], para restaurar cada tabela em uma transação
separada, evitando um internal overflow.
gbak -c -se localhost:service_mgr -one C:\Data\backup1.fbk C:\data\new44.fdb -user
SYSDBA -pass masterkey

3. Ajustando e logando os processos de backup e restore

3.1. Gbak com verbose output

Por padrão, gbak é uma ferramenta "silenciosa", ele não retorna nada em caso de execução bem sucedida.
Para torná-lo mais "falante", podemos adicionar o switch -v[erify]

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

-pass masterkey

Como resultado, haverá mais detalhes apresentados. Há um efeito colateral: a saída de impressão para o
console pode tornar o processo de backup com a opção verbose significativamente mais lento do que a
variante silenciosa, então uma boa ideia será enviar a saída para o arquivo, através do parâmetro -y
logfile:

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

-pass masterkey -y C:\data\backuplog1.txt

Nota 1: O gbak não substituirá o arquivo de registro existente! Se você já tiver C:\databackuplog1.txt
neste exemplo, o backup vai retornar um erro (veja o item #3 no apêndice A).
Nota 2: existe opção -verbint para controlar o intervalo em que é relatado o número de registros
processados durante o backup ou restauração.

3.2. Adicionar estatísticas de performance na saída

Na saída verbose do gbak para um backup ou restore, podemos ver mensagens como está:

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

para cada tabela ou objeto da base de dados.
Pode ser interessante descobrir quais tabelas/objetos consomem a maior parte do tempo, correto?

Para isso, é necessário usar o parâmetro -st(atistics):

-ST(ATISTICS) TDRW show statistics:

T time from start
D delta time
R page reads
W page writes
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
Quando usada, adicionará ao log as seguintes colunas:
gbak: time delta reads writes
Com isso, saberemos o tempo e a I/O gasta em cada linha.

3.3. Excluir tabelas no backup ou restore

Se você acha que algumas tabelas podem ser excluídas do backup (um bom exemplo é uma tabela de log
de auditoria muito longa), pode especificá-las no parâmetro SK[IP_DATA], que inclusive aceita
expressões regulares.

No exemplo abaixo, excluímos dados das tabelas COUNTRY e JOB no backup executado:
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

No exemplo abaixo, excluímos a tabela o CLIENT na restauração:

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

Observe que o parâmetro para SKIP_DATA deve ser transmitido como um único parâmetro, por isso
deve estar entre aspas! No Linux, as aspas devem ser simples, no Windows – duplas.

Precauções ao excluir tabelas no backup/restore

Recomendamos testar fortemente a condição de expressão regular antes de usá-la, com a seguinte query –
ela retornará uma lista de tabelas que correspondem à condição do filtro (nas queries, as aspas são sempre
simples)

SQL> SELECT RDB$RELATION_NAME FROM RDB$RELATIONS WHERE TRIM(RDB$RELATION_NAME)

SIMILAR TO '(COUNTRY|JOB)';

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

Observe que os dados das tabelas durante o backup ou restore serão excluídos independentemente das
restrições existentes (Foreign Keys), portanto, se você não planejou tal exclusão cuidadosamente, será
fácil obter o erro "Cannot commit foreign key index" durante o processo de restauração.

3.4. Obter a senha através de um arquivo

Se não for um grande fã da ideia de expor a senha à todos que vêem seus comandos, irá gostar da
seguinte switch:  -fetch passwordfile

Vamos criar o arquivo com a senha em C:\Datapassfile.txt e usá-lo para passar a senha para o gbak:

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

C:\Data\passfile.txt
Há 2 benefícios práticos:

1. Se armazenarmos uma senha em um único arquivo, podemos garantir que todos os nossos
arquivos de scripts sempre usarão a senha real.
2. A senha não fica exposta em todos os arquivos de script

4. Backup restore em um único passo

Muitas vezes, o objetivo do backup é ser seguido por uma restauração imediata, a fim de obter um novo
banco de dados, por exemplo, para mudar o tamanho de página, ou migrar o banco de dados existente da
2.5 para 3.0. Neste caso, é possível realizar o backup e o restore em um único passo, usando a entrada e a
saída padrão como fontes para os comandos apropriados. Sendo assim, não haverá a criação de um
arquivo de backup intermediário, reduzindo os requisitos de espaço livre e acelerarando o processo.

O comando é o seguinte:

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
Em essência, temos dois comandos unidos pelo símbolo |, o primeiro para realizar o backup para a stdout:
gbak -b -se localhost:service_mgr -g -user SYSDBA -password masterkey
C:\Data\test1.fdb stdout
e o segundo, para restaurar da stdin:
gbak -c -se localhost:service_mgr -user SYSDBA -password masterkey stdin
C:\Data\new10.fdb

Este comando é a maneira mais rápida de fazer backup/restore na mesma instância Firebird.
Obs: para converter um bancos de dados da versão 2.5 para a 3.0 é necessário usar 2 instâncias do
Firebird, consulte detalhes aqui.

5. Resumo de performance
A figura a seguir contém informações sobre a velocidade de diferentes comandos de backup local da base
de dados de teste:

Como você pode ver, a maneira mais rápida de fazer backup local é usar o Service Manager (switch
-se[rvice]) e inibir a coleta de lixo (switch -ig).

Para o backup do servidor remoto para a máquina local, o Service Manager também é a melhor opção:
A situação em relação ao desempenho de restauração é semelhante: o Service Manager é a maneira mais
rápida de restaurar.

Quanto ao caso bastante raro, quando a restauração é feita do backup local para um servidor remoto, usar
o Service Manager com o truque da stdin é a única escolha viável:

Perguntas frequentes sobre máquinas virtuais e backups

Por que eu deveria usar ferramentas de backup firebird, quando há ferramentas de backup populares
disponíveis que prometem fazer backup de tudo?

Faço backup da imagem completa da Máquina Virtual, por que eu deveria me preocupar com backup do
banco de dados Firebird?

Appendix A. Erros durante um backup/restore

1) Uma tentativa de executar o gbak sem parâmetros ou com um usuário que não é o proprietário do
banco de dados/SYSDBA resultará no seguinte erro:

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

2) Se você especificar a senha errada, obterá o seguinte erro:

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

3) Erro quando você especifica um arquivo existente como destino para o verbose

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

4) Erro quando se tenta restaurar um backup em cima de uma base já existente

gbak: ERROR:database C:\data\new1.fdb already exists. To replace it, use the -REP
switch
gbak: Exiting before completion due to errors
5) Erro ao tentar gerar o backup em um local onde não se tem permissão de escrita.
gbak: ERROR:cannot open file /db/test1.fbk
gbak: Exiting before completion due to errors

6) Quando o gbak tenta acessar um arquivo que não tem permissão – por exemplo, o arquivo tem um
owner diferente do firebird no Linux

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
7) Tentativa de usar saída verbose
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
8) Tentativa de fazer um backup via Service Manager em um servidor remoto com a opção verbose
ligada e armazenando a saída em um arquivo de log.
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
9) Erro "genérico" durante um backup/restore em um único passo:
gbak: ERROR:No request from user for stdin data
gbak: Exiting before completion due to errors
10) Se estiver tentando passar um arquivo que não seja de backup para o gbak restaurar
gbak: ERROR:unavailable database
gbak: Exiting before completion due to errors
gbak: ERROR:expected backup description record
gbak: Exiting before completion due to errors
11) Backup de uma base que está corrompida (wrong page):
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