Backup e restauração testada

Um arquivo de backup pode ser importado sem erro e ainda devolver um ambiente que não serve à operação. O backup só tem valor quando a restauração foi testada e mostrou que a estrutura, os dados, as identidades e as dependências voltam como deveriam.

Consistência e escopo

A consistência é a garantia de que a cópia representa um único momento coerente, sem tabelas de momentos diferentes. O escopo define o que a cópia precisa conter para que a aplicação volte a funcionar:

• as tabelas usadas pela aplicação, inclusive as tabelas de controle;
• as views, os procedimentos armazenados, os gatilhos e os eventos agendados, quando existem;
• as contas de acesso e as permissões, que ficam em um banco de sistema e não entram na cópia de um banco comum;
• a configuração do servidor, que fica em um arquivo próprio, fora do banco.

A cópia fica guardada fora do servidor de origem, em outro computador ou em outro armazenamento, porque uma cópia no mesmo disco se perde junto com ele.

A exportação

• mysqldump --host=192.168.1.10 --user=backup --password --single-transaction --routines --events loja --result-file=loja_20261008.sql: exporta o banco loja inteiro, com os procedimentos e os eventos.

As opções completam a exportação:

• --routines: inclui os procedimentos armazenados, que ficam fora da exportação padrão.
• --events: inclui os eventos agendados, que também ficam fora da exportação padrão.
• --triggers: inclui os gatilhos das tabelas e já é o comportamento padrão.

No Windows, a opção --result-file evita um problema do PowerShell, em que o redirecionamento com o sinal de maior pode gravar o arquivo em uma codificação que a importação não reconhece.

A versão da ferramenta também importa. O mysqldump do MySQL 8 lê estatísticas de colunas que não existem nas versões anteriores e, contra um servidor 5.7, pode falhar com o erro 1109, de tabela desconhecida. Nesse caso, a opção --column-statistics=0 desliga essa leitura. Com servidores mais antigos, como o 5.1, o mais seguro é usar o mysqldump da mesma versão do servidor, instalado junto com ele.

O que a consistência não cobre

• Tabelas MyISAM: a visão consistente do --single-transaction vale só para o InnoDB, e uma tabela MyISAM que recebe gravações durante a exportação pode ficar em um momento diferente. Sem essa opção, o mysqldump bloqueia as tabelas de cada banco até o fim da exportação, o que mantém a consistência e pode fazer as gravações esperarem.
• Mudanças de estrutura: um ALTER TABLE, um DROP TABLE, um RENAME TABLE ou um TRUNCATE TABLE durante a exportação quebra a consistência, e uma atualização da aplicação que recria tabelas não pode coincidir com a cópia.
• Exportações separadas: duas tabelas relacionadas exportadas em comandos diferentes correspondem a momentos diferentes.

A restauração em um destino isolado

O teste usa um servidor ou um banco descartável, sem nenhuma ligação com a operação. A cópia de teste não pode estar ligada à sincronização com a matriz, nem a uma integração real, para não enviar dados de teste a sistemas de verdade.

Antes da importação, convém examinar o início do arquivo. Uma exportação feita com a opção --databases traz os comandos CREATE DATABASE e USE com o nome do banco original, e a importação grava nesse banco, mesmo quando outro banco é indicado na conexão. A importação em um banco de teste usa a ferramenta de linha de comando:

• mysql --host=127.0.0.1 --port=3307 --user=teste --password loja_teste: abre a conexão com o banco de teste;
• SOURCE loja_20261008.sql;: executa o arquivo da exportação dentro dessa conexão.

A importação precisa terminar sem erros, e os avisos ficam registrados. Diferenças de versão, de collation e de permissões entre a origem e o destino podem aparecer nesse momento. Um servidor que inicia sem erro é a condição de partida do teste, e não o resultado dele.

O que validar depois da importação

• a definição, o engine e os índices de cada tabela;
• as contagens exatas, o maior identificador e o próximo valor do contador;
• as linhas marcadas como excluídas e a tabela de controle das ordens;
• as colunas derivadas e as ligações entre as tabelas, com as consultas de registros órfãos;
• as buscas e os fluxos principais da aplicação, em um ambiente controlado.

As medidas de comparação vêm do mesmo momento da cópia. Uma contagem tirada da produção horas depois, com vendas novas, não serve de referência, e uma contagem igual não prova que os identificadores e os valores foram preservados.

Até qual momento a cópia recupera

A restauração devolve os dados ao momento da cópia. As alterações posteriores só voltam com o log binário, um registro das alterações confirmadas no servidor, aplicado sobre a cópia a partir da posição em que ela foi feita. Essa recuperação depende de três condições:

• o log binário ligado, que é o padrão a partir do MySQL 8 e vem desligado nas versões antigas, como a 5.1;
• os arquivos do log guardados desde a cópia, já que o MySQL 8 os apaga, por padrão, depois de 30 dias;
• a posição do log anotada no momento da cópia, que o mysqldump grava no arquivo com a opção --source-data, chamada de --master-data nas versões anteriores.

Dois comandos conferem o log binário:

• SELECT @@log_bin;: mostra o valor 1 quando o log binário está ligado;
• SHOW BINARY LOGS;: lista os arquivos do log binário existentes.

Nenhum recurso recupera uma alteração que não foi registrada. As vendas já enviadas à matriz podem existir lá, e a reconstituição desse período depende do procedimento da sincronização.