Velocidade de Backup do Site: Por que seus backups estão lentos e como corrigi-los

Seu backup está em execução há 45 minutos. Nada está quebrado, mas uma barra de progresso continua se movendo.

Ou talvez seu site fique lento todas as noites às 3 da manhã, e você não consegue descobrir o porquê. Você verifica as configurações de seus plugins, executa um teste de velocidade e nada óbvio aparece. Então alguém menciona backups, e tudo faz sentido.

Backups lentos de sites são um problema real. O processo de backup em si pode estar demorando muito ou falhando silenciosamente antes de terminar. Por outro lado, seu backup pode estar sendo concluído corretamente, mas os recursos que ele consome enquanto está em execução estão deixando seu site principal lento.

A correção é diferente dependendo de qual problema você está enfrentando. Este tutorial aborda ambos.

Ao final, você terá lidado com a lentidão de backup do site, trabalhado nas configurações do Duplicator Pro que a resolvem e configurado um cronograma de backup que não compete com seu tráfego real.

Aqui estão os principais pontos:

• Existem dois problemas distintos de velocidade de backup: um processo de backup lento ou quebrado e um backup que deixa seu site principal lento durante a janela de backup. A correção é diferente para cada um, e este post cobre ambos.
• Um backup que parece completo, mas falha na restauração, é um problema de tempo limite do PHP, não um problema de corrupção. O formato DupArchive do Duplicator Pro evita isso processando arquivos em blocos em vez de uma operação contínua.
• Reduzir o tamanho do seu arquivo é a alavanca mais rápida. Diretórios de cache, arquivos de log e arquivos de backup restantes de outros plugins podem ser excluídos com segurança e geralmente representam a maior parte do peso desnecessário do backup.
• Backups completos diários do site geralmente são excessivos. Um backup diário apenas do banco de dados (menos de 30 segundos) combinado com um backup semanal completo do site reduz o tempo de criação e a carga do servidor sem sacrificar a cobertura de restauração.
• O cron do WordPress não roda em um cronograma real. Backups agendados para as 3 da manhã podem ser silenciosamente transferidos para horários de pico de tráfego. Substituir o WP-Cron por um trabalho cron real do servidor é o que torna os backups agendados realmente confiáveis.
• Teste uma restauração antes que você precise de uma. A maioria das pessoas descobre um backup quebrado durante um desastre real. Verificar uma restauração em um site de staging leva 20 minutos e é a única etapa que separa uma recuperação rápida de uma dolorosa.

Sumário

Quanto Tempo Deve Levar um Backup do WordPress?

Em um site bem configurado com hospedagem decente, um backup completo deve ser concluído em dois a dez minutos. Sites grandes em hospedagem compartilhada podem levar de 30 a 45 minutos, às vezes mais. E o tempo varia não apenas pelo tamanho do site, mas por como o backup é executado, o que seu host permite e se seu servidor está sob carga quando o processo começa.

Quatro fatores impulsionam a maior parte da variação.

• Limites de I/O do host

A hospedagem compartilhada limita o número de operações de leitura e gravação que sua conta pode executar por segundo. Um backup lê todos os arquivos do seu site e os grava em um arquivo. Em um servidor com limites, esse processo fica extremamente lento e pode derrubar o tempo de resposta do seu site enquanto ele é executado.

• Tamanho do site

Uma grande biblioteca de mídia, um banco de dados inchado ou anos de arquivos de plugin acumulados estendem o tempo de criação. Um site de 500 MB e um site de 5 GB não serão copiados da mesma forma.

• Método de backup

Backups completos comprimem tudo do zero a cada vez. Backups incrementais salvam apenas o que mudou desde a última execução, o que os torna significativamente mais rápidos após a conclusão do primeiro backup. O Duplicator Pro suporta ambas as abordagens, e a estratégia de duas programações neste tutorial oferece a maior parte do benefício de velocidade dos backups incrementais sem a complexidade.

• Timeouts do PHP

A maioria dos hosts compartilhados define limites de tempo de execução do PHP entre 30 e 60 segundos. Um backup que excede esse limite é encerrado no meio do processo. O arquivo parece completo. Ele não está. Esta é uma das causas mais comuns de backups que parecem ter sucesso, mas falham durante a restauração.

O Que Você Precisa Antes de Começar

Antes de alterar qualquer configuração, certifique-se de ter o seguinte em vigor.

• Um plugin de backup do WordPress instalado e ativo. Este tutorial usa o Duplicator Pro para todas as etapas específicas e referências de interface. O Duplicator Pro é um plugin de backup, migração e recuperação de desastres do WordPress usado por mais de 1,5 milhão de profissionais de WordPress. Ele lida com backups, migrações de sites, staging e restaurações — incluindo um formato de arquivo em blocos projetado especificamente para sobreviver aos limites de timeout do PHP comuns em hospedagem compartilhada.
• Acesso administrativo do WordPress (você precisará dele para acessar as configurações do seu plugin de backup)
• Acesso ao painel de controle de hospedagem (cPanel ou o equivalente do seu host — necessário para configuração de cron do servidor e alterações nos limites do PHP)
• O tamanho atual do seu backup (encontre isso na tela de pacotes ou histórico de backup do seu plugin)
• Seu tipo de hospedagem: compartilhada, VPS, WordPress gerenciado ou dedicada. Isso importa porque algumas correções neste tutorial exigem a cooperação do seu host. Em hospedagem compartilhada, você nem sempre pode alterar as configurações de PHP sozinho.
• Acesso ao suporte de hospedagem (chat ao vivo ou um sistema de tickets de suporte — você pode precisar dele para as Etapas 3 e 8)

Saber o seu tipo de hospedagem antes de começar economizará tempo. Aumentos nos limites de Shell Exec e memória PHP são controlados no nível do servidor. O que você pode alterar sozinho depende inteiramente do seu plano.

Como Acelerar os Backups do Seu Site

Trabalhar nestas etapas proporcionará os resultados mais rápidos. A primeira etapa é um diagnóstico, para que você saiba quais correções realmente se aplicam à sua situação antes de começar a alterar as configurações.

Veja o que você fará:

• Etapa 1: Identifique o problema de desempenho do seu backup: diagnostique se o seu processo de backup está lento ou quebrado ou se os backups concluídos estão deixando seu site principal lento, pois a correção é diferente para cada um
• Passo 2: Reduza o que é copiado para backup: exclua diretórios de cache, arquivos de log e arquivos de plugin restantes para encolher o tamanho do seu arquivo, que é a maneira mais rápida de reduzir o tempo de compilação.
• Passo 3: Mude para um motor de arquivamento mais rápido: substitua o ZipArchive baseado em PHP pelo Shell Exec para velocidade ou pelo DupArchive para resiliência em hosts com limites de execução PHP restritos.
• Passo 4: Corrija backups lentos do banco de dados: mude o Modo SQL para Código PHP e execute uma limpeza do banco de dados para reduzir o tempo de exportação em bancos de dados com mais de 20 MB.
• Passo 5: Substitua o cron do WordPress por um job cron de servidor real: faça com que os backups agendados sejam executados no horário exato que você definir, em vez de dispararem sempre que o primeiro visitante chegar.
• Passo 6: Configure uma estratégia de backup com duas programações: execute backups diários apenas do banco de dados e backups semanais do site completo separadamente, para que compilações pesadas ocorram com a menor frequência possível.
• Passo 7: Solicite limites de recursos do servidor mais altos: aumente os limites de memória e tempo de execução do PHP como último recurso, quando todas as outras configurações já estiverem otimizadas.

Etapa 1: Identifique o Problema de Desempenho do Seu Backup

Existem dois problemas diferentes escondidos em "meu backup está lento".

• Problema A: O processo de backup em si é lento ou está quebrado. Sinais incluem compilações que levam mais de 20 minutos, uma barra de progresso que congela em uma porcentagem específica ou um backup que parece ser concluído, mas falha durante a restauração.
• Problema B: Seus backups estão deixando seu site principal lento. Sinais incluem visitantes ou administradores relatando lentidão durante uma janela de tempo recorrente ou uma ferramenta de monitoramento mostrando um pico no tempo de resposta que ocorre em uma programação previsível.

Para diferenciá-los, comece com o log de compilação do seu plugin de backup. Para o Duplicator, vá para Duplicator Pro » Ferramentas » Logs do Duplicator. Encontre o log do seu backup mais recente.

Outros plugins têm logs semelhantes - verifique as configurações avançadas do seu plugin.

Role até o final. Se você vir um erro de tempo limite, um erro de memória ou uma linha que é cortada no meio do processo, esse é o Problema A. Se o log mostrar que foi concluído, mas seu site ainda está lento, esse é o Problema B.

Mais um cenário que vale a pena nomear antes de prosseguir: se o seu log de compilação disser que o backup foi concluído, mas o backup falhar durante a restauração, um limite de tempo de execução PHP provavelmente cortou a compilação silenciosamente antes que ela terminasse.

O arquivo existe, mas foi truncado. Parece o Problema A, mas a causa raiz é um limite de recursos de hospedagem. O Passo 3 cobre isso diretamente.

Se precisar de ajuda para ler os logs de backup do Duplicator, leia este guia.

Etapa 2: Reduza o Que é Incluído no Backup

Cada megabyte extra no seu backup estende o tempo de compilação. Em hospedagem compartilhada, onde CPU e I/O de disco já estão restritos, um arquivo inchado torna os backups mais lentos e o aproxima do limite de tempo limite, onde os backups começam a falhar.

A maneira mais rápida de encolher seu backup é parar de incluir arquivos que não precisam estar lá.

Os infratores mais comuns:

• Diretórios de cache
• Arquivos de log
• Arquivos temporários
• Arquivos de backup deixados por outros plugins
• Arquivos de mídia grandes, como vídeos, que você também armazena em uma CDN ou serviço externo

Nada disso afeta sua capacidade de restaurar um site funcional. Caches são regenerados automaticamente quando visitantes carregam páginas. Logs não fazem parte do seu site. Arquivos de backup antigos de outros plugins apenas adicionam peso.

Veja como personalizar backups no Duplicator Pro. Crie um novo backup acessando Duplicator Pro » Backups » Add New.

Na seção Backup, você verá predefinições e filtros.

Ative os filtros de arquivo. Exclua primeiro seu diretório de cache selecionando o filtro de cache.

Se você usa um plugin de cache como WP Rocket ou W3 Total Cache, pode haver uma subpasta específica do plugin dentro de wp-content também. Adicione o caminho completo para cada um.

Em seguida, adicione quaisquer diretórios de log. Locais comuns incluem wp-content/debug.log e pastas de log específicas de plugins.

Não exclua wp-content/uploads a menos que você armazene toda a sua mídia em uma CDN separada e tenha uma cópia confirmada e atual de cada arquivo. Exclua apenas extensões de arquivo específicas das quais você tem certeza de que estão em backup em outro lugar. Errar a mídia aqui significa uma restauração bem-sucedida, mas faltando metade das suas imagens.

Depois de adicionar seus filtros, continue com o backup. O Duplicator Pro analisará seu site e relatará quaisquer outros tamanhos de arquivo grandes.

Etapa 3: Mude para um Mecanismo de Backup Mais Rápido

Assim que o arquivo de backup estiver o mais enxuto possível, a próxima variável é como o backup é criado. Por padrão, ele usa o ZipArchive integrado do PHP. Isso funciona, mas é executado inteiramente dentro do PHP, o que significa que está sujeito a todos os limites de recursos que seu host define: tempo de execução, memória e limitação de CPU.

Em um servidor capaz, provavelmente está tudo bem. Em hospedagem compartilhada, isso pode criar gargalos.

Você tem duas alternativas, e qual usar depende do seu host.

Opção A: Shell Zip

Isso muda o mecanismo de arquivo de backup de PHP para o binário zip nativo do seu servidor. A ferramenta zip do sistema operacional é mais rápida que o PHP para a maioria das tarefas de compressão e não conta contra seu limite de tempo de execução do PHP da mesma forma.

Para mudar, acesse Duplicator Pro » Settings » Backups » Archive e selecione Shell Zip.

Antes de fazer a mudança, saiba disto: alguns hosts compartilhados de baixo custo desabilitam shell_exec no nível do servidor. Se você alterar a configuração e sua próxima compilação falhar imediatamente em 0%, foi isso que aconteceu.

Volte para ZipArchive na mesma tela de configurações, então entre em contato com seu host e peça para eles habilitarem shell_exec para sua conta. Se eles não puderem ajudar, passe para a Opção B.

Opção B: DupArchive

Este é o formato de arquivo próprio do Duplicator, e funciona de forma diferente do ZIP padrão. Em vez de uma operação de compressão contínua, o DupArchive processa seus arquivos em pedaços menores. Cada pedaço é concluído antes que o próximo comece.

Em planos de hospedagem compartilhada com limites de tempo de execução do PHP de 30 a 60 segundos, um backup ZIP padrão que leva mais tempo do que esse limite é interrompido no meio da compilação. O processo para, mas o arquivo já foi gravado no disco.

Seu backup parece completo. Então, quando você tenta restaurá-lo, ele falha. O arquivo foi cortado antes de terminar.

O DupArchive evita isso completamente. Como cada bloco redefine o relógio de execução do PHP, o backup sobrevive a limites que matariam uma construção ZIP padrão. Já vi essa correção resolver problemas em hospedagem compartilhada mais de uma vez.

Para alternar, vá para Duplicator Pro » Configurações » Backups » Arquivo e escolha DupArchive.

Após alternar para qualquer uma das opções, execute um backup de teste. Crie um backup pequeno e, em seguida, verifique o log quando ele terminar. Role até o final do log e confirme que ele foi concluído com sucesso.

Etapa 4: Corrigir backups lentos do banco de dados

Um banco de dados grande retarda toda a construção do backup, não apenas a parte em que o banco de dados é exportado. Se o seu banco de dados estiver inchado, você sentirá isso em todo o processo.

Para encontrar o tamanho do seu banco de dados, inicie um novo backup no Duplicator Pro e deixe o assistente de configuração executar a verificação. Ele listará o tamanho do seu banco de dados antes de você se comprometer a criar o backup.

Se for superior a 20 MB, essas correções podem fazer uma diferença notável.

Correção 1: Mudar Modo SQL para Código PHP

Vá para Duplicator Pro » Configurações » Backups » Modo SQL e altere a configuração de MySQL dump para Código PHP. Isso muda o método que o Duplicator usa para exportar suas tabelas de banco de dados.

O método Código PHP é geralmente mais confiável em hospedagem compartilhada porque é menos provável que acione timeouts de bloqueio de tabela que interrompem a exportação. É uma pequena mudança com um efeito significativo em bancos de dados maiores.

Correção 2: Limpar o banco de dados antes do próximo backup

Esta leva alguns minutos, mas vale a pena fazer antes de qualquer backup importante.

Instale o WP-Optimize ou um plugin de limpeza de banco de dados semelhante e execute-o para remover revisões de posts, comentários de spam, transientes expirados e metadados órfãos. Estes se acumulam silenciosamente em sites ativos e podem representar de 30 a 50 por cento do inchaço do banco de dados sem conter nada que você realmente precise restaurar.

No meu site pessoal, executei um backup antes e depois de uma limpeza rápida do banco de dados com o WP-Optimize. Isso cortou 30 segundos do meu tempo de backup e reduziu o tamanho do arquivo.

No entanto, não limpe seu banco de dados e execute imediatamente um backup crítico pela primeira vez. Execute a limpeza, navegue pelo seu site e verifique se tudo funciona normalmente, e então faça o backup. Limpezas são seguras quando feitas com uma ferramenta confiável, mas você quer confirmar se o seu site está saudável antes de travar esse estado em um backup.

Após fazer ambas as alterações, execute um novo backup e compare o tempo de construção com sua linha de base anterior. Em bancos de dados com mais de 20 MB, a diferença geralmente é visível.

Etapa 5: Substitua o WordPress Cron por um Cron Real do Servidor

Se seus backups estão agendados, mas continuam rodando na hora errada, ou se seu site fica lento durante o horário comercial em vez da janela de tranquilidade que você definiu, o cron do WordPress é provavelmente o motivo.

O WP-Cron não roda em um horário real. Ele dispara apenas quando alguém visita seu site.

Quando o tráfego chega, o WordPress verifica se há tarefas agendadas atrasadas e as executa naquele momento. Um backup que você agendou para as 3 da manhã roda quando o primeiro visitante aparece, o que pode ser bem no meio da sua janela de tráfego de pico.

Substituir o WP-Cron por um cron job do servidor garante que seus backups sejam executados no horário exato que você definir, todas as vezes, independentemente do tráfego.

Comece criando uma conta em https://cron-job.org/. Em seguida, crie um novo cron job.

Nomeie o novo cron job. Defina isso como a URL, substituindo-o pelo domínio do seu site: https://example.com/wp-admin/admin-ajax.php?action=duplicator_process_worker

Defina o Agendamento de execução para A cada 1 minuto.

Assim que o cron job do servidor estiver ativo e salvo, adicione esta linha ao seu arquivo wp-config.php, acima da linha que diz "That's all, stop editing!":

define('DISABLE_WP_CRON', true);

Isso instrui o WordPress a parar de executar seu próprio sistema de cron.

Adicione a linha `define` ao wp-config.php somente após o cron job do servidor ser confirmado e salvo. Se você desabilitar o WP-Cron primeiro, todas as tarefas agendadas em seu site pausarão imediatamente. Backups agendados, posts agendados, qualquer coisa que dependa do WP-Cron para de funcionar até que o cron do servidor esteja ativo.

Se você estiver em uma hospedagem WordPress gerenciada como WP Engine, Kinsta ou Flywheel, consulte a documentação de sua hospedagem antes de editar o wp-config.php. Algumas hospedagens gerenciadas lidam com o cron do servidor de forma diferente ou o gerenciam em seu nome.

Após a configuração, retorne a Duplicator Pro » Configurações » Agendar Backups e verifique se o horário da próxima execução agendada reflete exatamente o que você configurou. Essa confirmação é o seu sinal de que a transição funcionou.

Etapa 6: Configure uma Estratégia de Backup com Dois Cronogramas

Backups diários do site completo são uma das causas mais comuns de backups lentos e sites lentos em hospedagem compartilhada. Eles também são, para a maioria dos sites WordPress, mais do que você realmente precisa.

Seu banco de dados muda constantemente, com novos posts, pedidos, envios de formulários, comentários e atividade de plugins. Em contraste, seus arquivos, temas, plugins e uploads são atualizados ocasionalmente.

Executar um backup completo todos os dias significa compactar e arquivar gigabytes de arquivos que não foram alterados recentemente.

A solução são dois agendamentos de backup separados.

• Agendamento A: backup diário apenas do banco de dados. Um backup apenas do banco de dados captura todas as alterações em seu conteúdo, pedidos e configurações sem tocar em seus arquivos. Na maioria dos sites, ele é concluído em menos de 30 segundos. Execute isso diariamente.
• Agendamento B: backup semanal do site completo. Incluindo arquivos, execute uma vez por semana durante sua janela de menor tráfego real. Este é o backup que você restaura se algo der muito errado.

Antes de definir o agendamento, encontre sua janela real de menor tráfego. Procure pelo bloco de duas horas com o menor número de sessões em uma semana típica.

Para a maioria dos sites, isso acontece entre 2h e 5h da manhã, mas verifique com seus próprios dados. Seu padrão de tráfego não é o mesmo de ninguém.

Em seguida, vá para Duplicator Pro » Agendar Backups » Adicionar Novo. Nomeie o agendamento como algo como Backup do Banco de Dados. Adicione um novo modelo de backup.

Nomeie o modelo. Escolha a predefinição de backup Somente Banco de Dados e salve-a.

Volte para o novo agendamento e escolha o modelo de backup do banco de dados que você acabou de criar. Escolha um local de armazenamento e defina para ser executado diariamente.

Salve. Em seguida, crie um segundo agendamento e repita o processo, mas com um modelo de backup de site completo. Deixe-o rodar semanalmente.

Ambos os agendamentos aparecerão em Duplicator Pro » Agendamentos de Backup com seus próximos horários de execução listados.

Etapa 7: Adicione Backups Incrementais

Backups completos comprimem todo o seu site do zero toda vez que são executados. Isso é bom para backups semanais de site completo, mas é mais do que a maioria dos sites precisa para proteção diária.

Backups incrementais seguem uma abordagem diferente: após o primeiro backup completo, eles salvam apenas o que mudou desde a última execução. O backup é concluído mais rapidamente porque não está reprocessando arquivos que não foram alterados.

O Duplicator Pro não executa backups incrementais verdadeiros, mas a estratégia de dois agendamentos da Etapa 6 oferece a maior parte do mesmo benefício. Backups diários apenas do banco de dados capturam tudo o que muda em um site WordPress típico, concluindo em menos de 30 segundos. O backup semanal completo cuida de todo o resto.

Para a maioria dos sites, essa divisão cobre a necessidade prática que os backups incrementais são projetados para resolver.

Se o seu site for grande o suficiente para que até mesmo os backups semanais completos sejam consistentemente lentos ou falhem, backups incrementais de arquivos podem valer a pena implementar. Ferramentas como o BlogVault processam backups em seus servidores em vez dos seus, o que remove o problema de carga do servidor.

Etapa 8: Solicite Limites de Recursos do Servidor Mais Altos

Os limites de memória e tempo de execução do PHP são restrições reais, mas alterá-los requer a cooperação do seu host e não resolve problemas subjacentes como um arquivo compactado inchado ou um agendamento mal cronometrado.

Trabalhe nas etapas anteriores primeiro. Se os backups ainda estiverem expirando, o limite pode ser os limites de recursos do seu plano de hospedagem.

Duas configurações são mais importantes para a velocidade de backup: memory_limit e max_execution_time.

memory_limit controla quanta RAM o PHP pode usar durante um único processo. Backups consomem muita memória. Se o seu limite estiver definido como 64MB ou 128MB, compilações grandes ficam sem espaço e morrem antes de terminar.

Peça pelo menos 256MB. Se o seu host oferecer 512MB, solicite isso em vez disso.

max_execution_time controla quanto tempo um processo PHP pode ser executado antes que o servidor o encerre. O padrão em muitos hosts compartilhados é de 30 a 60 segundos. Um backup grande precisa de significativamente mais do que isso. Peça 300 segundos.

Entre em contato com a equipe de suporte do seu host e seja específico em sua solicitação. Peça um memory_limit de 512MB e um max_execution_time de 300 segundos.

Se o seu host não puder ou não quiser aumentar esses limites, o DupArchive da Etapa 3 é o seu caminho prático. Ele foi projetado especificamente para funcionar dentro de limites apertados de PHP, dividindo o processo. É mais lento que o Shell Exec em um servidor capaz, mas termina onde uma compilação ZIP padrão não conseguiria.

Após qualquer alteração de limite, execute um backup de teste e abra o log de compilação. Confirme se o backup foi concluído sem erros de tempo limite ou de memória.

Solução de problemas: Quando os backups ainda estão lentos ou quebrados

Trabalhar nas etapas acima resolve a maioria dos problemas de velocidade de backup de sites. Se algo ainda estiver errado, aqui está o que você provavelmente está vendo e como superar isso.

Backup Concluído, Mas Falha na Restauração

Você vê um backup, o log de compilação não mostra erros óbvios, mas quando você executa o instalador, ele falha ou restaura um site em branco.

Isso acontece porque um limite de tempo de execução do PHP cortou a compilação antes que ela terminasse de fato. O arquivo foi gravado no disco até aquele ponto e depois parou.

Mude para DupArchive (abordado na Etapa 3), depois exclua o backup com falha e crie um novo. Execute o instalador e verifique se a restauração é concluída antes de confiar nele.

Backup Travado em uma Porcentagem Específica

A barra de progresso congela em um ponto específico e permanece lá por mais de dez minutos sem se mover.

Um arquivo grande ou uma tabela de banco de dados bloqueada está impedindo o processo naquele ponto exato da compilação. Vá para o log de backup e role para encontrar o último arquivo ou tabela listado antes que o log seja cortado. Esse é o culpado.

Se for um arquivo, adicione-o aos seus filtros de exclusão (Etapa 2) e reconstrua. Se for uma tabela de banco de dados, mude o Modo SQL para Código PHP (Etapa 4) e tente novamente.

Site Fica Lento Todas as Noites na Mesma Hora

Visitantes ou sua ferramenta de monitoramento relatam lentidão durante uma janela específica. O tempo coincide com o seu backup agendado.

Seu backup está sendo executado durante um período de tráfego ativo e competindo pelos mesmos recursos de CPU e disco que atendem seus visitantes. Verifique sua janela de baixo tráfego real no Google Analytics e reagende o backup para esse horário.

Se você estiver executando backups diários de todo o site, mude para a estratégia de duas programações da Etapa 6. Backups apenas do banco de dados são concluídos rápido o suficiente para que o impacto no desempenho seja mínimo, mesmo durante tráfego moderado.

Shell Exec Causa Falha Imediata na Criação

Você mudou o mecanismo de arquivamento para Shell Exec, e a próxima compilação falha em 0% com um erro imediato.

Seu host desabilitou o shell_exec no nível do servidor. Volte para ZipArchive ou DupArchive. Em seguida, entre em contato com seu host e pergunte especificamente se o shell_exec pode ser habilitado para sua conta.

Se eles disserem não, o DupArchive é seu mecanismo de arquivamento de longo prazo. Ele lida com os mesmos problemas de tempo limite que o Shell Exec teria resolvido, apenas por meio de um método diferente.

Backups Funcionam em Staging, Mas Falham no Servidor Principal

Seus backups são bem-sucedidos em staging ou sites locais, mas expiram ou produzem arquivos corrompidos em produção.

Seu servidor ativo tem limites de PHP mais rigorosos ou está sob limitação ativa de CPU que seu ambiente de staging não possui. Compare as configurações de PHP entre os ambientes: verifique memory_limit e max_execution_time em ambos. Solicite limites mais altos do seu host ativo (Etapa 7) ou mude para o DupArchive para trabalhar dentro de quaisquer limites existentes.

Se nenhuma das opções acima resolver seu problema, a equipe de suporte do Duplicator Pro é o próximo passo certo. Vá para duplicator.com e abra um ticket de suporte. Inclua seu log de compilação, suas configurações de PHP e seu ambiente de hospedagem. Essas três informações o levarão a uma resolução mais rápida do que uma descrição genérica do problema.

Perguntas Frequentes (FAQs)

Uma construção ZIP padrão que leva mais tempo que o limite do seu host é encerrada no meio do processo e produz um pacote corrompido. O DupArchive sobrevive a esses limites porque cada bloco reinicia o relógio.

Nem sempre é mais rápido que o ZIP em servidores capazes, mas é significativamente mais confiável em ambientes de hospedagem compartilhada restritos.

A pergunta mais importante é se você testou uma restauração recentemente. Um backup que você nunca testou é um backup que você realmente não sabe se funciona. Escolha um ambiente de staging, restaure seu backup mais recente e verifique se o site carrega corretamente.

Execute Seu Próximo Backup Sem Se Perguntar Se Funcionará

Um backup lento é um inconveniente. Um backup que parece completo, mas não pode ser restaurado, é um problema completamente diferente e é mais comum do que a maioria das pessoas espera.

As configurações neste tutorial existem porque a hospedagem compartilhada não foi projetada com backups do WordPress em mente. O Duplicator Pro foi.

Mais de 1,5 milhão de profissionais de WordPress usam o Duplicator Pro para lidar com backups, migrações, staging e recuperação de desastres em sites de todos os tamanhos. O formato DupArchive, a estratégia de duas programações e os filtros de exclusão de arquivos ajudam você a evitar backups lentos ou que consomem muitos recursos.

Se este tutorial ajudou, estes guias também valem a pena ser marcados.

• Como os Backups do WordPress Afetam o Desempenho do Site (e Como Corrigir)
• Pare de Adivinhar Por Que os Backups Falham (Verifique Estes Logs em Vez Disso)
• Site Acabou de Cair? Aqui Está Seu Plano Completo de Recuperação de Site
• Por Que Seu Site WordPress Precisa de Monitoramento de Backup (Não Apenas Backups)
• Como Visualizar Seu Backup do WordPress Como um Site Funcional