Dicas Gerais

Como restaurar um backup SQL do MySQL por SSH com segurança

Aprenda a preparar e importar um backup SQL por SSH, proteger o arquivo e a senha e validar a restauração antes de usar o banco em produção.

Atualizado em Sem comentários

Revisão técnica: 07/09/2026. Publicação original preservada.

Para restaurar um backup SQL por SSH, você precisa de acesso ao terminal, um cliente MySQL ou MariaDB e um usuário com permissões no banco de destino. Comece em um banco de teste: a importação executa as instruções do arquivo e pode substituir ou apagar dados existentes.

Prepare o arquivo e o banco de destino

Guarde uma cópia do banco atual e confira a origem do backup. Envie o arquivo por SFTP ou outro canal protegido para uma pasta privada da conta, fora de public_html e de qualquer diretório servido pelo site. Um dump pode conter dados de clientes e outras informações que não devem ficar disponíveis para download.

Exemplo de caminho privado: /home/USUARIO/backups/arquivo.sql. Substitua os nomes dos exemplos pelos dados reais da sua conta. No cPanel, crie previamente o banco e associe o usuário com as permissões necessárias, quando essa for a forma de gerenciamento da hospedagem.

Importe pelo terminal Linux

No shell Linux da sessão SSH, execute:

mysql --host=HOST_DO_BANCO --user=USUARIO_DO_BANCO --password NOME_DO_BANCO < /home/USUARIO/backups/arquivo.sql

Digite a senha quando o cliente solicitar. Não escreva a senha junto de --password ou -p: ela pode acabar no histórico ou na lista de processos. Em ambientes MariaDB, o executável pode se chamar mariadb. A documentação do MySQL explica a restauração de dumps SQL e os cuidados com senhas.

Se o dump contiver CREATE DATABASE ou USE, ele pode selecionar outro banco além do informado no comando. Confira isso antes de executar. Não use curingas como *.sql para uma restauração que deveria ler um único arquivo.

Se a importação apresentar erros

  • Acesso negado: confira host, usuário e permissões no banco correto.
  • Collation desconhecida ou sintaxe incompatível: compare as versões de origem e destino; não remova trechos do dump sem entender o efeito.
  • Acentuação incorreta: confirme a codificação real do arquivo e as instruções de charset existentes nele. Trocar a opção para Latin1 por tentativa pode piorar o resultado.
  • Erro em views, triggers ou rotinas: confira o que foi incluído no backup e as permissões exigidas. Não existe um limite universal de 2 MB que determine a ferramenta adequada.

Não ignore erros para concluir a operação à força. Uma importação interrompida pode deixar dados parciais, mesmo que parte das tabelas tenha sido criada.

Valide antes de usar em produção

Compare as tabelas esperadas, confira registros e caracteres acentuados e teste as funções principais da aplicação no ambiente de teste. Planeje a troca com uma janela de manutenção quando houver novas gravações. Mantenha o backup privado pelo período definido na sua rotina de recuperação.

Se precisar de ajuda para planejar a restauração em um servidor, consulte o gerenciamento de servidores da WebinHost.

Assuntos: