Guia Rápido para Backup-Restauração com Gbak

O que é gbak?

Gbak é uma ferramenta padrão de linha de comando do Firebird (veja sua documentação oficial aqui), projetada para realizar 1) backup completo do banco de dados: ela lê cada registro no banco de dados e os armazena no arquivo de backup, 2) restauração do backup para um novo banco de dados.

Para desenvolvedores e administradores com experiência em outros SGBDs, o termo “backup” pode ser um pouco confuso, pois o gbak não produz uma cópia exata do banco de dados, mas sim um arquivo em formato não-database, apenas com dados (os índices são armazenados como declarações).

Para criar um banco de dados a partir do arquivo de backup do gbak, o processo de restauração com gbak deve ser executado.

1. Dominando backups com Gbak

1.0. Preparação

Vamos criar a pasta C:\data e colocar algum banco de dados nela. Usaremos um banco de dados de 5Gb do teste Firebird OLTP-EMUL, mas você pode usar seu próprio banco de dados, é claro.

Para usuários Linux - vamos criar a pasta /db e alterar seu proprietário para “firebird”, e copiar o banco de dados para lá (certifique-se de que o proprietário também seja firebird).

Code

mkdir /db
chown firebird -R /db

1.1 O backup Firebird mais simples com o 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

Neste exemplo, a ferramenta gbak acessa o arquivo do banco de dados usando acesso local ou embutido.

Firebird 3.0: O acesso embutido na configuração padrão do Firebird 3.0 (com o parâmetro ServerMode = SuperServer no firebird.conf) tentará colocar um bloqueio exclusivo no banco de dados, então outras conexões não conseguirão acessar o banco de dados (ou a tentativa do gbak falhará devido às conexões ativas).

Firebird 2.5: Com Firebird 2.5 no Windows, o comando funcionará bem através do protocolo XNET (se você tiver apenas uma instância do Firebird em execução, é claro). No Linux, o Firebird tentará usar acesso embutido; se não estiver acessível, ele tentará automaticamente (e implicitamente) conectar via TCP/IP. (Se você não sabe o significado de XNET, INET, etc., consulte o Guia de Referência de Strings de Conexão do Firebird).

Nota 1: Este comando é executado sob a conta do usuário do SO (ou seja, a sua), e usa suas permissões para acessar os arquivos de backup e do banco de dados.

Normalmente, o serviço Firebird no Windows é executado com a conta LocalSystem, e no Linux sob o usuário “firebird”, mas o console geralmente é executado sob sua própria conta de usuário.

Se essa conta de usuário não tiver acesso ao caminho do banco de dados ou ao caminho do backup, o gbak falhará com o erro “Cannot open backup file” (veja o exemplo no Apêndice A. Erros, #5).

Nota 2: gbak -b sobrescreve silenciosamente o arquivo de backup. Portanto, se você já tiver backup1.fbk, ele será sobrescrito.

Nota 3: No Linux, este comando gbak criará um arquivo de backup com o proprietário igual ao usuário do console.

Tempo de backup para este comando: 120 segundos

1.2. Backup local com gbak que pode ser feito online no Windows

Esta seção é apenas para usuários Windows! Normalmente, precisamos realizar o backup enquanto temos conexões ativas com o banco de dados, então em vez de conexão embutida, é melhor especificar explicitamente o protocolo local para evitar colocar bloqueio exclusivo no arquivo do banco de dados pelo próprio gbak no Firebird 3, ou seja, 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 uma string de conexão local, e ela usará XNET também:

Code

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, então é necessário usar string de conexão TCP/IP (veja a seção 1.3).

Além disso, o XNET funciona apenas para uma única instância do Firebird, então se você executar várias instâncias do Firebird no Windows, pode ser mais fácil usar uma string de conexão estilo INET para especificar a instância do servidor de destino.

Tempo de backup: 139 segundos

1.3. Backup com gbak com string de conexão TCP/IP

Este é o comando gbak mais universal, para realizar backup online.

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

Neste caso, ao especificar localhost: no início do caminho do banco de dados, a conexão é feita através do subsistema de rede do Firebird.

É ligeiramente mais lento que o acesso local, mas funciona em todos os casos em que temos um servidor em execução que aceita conexões.

Porta não padrão para Firebird

Se você tiver o Firebird executando em uma porta não padrão (por exemplo, 3051 em vez de 3050), você pode fazer o backup desta forma:

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

Tempo de backup: 182 segundos

1.4. Backup mais rápido com gbak com Service Manager

Como podemos alcançar a universalidade da conexão TCP/IP, com suporte a porta não padrão, e backup local rápido? Vamos usar o Service Manager! O Service Manager, em palavras simples, é a forma de executar ferramentas padrão através do mecanismo do Firebird. Observe que, no caso do Service Manager, não há necessidade de especificar o nome do servidor no caminho do banco de dados, apenas no 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 a opção -service para especificar que queremos usar o Service Manager da instância do Firebird na porta 3050 para realizar o backup.

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

Se o Firebird estiver executando em porta não padrão (por exemplo, 3051), o comando pode ser assim:

Code

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

Nota: Há uma limitação significativa no Firebird 2.5 e Firebird 3.0.0-3.0.5 (removida apenas no 3.0.6): a linha de comando (todos os parâmetros e caminhos para o banco de dados e para o backup) deve ter menos de 256 caracteres.

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

Code

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

Code

mydb1=/db/test1.fdb  #linux

e então usá-lo em nosso 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

Tempo de backup: 115 segundos

1.5. O backup mais rápido com gbak com coleta de lixo inibida

Para tornar o backup ainda mais rápido, vamos adicionar a opção -g

Code

 -G(ARBAGE_COLLECT)    inibir coleta de lixo

Então, o comando de backup será o seguinte

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

A opção -g força o mecanismo do Firebird a desabilitar a coleta de lixo para o processo de backup no arquivo do banco de dados.

Isso não significa que versões de registros de lixo serão armazenadas no arquivo de backup; significa que o servidor não tentará limpar o lixo existente no banco de dados durante o backup, e o backup será mais rápido.

Recomendamos fortemente o uso desta opção, pois acreditamos que a coleta de lixo e a limpeza associada devem ser feitas pelo sweep (gfix -sweep ou autosweep), então é melhor não considerar o gbak como qualquer tipo de alternativa ao sweep.

Tempo de backup: 105 segundos

1.6. Backup para compartilhamento de rede ou localização de rede

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

No Windows

A confusão frequente de novos usuários do Firebird: backup manual (quando você inicia o comando a partir de um prompt de comando), com gbak -b simples, para o compartilhamento de rede funciona bem, mas a versão 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 a locais de rede (a menos que esses compartilhamentos de rede tenham acesso configurado para o grupo “Everyone”, mas isso é muito, muito perigoso em nossa era de ransomware).

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 locais do banco de dados e os arquivos do 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 de rede com mapeamento para o usuário “firebird”, para que o serviço Firebird possa acessar o local de rede da mesma forma que uma unidade local.

1.7. Backup simples do servidor remoto para a máquina local

É possível fazer backup do banco de dados do servidor remoto para a máquina local.

O exemplo de comando abaixo é iniciado em um computador Windows, acessa o banco de dados no servidor Linux (com endereço IP 192.168.0.108, mas o nome do host do servidor também pode ser usado, é claro), e o arquivo de backup é armazenado na pasta C:\Data no Windows):

Code

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

Tempo de backup: 568 segundos

Este comando geralmente será muito mais lento do que o backup local, porque o gbak lê os dados do servidor remoto e transfere os registros pela rede.

1.8. Backup mais rápido do servidor remoto para o local com o Service Manager

O comando abaixo é mais rápido do que o backup tradicional do servidor remoto para a máquina local, descrito na seção #1.7

Code

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 é enviada para o pipe stdout e depois redirecionada para o arquivo local.

Este comando é geralmente 15%-20% mais rápido do que o da seção #1.7 (Backup simples do servidor remoto para o local), devido ao seguinte:

ele executa o backup através do Service Manager no servidor remoto, então todas as operações de leitura e compactação são realizadas da maneira mais rápida,
ele transfere pela 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 ativar o modo verboso e armazenar a saída detalhada no arquivo de log.

Tempo de backup: 473 segundos

1.9. Backup do banco de dados Firebird no servidor remoto para o mesmo servidor remoto usando o Service Manager

Com o Service Manager, é possível invocar o backup gbak do banco de dados no servidor remoto e armazená-lo também no mesmo servidor remoto.

Code

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 também no mesmo servidor de rede.

É claro que o local do backup deve ser acessível pelo serviço Firebird (no Linux ele é executado como usuário “firebird”, no Windows como conta LocalSystem).

1.10. Backup do banco de dados Firebird 6x mais rápido com backup multi-thread no Firebird 5 (ou HQbird 2.5/3.0/4.0/5.0)

Se você ainda não está satisfeito com o desempenho de backup do gbak do Firebird, considere migrar para o Firebird 5 (ou use a distribuição empresarial do Firebird: HQbird para outras versões).

Ele suporta backup multi-thread, que permite operações de backup até 6x mais rápidas com o gbak.

Code

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

Como você pode ver, há um novo parâmetro -par 8, que faz o gbak usar 8 threads para criar um backup.

O HQbird executa tarefas de manutenção (sweep, backup, restore) muito mais rapidamente (os resultados na figura abaixo são de um banco de dados diferente, é claro):

2. Restore com a ferramenta 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:\Data\backup1.fbk no caso do Windows, ou /db/backup1.fbk no caso do Linux.

2.1. O comando de restore mais simples

No Windows

Code

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

No Linux

Code

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

Primeiro de tudo, observe que o gbak -c não sobrescreve o arquivo do banco de dados, e se existir o arquivo C:\data\new1.fdb ou /db/new1.fdb, o gbak retornará um erro informando que o banco de dados já existe.

Além disso, este comando funciona de maneira muito diferente nas versões 2.5/3.0+ e no Windows/Linux.

No Linux, este comando usará acesso embutido ao banco de dados criado (se você não alterou a ordem dos provedores Firebird no firebird.conf, é claro) tanto para 3.0 quanto para 2.5.

No Windows, no Firebird 3.0 com a ordem padrão de provedores, será acesso embutido; na versão 2.5 - XNET.

Então, este comando cria um arquivo com os direitos do usuário que iniciou o gbak. Isso é especialmente importante no Linux - se você executar esse gbak como root, o proprietário do arquivo do banco de dados será root, e o processo Firebird, que é executado sob o usuário “firebird”, não conseguirá acessar o arquivo restaurado.

Nota para usuários Linux

Muitas pessoas, para “corrigir” a propriedade, aplicam permissão para todos acessarem o banco de dados restaurado, ou seja, algo como “chmod 777 database”, mas isso é muito inseguro. A maneira correta é alterar o proprietário do banco de dados para firebird, com o seguinte comando:

Code

chown firebird /db/new1.fdb

Em geral, este comando é bom o suficiente para o restore simples de bancos de dados não produtivos (usados para testes ou em desenvolvimento).

Tempo de restore: 275 segundos

2.2. Restore com string de conexão localhost

A opção de restore mais universal, mas não a mais rápida, é a seguinte:

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

Porta não padrão

Se o Firebird estiver rodando em uma porta não padrão, por exemplo, 3051, ela pode ser especificada no comando de restore:

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

Tempo de restore: 1225 segundos

2.3. Restore com XNET no Windows

Para tornar o restore um pouco mais rápido, no Windows podemos usar XNET (para Firebird 3.0 e superior):

Code

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

No Firebird 2.5 no Windows, o acesso XNET será usado com o comando de linha simples (se houver apenas uma instância do Firebird em execução):

Code

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

Tempo de restore: 585 segundos

2.4. Restore mais rápido com o Service Manager

E a maneira mais rápida de restaurar é usar o 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

Com a opção -se, invocamos o Service Manager no endereço localhost e instruímos ele a executar o código de restore dentro do mecanismo Firebird.

Quando o restore é feito pelo Service Manager, o arquivo do banco de dados criado será de propriedade da conta da instância Firebird em execução (processo) - é “firebird” no Linux e LocalSystem no Windows.

Tempo de restore: 244 segundos

2.5. Opção não recomendada

Em algum momento, você pode ter a tentação de usar a seguinte opção:

Code

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

Code

para forçar a substituição do banco de dados existente pelo novo.

Em nossa experiência, esta opção aumenta muito as chances de sobrescrever 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.

Nós nem forneceremos o exemplo do comando com esta opção.

2.6. Restore do banco de dados usando alias

É possível restaurar o banco de dados usando o alias, declarado no databases.conf (ou aliases.conf no Firebird 2.5)

Por exemplo, temos a seguinte declaração:

Code

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

restdb=/db/newrest1.fdb  #Linux

Então podemos executar o seguinte comando para restaurar o backup para o caminho especificado pelo 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. Restore do backup local para o servidor remoto

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

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

Code

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

Tempo de restore: 7009 segundos

Como você pode notar, o processo de restore remoto funciona muito lentamente. Podemos acelerá-lo com o Service Manager?

2.8. Restore do backup local para o servidor remoto com o Service Manager

Para restaurar o backup local no servidor remoto com o Service Manager, é necessário fazer o truque com o fluxo 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 o restore no servidor remoto com a entrada padrão stdin como fonte do backup - e fornece a entrada usando a parte < C:\Data\backup1.fbk do comando.

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

Tempo de restore: 450 segundos

2.9. Restore de tabelas extremamente longas

Se você tem um banco de dados realmente grande com o número total de linhas superior a 2 bilhões, é necessário especificar a opção -o[ne_at_a_time], para restaurar cada tabela em uma transação separada, para evitar algum estouro interno.

Code

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

3. Ajustes e registro de logs dos processos de backup e restore

3.1. Gbak com saída verbosa

Por padrão, o gbak é uma ferramenta muito silenciosa, não retorna nada em caso de execução bem-sucedida. Para torná-lo verboso, podemos adicionar a opção -v[erify]

Code

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

Como resultado, haverá mais detalhes. O problema menor, mas irritante, é que imprimir a saída no console pode tornar o backup verboso significativamente mais lento do que a variante silenciosa, então uma boa ideia será salvar o log no arquivo com a opção - 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: o gbak não sobrescreverá o arquivo de log existente! Se você já tem C:\data\backuplog1.txt neste exemplo, o backup gerará um erro (veja #3 no Apêndice A).

Nota 2: existe a opção -verbint para controlar o intervalo de relatório do número de registros processados durante o backup ou restore.

3.2. Adicionar estatísticas de desempenho à saída verbosa

Na saída verbosa do gbak para backup e restore, podemos ver mensagens como estas:

Code

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

para cada tabela e outros objetos do banco de dados.

É interessante descobrir quais tabelas/objetos consomem mais tempo, certo?

Para isso, é necessário usar a opção -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

Quando aplicada, ela adicionará ao log as seguintes colunas:

Code

gbak: time   delta  reads  writes

para que possamos ver o tempo e a E/S gastos em cada linha.

3.3. Excluir tabelas do backup e/ou do restore

Se você acha que algumas tabelas podem ser excluídas do backup (um bom exemplo é uma tabela de log muito longa), você pode especificá-las no parâmetro SK[IP_DATA], com expressão regular como parâmetro.

No exemplo abaixo, excluímos os dados das tabelas COUNTRY e JOB do backup:

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

E, no exemplo abaixo, excluímos a tabela CLIENT da restauração:

Code

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, portanto, deve estar entre aspas!

No Linux, as aspas devem ser simples; no Windows, duplas.

Precauções ao excluir tabelas do backup e/ou restauração

Recomendamos fortemente verificar a condição da expressão regular antes de usá-la, com a seguinte consulta - ela retornará uma lista de tabelas que correspondem à condição do filtro (na consulta, as aspas são sempre simples):

Code

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

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

Observe que as tabelas do backup ou da restauração serão excluídas independentemente das restrições existentes (chaves estrangeiras). Portanto, se você não planejou essa exclusão cuidadosamente, é muito fácil receber o erro “Cannot commit foreign key index” durante o processo de restauração.

3.4. Obter a senha para backup ou restauração a partir de um arquivo

Se você não é um grande fã da ideia de expor a senha para todos que veem seus comandos, você vai gostar do seguinte parâmetro: -fetch passwordfile

Vamos criar o arquivo com a senha em C:\Data\passfile.txt e usá-lo (aqui usamos uma variante embarcada bem simples; é claro que o parâmetro também funcionará com o Service Manager):

Code

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

Há 2 benefícios práticos:

Se armazenarmos a senha em um único arquivo, podemos garantir que todos os nossos arquivos de comando sempre usarão a senha atual.
Não expomos a senha em todos os arquivos de comando.

4. Backup-restauração em uma única etapa

Frequentemente, o objetivo do backup é realizar a restauração imediata, para obter um novo banco de dados limpo, por exemplo, para aplicar um novo tamanho de página para o banco de dados, ou para migrar o banco de dados existente da versão 2.5 para a 3.0.

Nesse caso, é possível realizar o backup-restauração com um único comando, usando a entrada e saída padrão como fontes para os comandos apropriados, evitando a criação do arquivo de backup intermediário, reduzindo os requisitos de espaço livre e acelerando o processo.

O comando é o seguinte:

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

Em essência, aqui fazemos 2 comandos, unidos pelo símbolo |,

o primeiro para backup em stdout:

Code

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

e o segundo, para restauração a partir de stdin:

Code

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-restauração na mesma instância do Firebird.

Observe: para converter bancos de dados com backup-restauração em uma única etapa da versão 2.5 para a 3.0, é necessário usar 2 instâncias do Firebird, veja os detalhes aqui.

5. Resumo de desempenho

A figura a seguir contém informações sobre a velocidade de diferentes comandos de backup local do banco de dados de teste:

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

Para o backup do servidor remoto para a máquina local, o Service Manager também é a melhor opção:

A situação com o desempenho da 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 o servidor remoto, usar o Service Manager com o truque do stdin é a única escolha viável:

Pergunta Muito Frequente sobre VM e Backups do Firebird

Por que devo usar as ferramentas de backup do Firebird, quando existem ferramentas de backup populares disponíveis que prometem fazer backup de tudo?

Ou: eu faço backup da imagem completa da Máquina Virtual, por que devo me preocupar com o backup do banco de dados Firebird?

A resposta está aqui.

Apêndice A. Erros durante backup/restauração

Uma tentativa de executar o gbak sem parâmetros, ou com um usuário que não seja o proprietário do banco de dados/não-SYSDBA, levará ao seguinte erro:

Code

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

Se você especificar a senha errada, ocorrerá o seguinte erro:

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

O erro ocorre quando o arquivo existente é especificado como destino do log detalhado:

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

O erro ocorre se o banco de dados existente for especificado no comando de restauração do 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

O erro ocorre quando o gbak tenta gravar um backup no local onde não tem direitos suficientes para gravar.

Code

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

Quando o gbak tenta acessar o arquivo sem permissão para fazê-lo - por exemplo, o arquivo tem outro proprietário que não o usuário “firebird” no 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

Tentativa de usar saída detalhada:

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

Tentativa de fazer backup com o Service Manager no servidor remoto com saída detalhada habilitada e armazenamento no arquivo de log.

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

Erro no backup-restauração em uma única etapa quando o backup falha por algum motivo:

Code

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

Se você estiver tentando passar um não-backup para o 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

O backup de um arquivo de banco de dados corrompido com a página errada relatará o seguinte erro (o número e o arquivo do banco de dados serão diferentes, é claro):

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

Contatos

Sinta-se à vontade para entrar em contato conosco com qualquer dúvida, ou relatar quaisquer erros ou erros de digitação: [email protected]