Checklist: restauração automatizada MariaDB no Windows Server 2025

Checklist: restauração automatizada MariaDB no Windows Server 2025 é a rotina de scripts e checagens que valida o dump, restaura em staging e só promove dados com integridade confirmada. Restaurar direto em produção sem hash e sem mysqlcheck aumenta o risco de sobrescrever dados válidos. Para configurar a restauração automatizada com verificação de integridade, siga estes passos:

1. Isole um schema ou instância de staging e um usuário MariaDB só para restore.
2. Confira o SHA-256 do arquivo .sql (ou .sql.gz) contra o hash gerado no backup.
3. Importe o dump com mariadb.exe via script PowerShell e arquivo de credenciais protegido.
4. Execute mysqlcheck --check no ambiente de teste e rode consultas de sanidade.
5. Agende a tarefa no Agendador do Windows Server 2025 após o job de backup.
6. Promova para produção somente se hash, mysqlcheck e logs estiverem limpos.

Pré-requisitos

Antes de aplicar o checklist de restauração automatizada MariaDB no Windows Server 2025, o servidor precisa ter o serviço MariaDB 11.8 (ou superior da série 11) em execução, o cliente na pasta bin e permissão para criar tarefas agendadas. Sem dump íntegro, hash conhecido e um alvo de staging, a automação vira um restore cego.

• Windows Server 2025 com MariaDB 11.8+ instalado e serviço MariaDB iniciado.
• Binários mariadb.exe, mariadb-dump.exe e mysqlcheck.exe no PATH ou em C:\Program Files\MariaDB 11.8\bin.
• Dump lógico (.sql ou .sql.gz) mais arquivo .sha256 gerado no momento do backup.
• Instância ou database de staging (nunca o schema de produção como destino do job automático).
• Conta de serviço com direito de Log on as a batch job e leitura na pasta de backups.
• Arquivo de opções MySQL/MariaDB (defaults-extra-file) com ACL restrita ao serviço.
• Acesso administrativo ao Agendador de Tarefas e ao Event Viewer para auditar falhas.

Se o host for um VPS Windows, confirme o RDP e o disco de backups antes de agendar; o artigo Acessando servidores VPS Windows da AviraHost cobre o acesso inicial. Para copiar dumps entre máquinas, o acesso remoto oficial do Windows evita expor a porta 3306 na internet. Conexão remota ao servidor de banco, quando necessária, deve seguir o mesmo rigor descrito em Conectando remotamente ao MySQL - cPanel: usuário dedicado, host restrito e TLS quando o cliente suportar.

Checklist: restauração automatizada MariaDB no Windows Server 2025

O ponto central do checklist: restauração automatizada MariaDB no Windows Server 2025 é separar validação, restore e promoção. O job automático só deve chegar até o staging; a promoção permanece um passo explícito depois de mysqlcheck e de consultas de sanidade. Ao montar o fluxo, trate o dump como artefato versionado: nome com data, hash ao lado e retenção de pelo menos três gerações íntegras.

Crie a pasta de trabalho, por exemplo D:\Backups\MariaDB e D:\Restore\MariaDB\logs. O script PowerShell deve falhar rápido ($ErrorActionPreference = 'Stop'), registrar horário UTC, nome do arquivo e o hash calculado. Credenciais não entram no script: use um arquivo D:\Restore\MariaDB\restore.cnf com ACL apenas para SYSTEM e para a conta da tarefa.

[client]
user=restore_stg
password=TroqueEstaSenha
host=127.0.0.1
port=3306

O usuário restore_stg precisa de privilégios apenas no database de staging (CREATE, DROP, INSERT, SELECT, LOCK TABLES conforme o dump). Não conceda SUPER nem acesso aos schemas de produção. Se o dump contém CREATE DATABASE, aponte o restore para um nome de teste, por exemplo app_staging, e ajuste o SQL ou use um dump sem CREATE DATABASE gerado com mariadb-dump --databases app_prod --skip-add-drop-database no job de origem.

Antes de qualquer DROP no staging, o script deve gravar o tamanho do dump e recusar arquivos vazios ou menores que o mínimo histórico. Essa trava simples evita restaurar um .sql truncado por falha de disco ou cópia incompleta. Mantenha o dump original intacto: a automação lê uma cópia em D:\Restore\MariaDB\work.

Checklist: restauração automatizada MariaDB no Windows Server 2025 — itens que o script deve cumprir

1. Localizar o dump mais recente cujo .sha256 exista e não esteja com atributo de arquivo em uso.
2. Recalcular SHA-256 e abortar se divergir do arquivo de hash.
3. Copiar o dump para a pasta work e registrar o caminho no log.
4. Opcional: descompactar .sql.gz só depois do hash do arquivo compactado conferir.
5. Aplicar o SQL em staging com mariadb.exe e --defaults-extra-file.
6. Rodar mysqlcheck --check no schema restaurado e falhar o job se houver tabela marcada como corrompida.
7. Executar consultas de sanidade (contagem de tabelas, MAX(id) em tabelas-chave, horário do último registro).
8. Escrever um arquivo OK/FAIL e um código de saída diferente de zero em qualquer falha.

Com esses itens no mesmo script, o Agendador de Tarefas vira apenas o gatilho. A lógica de integridade permanece versionada no repositório do time, não escondida em cliques do MMC.

Validar hash SHA-256 do dump antes do restore

A conferência de hash SHA-256 do dump é o primeiro filtro contra arquivo truncado, bit flip em disco ou cópia pela metade via SMB. No Windows Server 2025 o cmdlet Get-FileHash calcula o mesmo digest que sha256sum no Linux, desde que o arquivo não tenha sido reconvertido de UTF-16. Guarde o hash em um .sha256 de uma linha, gerado no servidor de origem no mesmo segundo do dump.

Ao rodar o bloco abaixo, você verá o hash em hexadecimal maiúsculo. Compare com o conteúdo do arquivo de hash após Trim() e, se o origem Linux gravou em minúsculas, normalize com .ToUpperInvariant().

$dump = 'D:\Backups\MariaDB\seudominio.com.br_app.sql'
$expected = (Get-Content -Path ($dump + '.sha256') -Raw).Trim().Split(' ')[0]
$actual = (Get-FileHash -Path $dump -Algorithm SHA256).Hash
if ($actual.ToUpperInvariant() -ne $expected.ToUpperInvariant()) {
  throw "SHA-256 divergente. esperado=$expected atual=$actual"
}
Write-Output "Hash OK $actual"

Hash OK 3F1A9C0E8B7D6A5C4E3B2A1908F7E6D5C4B3A291807F6E5D4C3B2A1908F7E6D5

Se o backup vier compactado, hasheie o .sql.gz e só então descompacte. Hashear o SQL já extraído sem ter validado o pacote permite que um gzip corrompido falhe no meio do restore com SQL pela metade. Em PowerShell 7 você pode usar gzip -d se o OpenSSH Client e as ferramentas estiverem no PATH; no Windows Server 2025 com apenas Windows PowerShell 5.1, prefira dump .sql ou 7-Zip em modo silencioso, sempre depois do hash.

Não use MD5 para esse checklist: colisão e ferramentas antigas ainda geram MD5 em rotinas copiadas da internet. SHA-256 no mesmo volume NTFS, com o arquivo fechado (sem handle de gravação do job de backup), é o critério de avanço. Se o hash falhar, o script deve sair com código 2, preservar o dump e não tocar no staging.

Restore em staging com PowerShell, mariadb e mysqlcheck

O restore em staging com o cliente mariadb deve ocorrer só depois do hash. O alvo é um database de teste no mesmo servidor ou em instância paralela na porta 3307. Produção permanece fora do -e e fora do redirecionamento de stdin do job automático.

Atenção: o comando a seguir apaga e recria o schema de staging. Confirme o nome app_staging duas vezes. Nunca aponte --database para o schema de produção neste script.

$mariadb = 'C:\Program Files\MariaDB 11.8\bin\mariadb.exe'
$cnf = 'D:\Restore\MariaDB\restore.cnf'
$dump = 'D:\Restore\MariaDB\work\seudominio.com.br_app.sql'
& $mariadb --defaults-extra-file=$cnf -e "DROP DATABASE IF EXISTS app_staging; CREATE DATABASE app_staging CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"
Get-Content -Path $dump -Raw | & $mariadb --defaults-extra-file=$cnf app_staging
if ($LASTEXITCODE -ne 0) { throw "mariadb restore falhou com codigo $LASTEXITCODE" }

Output esperado: nenhum texto no sucesso; $LASTEXITCODE igual a 0. Qualquer ERROR 1064 ou ERROR 1049 deve abortar o job.

Em seguida rode o mysqlcheck só no schema restaurado. --all-databases no servidor de produção misturaria tabelas que o job não tocou e geraria falso positivo ou, pior, tentativas de REPAIR no lugar errado.

$mysqlcheck = 'C:\Program Files\MariaDB 11.8\bin\mysqlcheck.exe'
& $mysqlcheck --defaults-extra-file=$cnf --check app_staging
if ($LASTEXITCODE -ne 0) { throw "mysqlcheck encontrou tabelas inconsistentes" }

app_staging.usuarios                           OK
app_staging.pedidos                            OK
app_staging.pedidos_itens                      OK

Consultas de sanidade fecham o ciclo: conte tabelas em information_schema, compare com um arquivo de baseline e leia um MAX(updated_at) que não seja nulo em tabelas de movimento. Se o dump for de seudominio.com.br e a aplicação espera N tabelas, o script deve falhar quando N divergir. Só então grave restore-ok.flag. A promoção para produção fica fora deste job: outro procedimento, com backup fresco de produção e janela combinada, aplica o mesmo dump já validado ou um dump gerado a partir do staging conferido.

Agendar a restauração no Agendador de Tarefas

O Agendador de Tarefas do Windows Server 2025 dispara o script depois que o backup terminou, não no mesmo minuto em que o dump ainda está sendo escrito. Use um gatilho “Ao criar ou modificar um arquivo” na pasta de dumps, ou um atraso fixo (por exemplo 20 minutos após o horário do mariadb-dump). A ação deve ser powershell.exe com -NoProfile -ExecutionPolicy Bypass -File D:\Restore\MariaDB\Restore-Staging.ps1.

Execute a tarefa com a conta do serviço MariaDB ou com uma gMSA que leia o dump e abra o TCP 3306 em 127.0.0.1. Marque “Executar se o usuário estiver ou não conectado”, ative o histórico da tarefa e limite a uma instância (não iniciar uma nova se a anterior estiver em execução). Em Condições, desmarque “Iniciar somente se o computador estiver ligado à energia da rede” em host físico se isso impedir o job no rack.

O script deve escrever em D:\Restore\MariaDB\logs\restore-YYYYMMDD.log e, em falha, um evento no log Aplicação via Write-EventLog (registre a fonte uma vez com New-EventLog) ou via wevtutil. Assim o monitoramento (agente ou Event Viewer) enxerga hash inválido e mysqlcheck sem abrir o arquivo de log manualmente. Teste a tarefa com “Executar” no MMC e confira o código de última execução: 0x0 no sucesso, distinto de zero no throw do PowerShell.

Não encadeie restore de produção no mesmo gatilho. O checklist termina em staging verificado. Documente no runbook quem promove, qual comando usa e qual backup extra de produção é obrigatório antes do CUTOVER. Para o painel dos serviços contratados, use Como acessar o painel de gerenciamento dos meus Serviços quando precisar abrir chamado com horário do job e trecho do log.

Problemas comuns e como resolver

Sintoma: Get-FileHash diverge do .sha256 mesmo com o arquivo recém-copiado

Causa: o job de backup ainda estava gravando, o arquivo foi transferido em modo texto (CRLF extra) ou o .sha256 contém o nome do arquivo na mesma linha sem split correto.
Solução: aguarde o handle fechar (teste com falha se o LastWriteTime for recente demais), copie em binário (robocopy /J) e parseie só o primeiro token do .sha256. Recalcule no destino e compare em maiúsculas.

Sintoma: mariadb.exe devolve Access denied ou não encontra o defaults-extra-file

Causa: a conta da tarefa não lê restore.cnf, o caminho tem espaço sem aspas, ou o usuário SQL não tem privilegio no schema de staging.
Solução: ajuste ACL do .cnf, passe o caminho entre aspas no script e conceda privilégios só em app_staging. Confirme com mariadb --defaults-extra-file=... -e "SELECT CURRENT_USER();" na mesma conta da tarefa.

Sintoma: mysqlcheck reporta tabela marcada como corrompida após o restore

Causa: dump incompleto, crash no import ou tablespace InnoDB inconsistente já no backup de origem.
Solução: não promova. Preserve dump, hash e log. Restaure um dump anterior com hash OK no staging. REPAIR TABLE só no teste e só quando o motor permitir; InnoDB costuma exigir dump íntegro, não repair improvisado em produção.

Sintoma: a tarefa agendada fica em 0x1 ou 0xFFFD e o log do script está vazio

Causa: ExecutionPolicy, caminho -File errado ou perfil de rede indisponível no momento do logon da conta batch.
Solução: use -NoProfile -ExecutionPolicy Bypass, caminhos absolutos e um log transcript no início do .ps1 (Start-Transcript). Verifique Histórico da tarefa e o código de saída do powershell.exe.

Perguntas frequentes sobre restauração automatizada MariaDB no Windows Server 2025

Como verificar a integridade de um dump MariaDB no Windows Server 2025?

Confira o hash SHA-256 do arquivo .sql ou .sql.gz contra o valor gerado no backup, depois execute mysqlcheck --all-databases --check no servidor de teste. Só avance a restauração se o hash coincidir e o mysqlcheck não reportar tabelas corrompidas.

Qual ferramenta usar para restaurar backups MariaDB de forma automatizada?

Use mariadb ou mysql na linha de comando dentro de um script PowerShell, com credenciais em arquivo protegido. Agende a tarefa no Agendador de Tarefas do Windows Server 2025 para rodar após a cópia do dump e a checagem de hash.

A restauração automatizada deve apontar para o banco de produção?

Não. Restaure primeiro em uma instância ou schema de staging, rode mysqlcheck e consultas de sanidade e só então promova os dados. Restaurar direto em produção aumenta o risco de sobrescrever dados válidos com um dump incompleto.

Como agendar a restauração de backup MariaDB no Windows Server 2025?

Crie uma Tarefa Agendada que execute o script PowerShell com a conta do serviço MariaDB, gatilho diário ou após o job de backup, e ação Iniciar um programa apontando para powershell.exe -File. Ative o histórico da tarefa para auditar falhas de integridade.

O que fazer se o mysqlcheck falhar após o restore?

Interrompa a promoção para produção, preserve o dump original e o log do script, e tente um dump anterior cujo hash esteja íntegro. Corrija tabelas apenas no ambiente de teste com REPAIR TABLE quando aplicável, nunca em produção sem backup adicional.

Conclusão

• Trate hash SHA-256, restore em staging e mysqlcheck como portões obrigatórios do job; produção fica fora do agendamento automático.
• Use mariadb.exe com defaults-extra-file, conta mínima e logs com código de saída diferente de zero em qualquer falha.
• No Agendador, rode depois do dump fechar, ative o histórico e mantenha pelo menos três dumps cujo hash já tenha sido validado.

Leia também

• Checklist MariaDB vs MySQL: diferenças que impactam sua hospedagem
• Configurar MariaDB 11.4 no AlmaLinux 9: do padrão ao máximo
• Otimizar MariaDB 10.11 no Rocky Linux 9: tuning essencial

Precisa de ajuda com restauração automatizada MariaDB?

Se você hospeda aplicações em Windows Server 2025 e precisa de disco, isolamento e suporte para rotinas de backup e restore de MariaDB, um servidor dimensionado reduz a chance de dump truncado por volume cheio.

Ver servidores dedicados AviraHost