Backup Banco de Dados: Guia Técnico para Firebird, SQL Server, MySQL, PostgreSQL e Oracle

Mas Maurício, o sistema faz backup todo dia — está tudo certo, né?

Quem dera. Essa é a frase que mais ouço antes de um problema virar catástrofe. O sistema agenda o backup, o relatório diz “OK”, mas ninguém testou o restore. Aí chega o dia do aperto — HD queimado, ransomware, troca de servidor — e o arquivo de backup abre corrompido, ou pior: está vazio.

A real é que backup banco de dados (ou becape do banco) é diferente de copiar arquivos comuns. Banco de dados em uso tem transações em aberto, índices na memória, arquivos de log ativos. Você não pode simplesmente copiar o .fdb ou o .mdf com o banco rodando — o resultado quase sempre é um arquivo inútil na hora que mais precisar.

Neste guia, vou cobrir os cinco SGBDs que mais aparecem nos sistemas das empresas que atendemos: Firebird, SQL Server, MySQL, PostgreSQL e Oracle. Em cada um: o comando correto, o restore na prática e o ponto de atenção que ninguém conta.

Se você ainda está construindo o conceito de por que backup importa, recomendo começar pelo o que é backup antes de continuar aqui.

Por que copiar o arquivo do banco em uso não funciona?

Cada banco de dados mantém um estado interno consistente em memória — páginas sujas, transações em aberto, log de transações que ainda não foi sincronizado com o arquivo em disco. Quando você copia o arquivo físico com o banco em uso, você congela esse estado no meio do caminho.

O resultado? Um arquivo que abre com erro de integridade, tabelas faltando registros das últimas horas, ou simplesmente não abre. Já vi isso acontecer mais de uma vez com clientes que “faziam backup há anos” e descobriram na pior hora que não tinham nada.

A solução é sempre usar o utilitário nativo do SGBD. Esses utilitários sabem como exportar o banco de forma consistente, finalizando transações pendentes e garantindo que o arquivo gerado pode ser restaurado em outro servidor sem surpresas.

A tabela abaixo resume os cinco SGBDs e seus utilitários:

Como fazer backup no Firebird (gbak)?

O Firebird é o banco de dados que mais vejo em sistemas ERP brasileiros — especialmente sistemas desenvolvidos em Delphi. Ele armazena tudo em um único arquivo .fdb (ou .gdb em versões antigas), o que parece simples mas esconde uma armadilha: esse arquivo não pode ser copiado diretamente com o banco em uso.

A ferramenta correta é o gbak. Ela faz um backup lógico completo — exporta estrutura e dados, valida o banco durante o processo, e gera um arquivo .gbk que pode ser restaurado em qualquer servidor com Firebird na mesma versão ou mais recente.

Existe também o nbackup, que faz cópia física incremental. O problema: se o processo for interrompido por qualquer motivo, o banco fica em modo delta e começa a acumular mudanças indefinidamente, sem jamais concluir. Já vi banco parar por isso. Fique com o gbak.

O fluxo correto na WSpeed é: colocar o banco em shutdown seguro via gfix, copiar o arquivo para uma pasta temporária, reativar o banco (tempo de indisponibilidade: segundos), rodar o gbak sobre a cópia. O banco volta rápido e o backup acontece sem pressa na cópia fora da produção.

E se a sua ferramenta de backup usa VSS (Volume Shadow Copy)? Ela copia o .fdb num estado crash-consistent — ou seja, não corrompe o banco em produção, como se fosse uma foto do exato instante. Não é o ideal: o Firebird não é “VSS-aware”, então o backup vem cru e o restore depende da recuperação automática do banco. Serve de plano B; o caminho seguro continua sendo o gbak.

Backup (comando essencial):

:: Coloca o banco em shutdown controlado (espera até 100s pelas transações)
gfix -sh -tr 100 -fo 100 -user SYSDBA -pas masterkey localhost:C:\Dados\Sistema.fdb

:: Copia o arquivo para pasta temporária
copy C:\Dados\Sistema.fdb C:\WSPEED\BACKUP\Validar\Sistema.gdb

:: Reativa o banco imediatamente
gfix -online normal -user SYSDBA -pas masterkey localhost:C:\Dados\Sistema.fdb

:: Roda o gbak sobre a cópia (banco já está online de novo)
gbak -backup -v -ig -y C:\WSPEED\BACKUP\Logs\backup.txt ^
  localhost:C:\WSPEED\BACKUP\Validar\Sistema.gdb ^
  C:\WSPEED\BACKUP\Sistema-backup.gbk

Restore (gbak restore):

set GBAK="C:\Program Files (x86)\Firebird\Firebird_2_5\bin\gbak"
set ISC_USER=SYSDBA
set ISC_PASSWORD=masterkey

%GBAK% -c -r -user %ISC_USER% -pas %ISC_PASSWORD% -p 8192 -v ^
  C:\WSPEED\BACKUP\Sistema-backup.gbk ^
  localhost:C:\WSPEED\RESTORE\SistemaRestaurado.gdb

O parâmetro -p 8192 define o page size em 8 KB — padrão moderno para Firebird 2.5+. O -c cria um banco novo a partir do backup; o -r substitui se já existir.

Como fazer backup no SQL Server (sqlcmd)?

O SQL Server da Microsoft usa três tipos de arquivo: o .mdf (dados primários), o .ndf (dados secundários, opcional) e o .ldf (log de transações). Para um backup consistente, você precisa capturar todos eles juntos — e o comando nativo BACKUP DATABASE faz isso de forma atômica.

A vantagem do SQL Server: você pode rodar o backup com o banco 100% online. Nenhum downtime.

Pra ir além do full: o SQL Server também faz backup diferencial e de log de transações. Com o banco em recovery model FULL, o backup de log habilita o point-in-time recovery — voltar ao minuto antes do desastre. E, se a sua ferramenta usa VSS, é o SQL Writer Service que garante a consistência com a aplicação.

Script SQL para backup de todos os bancos de dados (salve como TodasBases.sql):

DECLARE @path NVARCHAR(512)
SET @path = 'C:\WSPEED\Backup\'

DECLARE @name NVARCHAR(256)
DECLARE @fileName NVARCHAR(512)
DECLARE @dia NVARCHAR(512)
DECLARE @fileDate NVARCHAR(40)

SELECT @fileDate = CONVERT(NVARCHAR(20), GETDATE(), 112)
SELECT @dia = DATENAME(WEEKDAY, GETDATE())

DECLARE db_cursor CURSOR READ_ONLY FOR
  SELECT name FROM master.sys.databases
  WHERE name NOT IN ('master','model','msdb','tempdb')
  AND state = 0
  AND is_in_standby = 0

OPEN db_cursor
FETCH NEXT FROM db_cursor INTO @name

WHILE @@FETCH_STATUS = 0
BEGIN
  SET @fileName = @path + @name + '_' + @dia + '.BAK'
  BACKUP DATABASE @name TO DISK = @fileName
    WITH FORMAT, MEDIANAME = @name, NAME = @name, COMPRESSION
  FETCH NEXT FROM db_cursor INTO @name
END

CLOSE db_cursor
DEALLOCATE db_cursor

Chame o script via sqlcmd (salve como BackupSQL.bat):

@echo off
set servidor=NOME-DO-SERVIDOR
set login=usuario_backup
set senha=SuaSenha

SQLCMD -S %servidor% -U %login% -P %senha% -b -i TodasBases.sql
:: Para autenticação Windows integrada (sem login/senha):
:: SQLCMD -S %servidor% -E -b -i TodasBases.sql

Restore em outro servidor (ponto de atenção: você precisa informar os caminhos dos arquivos .mdf e .ldf no servidor de destino):

set ARQUIVO=C:\WSPEED\BACKUP\MinhaBase_Sexta.BAK
set BASE=MinhaBase
set BASEINTERNA=DADP
set DESTINO=C:\SQLSERVER\

SQLCMD -S %servidor% -Q "RESTORE DATABASE %BASE% FROM DISK = '%ARQUIVO%' ^
  WITH MOVE '%BASEINTERNA%' TO '%DESTINO%%BASE%restore.mdf', ^
  MOVE '%BASEINTERNA%_log' TO '%DESTINO%%BASE%_logrestore.ldf'"

Uma consulta útil antes de tudo — para listar os bancos instalados e confirmar o que entra na rotina:

SELECT name, state_desc, compatibility_level FROM sys.databases;

Como fazer backup no MySQL (mysqldump)?

O MySQL (e o MariaDB, que usa os mesmos comandos) é o banco mais comum em sistemas web e alguns ERPs mais modernos. Normalmente roda em Linux.

A ferramenta é o mysqldump — gera um arquivo .sql com todas as instruções para recriar o banco do zero. O flag --single-transaction garante consistência sem bloquear tabelas durante o dump.

Pra bases grandes (100 GB+), vale conhecer o Percona XtraBackup (ou o mariabackup): é backup físico a quente, não trava o banco e restaura bem mais rápido que o mysqldump. E, pra recuperação ponto-a-ponto, guarde os binary logs (binlog) — eles deixam você voltar até a última transação.

Script shell para backup de todos os bancos (Linux):

#!/bin/sh
# Backup de todas as bases MySQL/MariaDB
USER=root
PASS=SuaSenhaAqui
PASTA=/backup/db

cd $PASTA

mysql -N -e 'show databases' -u${USER} -p${PASS} | while read dbname; do
  mysqldump \
    --user=${USER} \
    --password=${PASS} \
    --complete-insert \
    --routines \
    --triggers \
    --single-transaction \
    "$dbname" > "$dbname"-$(date +"%a").sql
  [[ $? -eq 0 ]] && gzip -f "$dbname"-$(date +"%a").sql
done
# Salva como nomebanco-Mon.sql.gz, nomebanco-Tue.sql.gz etc.
# Mantém 7 arquivos rotativos por banco (um por dia da semana)

Restore de uma base específica:

# Crie o banco de destino primeiro
mysql -u root -p -e "CREATE DATABASE base_restaurada;"

# Restaure o dump (descompactando on-the-fly)
gunzip -c /backup/db/meusite-Mon.sql.gz | mysql -u root -p base_restaurada

Como fazer backup no PostgreSQL (pg_dump)?

O PostgreSQL é robusto e cada vez mais presente em sistemas modernos. Ele armazena os dados em múltiplos arquivos internos — você nunca vai conseguir restaurar copiando esses arquivos diretamente. O caminho certo é o pg_dump (uma base) ou o pg_dumpall (todas as bases + roles globais).

Esse é o caminho lógico, ótimo pra portabilidade. Pra disaster recovery com point-in-time recovery, existe o caminho físico: pg_basebackup + arquivamento de WAL (Write-Ahead Log), que permite restaurar a qualquer instante.

Script Windows para backup completo com pg_dumpall (ideal pra migração ou disaster recovery):

@echo off
set DIR_OUT=C:\WSPEED\BACKUP\
set SISTEMA=MeuSistema
set PGUSER=postgres
set PGPASSWORD=SuaSenha
set HOST=127.0.0.1
set PGDUMPALL="C:\Program Files\PostgreSQL\16\bin\pg_dumpall.exe"
set SETEZIP="C:\Program Files\7-Zip\7z.exe"

if not exist %DIR_OUT% md %DIR_OUT%

for /f %%a in ('wmic path win32_localtime get dayofweek /format:list ^| findstr "="') do (set %%a)
if %DayOfWeek%==1 set DOW=Segunda
if %DayOfWeek%==2 set DOW=Terca
if %DayOfWeek%==3 set DOW=Quarta
if %DayOfWeek%==4 set DOW=Quinta
if %DayOfWeek%==5 set DOW=Sexta
if %DayOfWeek%==6 set DOW=Sabado
if %DayOfWeek%==0 set DOW=Domingo

set OUTFILE=%DIR_OUT%Backup-FULL-%SISTEMA%-%DOW%.sql
%PGDUMPALL% -h %HOST% -U %PGUSER% -v -f %OUTFILE%
%SETEZIP% a %DIR_OUT%Backup_%SISTEMA%_pgsql_%DOW%.zip %DIR_OUT%*.sql
del "%DIR_OUT%*.sql"

Restore com psql (preferível ao pg_restore para dumps gerados com pg_dumpall, pois é compatível com qualquer versão):

set PSQL="C:\Program Files\PostgreSQL\16\bin\psql.exe"
set PGUSER=postgres
set PGPASSWORD=SuaSenha
set PGHOST=127.0.0.1
set ARQUIVO=C:\WSPEED\BACKUP\Backup-FULL-MeuSistema-Segunda.sql

%PSQL% -h %PGHOST% -U %PGUSER% -v -f %ARQUIVO%

Atenção: se você usou pg_dump -Fc (formato customizado), o restore precisa do pg_restore — mas esse formato pode ter incompatibilidade entre versões do PostgreSQL. Para disaster recovery com portabilidade máxima, use o dump em texto plano (.sql) gerado pelo pg_dumpall.

E o Oracle?

O Oracle é o banco de dados que move os grandes ERPs — TOTVS e SAP, por exemplo, têm suporte a Oracle. É um sistema robusto, com arquitetura de arquivos distribuídos (datafiles, control files, archive logs), replicação, modos ARCHIVELOG e NOARCHIVELOG, e a ferramenta oficial de backup é o RMAN (Recovery Manager).

Vou ser direto: backup e restore Oracle são território de DBA experiente. Não pela dificuldade do comando em si, mas pela quantidade de variáveis — modo de archive, estrutura de tablespaces, SCN (System Change Number), configuração do catálogo de recuperação. Um passo errado no restore pode deixar o banco em estado inconsistente.

Se você gerencia um sistema que roda Oracle, recomendo envolver um DBA para montar a estratégia de backup. O que posso garantir do lado do WSpeed: assim que o RMAN gera os arquivos de backup, a nossa solução os captura e leva pra nuvem com criptografia e versionamento — sem intervenção manual.

O dump gerado é só metade do trabalho

Você já imaginou fazer backup do banco todos os dias durante um ano e descobrir que nenhum dos arquivos restaura?

Acontece. O script roda, o arquivo .gbk ou .BAK aparece na pasta — mas ninguém jamais testou a volta. Aí chega o dia do restore real e o banco abre com erro de integridade, ou faltam tabelas, ou a versão do banco mudou e o arquivo não é mais compatível.

Teste de restore periódico não é paranoia — é parte da rotina de quem leva backup a sério.

Além disso, o arquivo de dump que ficou só no servidor local resolve nada numa falha de hardware ou num ransomware (sequestro de dados). O servidor cai, o dump some junto. Por isso o fluxo completo é:

1. Script nativo do SGBD gera o dump na pasta local.
2. Arquivo é enviado pra nuvem criptografada imediatamente.
3. Nuvem guarda versões por 7, 15 ou 30 dias (rotativo).
4. Restore é testado mensalmente em ambiente separado.

É exatamente esse fluxo que o backup em nuvem para empresas da WSpeed automatiza. O script de dump fica no servidor; o WSpeed monitora a pasta de destino e envia cada arquivo novo pro Backblaze B2 (nosso armazenamento primário, especializado em backup e mais econômico) com criptografia AES-256 e retenção configurável. Se precisar, o arquivo também vai pro AWS S3.

Sem ação manual, sem depender de alguém lembrar de copiar.

Se você cuida da TI de clientes e quer entender como estruturar isso como serviço gerenciado, vale dar uma olhada em como trabalhamos com backup para empresas de TI.

Agora me conta nos comentários: qual SGBD você mais atende — e já pegou algum backup de banco que simplesmente não restaurou? Aposto que tem história boa (ou dolorosa) aí.

Abraço e até o próximo artigo ou vídeo.