Backup e restore no Magento 2: o que salvar e como

Rodrigo Biazzi

16 de abril de 2026

Um backup só serve se você consegue restaurá-lo, rápido, sob pressão, em um servidor que pode não ser o original. Muitas lojas Magento têm backups que falham nesse teste: um dump do banco sem a chave de criptografia, mídia que nunca foi copiada ou um dump que dá erro no meio da importação por causa dos definers das triggers.

Este artigo cobre o que um backup completo do Magento 2 contém, como criar cada parte e como restaurá-lo. Vale para Magento Open Source e Adobe Commerce em servidores próprios. O Adobe Commerce Cloud tem suas próprias ferramentas de snapshot e backup, que não cubro aqui.

Não confie no backup nativo

O Magento tem um recurso de backup no admin e o comando setup:backup. A Adobe o descontinuou há anos e ele vem desabilitado por padrão na configuração. Ele roda dentro do PHP, é lento em bancos grandes, guarda o resultado no mesmo servidor e nunca foi pensado para recuperação de desastres em produção. Use diretamente as ferramentas de banco e de arquivos.

O que um backup completo contém

Parte	Por que importa
Banco de dados	Produtos, clientes, pedidos, configuração, conteúdo de CMS
pub/media	Imagens de produtos e categorias, uploads de CMS, produtos para download
app/etc/env.php	Credenciais do banco e a chave de criptografia
Código	Repositório Git mais composer.json e composer.lock
Pastas de dados custom	Arquivos de importação e exportação, feeds, arquivos gravados por extensões
Configuração do servidor	Nginx, PHP-FPM, cron, Varnish, Redis

A chave de criptografia merece uma linha própria. O Magento criptografa chaves de gateways de pagamento, senhas de API e outros segredos no core_config_data com a chave guardada no env.php. Um backup do banco sem o env.php correspondente restaura uma loja em que todos esses valores ficam ilegíveis. Guarde uma cópia do env.php com cada backup, criptografada, porque ele contém segredos. Mais sobre esse arquivo no guia de env.php e config.php.

Você não precisa fazer backup de generated, pub/static, var/cache nem var/page_cache. Eles são reconstruídos a partir do código. O índice de busca no OpenSearch e o conteúdo do Redis também são reconstruídos, pelo reindex e pelo tráfego normal.

Dump do banco que restaura sem erro

Para um dump consistente de tabelas InnoDB sem travar a loja, use uma single transaction:

mysqldump \
    --single-transaction \
    --quick \
    --routines \
    --triggers \
    --no-tablespaces \
    -h db-host -u backup_user -p magento \
    | sed -E 's/DEFINER=`[^`]+`@`[^`]+`//g' \
    | gzip > magento-$(date +%Y%m%d-%H%M).sql.gz

--single-transaction dá um snapshot consistente sem bloquear escritas. Funciona para InnoDB, que é o que o Magento usa.
--quick envia as linhas em stream em vez de carregar tabelas inteiras em memória.
--triggers importa porque o Magento usa triggers nos indexers em modo Update by Schedule.
O comando sed remove as cláusulas DEFINER das triggers. Sem ele, importar em um servidor onde aquele usuário do banco não existe falha, ou exige privilégios elevados.

No MariaDB, nas versões recentes o cliente se chama mariadb-dump, com as mesmas opções.

Um aviso sobre dumps parciais. Por padrão, o mysqldump escreve um DROP TABLE IF EXISTS antes de cada tabela. Se você faz dump de apenas algumas linhas de uma tabela, com --where por exemplo, e importa esse arquivo em um banco existente, a tabela é apagada e substituída pelos dados parciais. Saiba o que um arquivo de dump contém antes de importá-lo em qualquer lugar que importe.

Para bancos maiores, ferramentas de backup físico como o Percona XtraBackup ou o Mariabackup restauram mais rápido do que um dump lógico. Elas copiam os arquivos de dados enquanto o servidor roda. O trade-off é que o restore precisa ir para um servidor de banco com versão compatível.

Recuperação em um ponto no tempo

Um dump noturno significa que você pode perder até um dia de pedidos. Se isso não é aceitável, habilite os binary logs no servidor de banco e guarde-os junto dos backups. Restaurar o último dump completo e reaplicar os binary logs até um determinado momento permite recuperar até logo antes de um deploy ruim ou de uma exclusão acidental. Os binary logs crescem rápido em lojas movimentadas, então defina um período de expiração e acompanhe o uso de disco.

Mídia e outros arquivos

A mídia costuma ser a maior parte do backup e muda devagar, então cópias incrementais funcionam bem:

rsync -a --delete \
    --exclude 'catalog/product/cache/' \
    /var/www/shop/shared/pub/media/ \
    backup-host:/backups/shop/media/

O cache de imagens de produto pode ser excluído porque o Magento o regenera, ou você pode refazê-lo depois de um restore com bin/magento catalog:images:resize. Use uma ferramenta de backup com versionamento, como restic ou borg, se precisar recuperar um arquivo apagado há vários dias. Um rsync simples com --delete guarda só o estado mais recente.

Onde guardar os backups

Fora do servidor. Um backup no mesmo disco não sobrevive a uma falha de disco, a um servidor apagado ou a um ransomware.
Criptografado. O banco guarda dados de clientes e o env.php guarda segredos.
Com retenção. Cópias diárias por algumas semanas e semanais por alguns meses cobrem a maioria das necessidades. Alguns problemas, como uma injeção de malware, são descobertos semanas depois de começarem. Veja o checklist de limpeza de malware.
Com acesso restrito. O servidor que cria os backups deve poder escrever mas não apagar os antigos, para que um servidor comprometido não consiga apagar o próprio histórico.

Restaurando uma loja

A ordem importa. Um restore que liga o cron cedo demais pode enviar e-mails ou sincronizar pedidos contra um banco importado pela metade.

Pare o cron do usuário do Magento e pare os consumers de fila.

Crie um banco vazio e importe o dump:

gunzip < magento-20260110-0300.sql.gz | mysql -h db-host -u magento -p magento

Faça o deploy do código no commit correspondente e rode composer install.
Restaure o app/etc/env.php e depois atualize as credenciais do banco se mudaram. Mantenha a chave de criptografia original.
Restaure o pub/media e as pastas de dados custom.
Se o domínio mudou, atualize as base URLs:
```
bin/magento setup:store-config:set --base-url="https://new.example.com/" --base-url-secure="https://new.example.com/"
```
Em setups com vários websites, confira também os escopos de website e store view no core_config_data.

Compile, faça o deploy do conteúdo estático, reindexe e limpe o cache:

bin/magento setup:di:compile
bin/magento setup:static-content:deploy -f
bin/magento indexer:reindex
bin/magento cache:flush

Confira a loja e só então ligue o cron e os consumers.

Se você restaura para um ambiente que não é de produção, sanitize os dados antes de qualquer pessoa usar e desabilite e-mails de saída e integrações. Veja como sanitizar um banco Magento para staging.

Teste o restore

Agende um teste de restore, pelo menos a cada poucos meses, em um servidor separado. Meça quanto tempo leva. Esse número é o seu tempo real de recuperação e muitas vezes é bem maior do que as pessoas supõem, porque importar um banco grande e reindexar leva tempo. Escreva os passos enquanto faz, para que o próximo restore seja feito a partir de um documento e não de memória.

FAQ

Devo usar o bin/magento setup:backup?

Não. O backup nativo está deprecated, desabilitado por padrão e não é adequado para produção. Use mysqldump ou uma ferramenta de backup físico para o banco e rsync ou restic para os arquivos.

Por que a chave de criptografia é tão importante nos backups?

O Magento criptografa segredos como chaves de API de pagamento com a chave do app/etc/env.php. Sem a mesma chave, um banco restaurado tem credenciais ilegíveis.

Por que o meu dump do Magento falha na importação com um erro de DEFINER?

As triggers dos indexers carregam o usuário do banco que as criou. Remova as cláusulas DEFINER com sed ao criar o dump, ou crie o mesmo usuário no servidor de destino.

Preciso fazer backup do índice do OpenSearch?

Não. Ele é reconstruído a partir do banco com bin/magento indexer:reindex. Faça backup do banco e da mídia e reindexe depois de restaurar.

Atendo como freelancer em Magento e Adobe Commerce, incluindo setups de backup e recuperação. Se precisar de ajuda com isso, fale comigo.

Assuntos:Magento 2 Backup MySQL DevOps Adobe Commerce