Como as cópias de segurança do WordPress afetam o desempenho do site (e como resolver isso)

No ano passado, estava a tentar resolver um problema de lentidão num site e não consegui encontrar nada de óbvio. Não havia plugins novos, nem picos de tráfego, nem nada de especial nos registos de erros.

Depois, verifiquei a programação do backup. Estava configurada para ser executada ao meio-dia, todos os dias, numa conta de alojamento partilhado. Era isso mesmo.

A maioria dos utilizadores do WordPress instala um plugin de cópias de segurança, define um horário e nunca mais volta a tocar nele. É uma daquelas tarefas que parece estar concluída assim que o plugin é ativado.

No entanto, as configurações predefinidas da maioria dos plugins de cópia de segurança não estão otimizadas para o desempenho. Estão otimizadas para a simplicidade.

Fazer uma cópia de segurança completa diária e guardá-la no Dropbox parece uma medida sensata. Num site pequeno com um serviço de alojamento generoso, é mesmo. Num site maior ou num alojamento partilhado mais económico, trata-se de um impacto recorrente no desempenho, que pode até fazer com que nem sequer consiga estabelecer ligação às cópias de segurança.

Neste artigo, vou mostrar-lhe o que acontece quando se executa uma cópia de segurança, por que razão algumas configurações sobrecarregam mais o servidor do que outras e as alterações específicas que reduzem esse impacto quase a zero.

Eis as principais conclusões:

• As cópias de segurança consomem muitos recursos: a compressão de ficheiros, a exportação de bases de dados e o envio para a nuvem consomem simultaneamente uma quantidade significativa de CPU, E/S de disco e largura de banda.
• Os limites da hospedagem partilhada podem causar falhas silenciosas: os tempos de espera ocultos do PHP e as quotas de CPU/E/S em serviços de hospedagem económicos muitas vezes interrompem os backups de longa duração a meio do processo, deixando-o com ficheiros corrompidos ou incompletos.
• O formato de cópia de segurança é importante: os arquivos ZIP padrão são processados numa única passagem contínua, o que os torna altamente vulneráveis a tempos de espera do servidor. Formatos fragmentados, como o DupArchive personalizado do Duplicator, contornam totalmente essas limitações.
• A otimização é fácil: é possível eliminar quase totalmente a perda de desempenho executando as cópias de segurança fora dos horários de pico, excluindo os ficheiros de cache, recorrendo ao cron do servidor e agendando cópias de segurança apenas da base de dados com maior frequência do que as cópias de segurança completas do site.

Índice

O que acontece no seu servidor quando é executada uma cópia de segurança?

Uma cópia de segurança não consiste apenas em copiar os seus ficheiros para outro local. Trata-se de um processo em várias etapas que decorre inteiramente no seu servidor, competindo pelos mesmos recursos que servem o seu site aos visitantes.

Enquanto o backup está a ser executado, o seu servidor está a realizar duas tarefas ao mesmo tempo. Na hospedagem partilhada, onde esses recursos já estão divididos entre dezenas de outros sites, isso faz diferença.

Compressão de ficheiros e carga da CPU

Durante um backup, todos os ficheiros da sua instalação do WordPress são lidos e compactados num arquivo. Esse processo consome muitos recursos da CPU.

Na hospedagem partilhada, a sua conta dispõe de uma parte limitada da capacidade de processamento do servidor, e uma cópia de segurança que comprima centenas de megabytes de ficheiros irá consumir grande parte dessa capacidade.

Os sites maiores agravam esta situação. Um maior número de ficheiros implica um tempo de compressão mais longo, o que significa que a CPU fica sob pressão durante mais tempo.

Um blogue pequeno com poucos ficheiros multimédia pode ser comprimido em menos de um minuto. Um site com imagens carregadas ao longo de vários anos pode demorar muito mais tempo.

Quer reduzir instantaneamente o tamanho da sua biblioteca multimédia para metade? Elimine as variações de imagens não utilizadas com o WP Media Cleanup!

Exportação de bases de dados e bloqueio de tabelas

A exportação da base de dados é frequentemente o culpado oculto. A maioria dos utilizadores pensa nos seus ficheiros quando imagina uma cópia de segurança, mas o WordPress armazena as suas publicações, definições, utilizadores e tudo o resto numa base de dados MySQL, o que requer um processo de exportação separado.

A maioria dos plugins de cópia de segurança exporta a base de dados utilizando um método que bloqueia temporariamente as tabelas que está a ler. Enquanto essas tabelas estão bloqueadas, as consultas do WordPress que chegam têm de esperar.

Mesmo que seja apenas por alguns segundos, o bloqueio de uma tabela pode provocar erros de tempo limite num servidor lento ou sobrecarregado.

E/S de disco: o gargalo que a maioria das pessoas ignora

A leitura de milhares de ficheiros durante um backup gera uma atividade considerável no disco. O armazenamento do seu servidor tem um limite quanto ao número de operações de leitura e gravação que consegue processar por segundo, e um backup que abrange toda a sua instalação do WordPress leva esse limite ao limite.

Os servidores de alojamento económico e partilhado continuam frequentemente a utilizar discos rígidos tradicionais em vez de SSDs. Nesses servidores, a elevada atividade do disco durante um backup atrasa todos os processos relacionados com o armazenamento, incluindo as consultas à base de dados e as leituras de ficheiros que geram as suas páginas.

Carregamento na nuvem e largura de banda

O impacto no desempenho não termina quando a criação do arquivo fica concluída. A maioria das configurações de backup carrega esse arquivo para um serviço de armazenamento na nuvem: Dropbox, Google Drive ou S3. Esse carregamento é executado na mesma ligação de servidor que atende os seus visitantes.

O upload de uma cópia de segurança de 2 GB para o Dropbox, a uma velocidade de upload típica de um alojamento partilhado, demora vários minutos. Durante esse período, a largura de banda disponível pode ficar sobrecarregada.

Por que é que o desempenho das cópias de segurança dos serviços de alojamento económicos é inferior?

Os planos de alojamento económico e partilhado impõem limites ao nível do servidor que a maioria dos utilizadores nunca encontra documentados em lado nenhum.

Não se trata de erros de software nem de configurações incorretas. São limites impostos propositadamente para impedir que uma conta consuma recursos que afetem todos os outros sites no mesmo servidor.

O problema é que esses mesmos limites interferem nos processos de cópia de segurança, e as falhas que provocam nem sempre são evidentes.

Limites de tempo do PHP

O PHP tem uma configuração de tempo máximo de execução. Em servidores partilhados económicos, este tempo é frequentemente definido entre 30 e 60 segundos. Um processo de cópia de segurança num site de maior dimensão pode demorar muito mais tempo do que isso e, quando atinge o limite, o servidor interrompe o processo a meio da execução.

O resultado é um ficheiro de arquivo incompleto. Parece que existe uma cópia de segurança. O ficheiro está lá, mas foi interrompido antes de terminar, o que significa que não é possível restaurá-lo.

O site sofreu todo o impacto no desempenho causado por uma cópia de segurança em execução e não obteve nenhum resultado fiável. Um ficheiro de cópia de segurança corrompido é pior do que não ter nenhuma cópia de segurança, pois cria uma falsa sensação de segurança, levando a crer que se está protegido quando, na verdade, não se está.

Quotas de CPU e E/S

A maioria dos serviços de alojamento partilhado limita o uso da CPU por conta. Quando atinge o limite, o serviço de alojamento não interrompe os seus processos de imediato. Em vez disso, abranda-os. Tudo o que está a ser executado na sua conta fica mais lento, incluindo os pedidos de páginas recebidos dos visitantes.

Os limites de E/S funcionam da mesma forma. A sua conta tem um limite máximo de operações de leitura e gravação por segundo. Uma cópia de segurança que comprima uma grande biblioteca multimédia atingirá frequentemente esse limite.

É por isso que algumas cópias de segurança são bem-sucedidas às 3 da manhã, mas falham ao meio-dia com configurações idênticas. As horas fora do pico implicam uma carga de base mais baixa no servidor, o que significa mais margem antes de a quota entrar em ação.

O formato do ficheiro de cópia de segurança é importante?

A maioria dos plugins de cópia de segurança utiliza, por predefinição, arquivos ZIP. Não é uma má escolha para um site pequeno num servidor com bons recursos. Mas o formato ZIP processa os ficheiros sequencialmente, um de cada vez, numa única passagem ininterrupta.

Num ambiente de alojamento partilhado com recursos limitados, essa única execução ininterrupta é exatamente o que os tempos limite do PHP foram concebidos para interromper.

O formato de arquivo utilizado pelo seu plugin de backup determina o nível de carga que este impõe ao servidor e se este consegue suportar as limitações de um serviço de alojamento económico. Este aspeto quase nunca é abordado nas conversas sobre o desempenho dos backups e, muitas vezes, é o que distingue um backup que é concluído de forma fiável de outro que falha silenciosamente.

Como o DupArchive lida com as restrições do servidor

O Duplicator é um plugin de cópias de segurança para o WordPress com um formato de cópia de segurança próprio chamado DupArchive. Foi desenvolvido especificamente para cópias de segurança e migrações do WordPress, tendo em conta as limitações de alojamento económico como um dos principais fatores de conceção.

Enquanto um processo ZIP padrão é executado como uma operação contínua, o DupArchive funciona em blocos mais pequenos. Cada bloco é concluído dentro dos limites de tempo de execução do servidor e, em seguida, o processo retoma a partir do ponto em que ficou.

Os tempos de espera do PHP que interromperiam um backup em formato ZIP a meio da execução não têm o mesmo efeito, porque cada bloco é suficientemente curto para ser concluído antes de o limite ser atingido.

Além disso, suporta sites de maior dimensão sem o limite de tamanho de ficheiro que provoca falhas no ZIP. Já foram realizadas migrações reais com o DupArchive que ultrapassaram os 400 GB!

Para a maioria dos utilizadores de alojamento partilhado, essa margem de manobra significa que o formato funciona sem problemas, enquanto uma abordagem baseada em ZIP resultaria num tempo de espera excessivo ou na corrupção dos ficheiros.

Consulte aqui a lista completa de configurações que aceleram um backup lento.

Shell Zip vs. ZipArchive

O Duplicator permite-lhe escolher o mecanismo de arquivo de cópia de segurança.

O Shell Zip delega a compressão ao sistema operativo, em vez de a executar através do PHP. É significativamente mais rápido quando disponível, porque o sistema operativo lida com a compressão de forma mais direta do que um processo PHP.

Os fornecedores de alojamento Budget desativam, por vezes, o Shell Zip. Se for esse o caso, pode pedir-lhes que o ativem ou considerar isso como um indício de que o processamento por partes do DupArchive do Duplicator é a alternativa adequada.

Estas duas opções cobrem, entre si, a maioria dos ambientes de alojamento: o Shell Zip para maior rapidez quando o alojamento o permite e o DupArchive para maior fiabilidade quando isso não é possível.

Como fazer cópias de segurança sem tornar o seu site mais lento

O objetivo é tornar as cópias de segurança invisíveis para os visitantes. Estas são executadas, concluídas e carregadas sem que ninguém note qualquer diferença na velocidade do site.

Isso é possível na maioria das configurações com apenas algumas alterações nas definições. Nenhuma delas requer mudar de alojamento ou contratar um programador.

As formas mais eficazes de realizar cópias de segurança sem tornar o seu site mais lento:

• Programe as cópias de segurança para horários de baixo tráfego: o timing é fundamental. Identificar as horas de menor movimento do seu site garante que as cópias de segurança não disputem os recursos do servidor com os visitantes reais.
• Excluir ficheiros que não precisam de ser incluídos na cópia de segurança: a remoção de diretórios de cache, registos e ficheiros temporários reduz drasticamente o tamanho da cópia de segurança, poupando recursos da CPU e operações de E/S do disco.
• Faça cópias de segurança da base de dados com mais frequência do que cópias de segurança completas: uma vez que a sua base de dados muda constantemente, mas os seus ficheiros não, a realização de cópias de segurança diárias e rápidas da base de dados permite-lhe reduzir a frequência das cópias de segurança completas do site para apenas uma vez por semana.
• Utilize o cron do servidor em vez do WP-Cron: ao mudar da programação do WordPress, que depende do tráfego, para uma tarefa cron dedicada no servidor, garante-se que as cópias de segurança sejam executadas exatamente quando devem ser.

Programe as cópias de segurança para horários de baixo tráfego

O momento certo é a solução mais eficaz disponível, independentemente do seu plano de alojamento. Uma cópia de segurança executada às 3 da manhã num servidor com pouca atividade tem muito mais margem de manobra do que a mesma cópia de segurança executada ao meio-dia, em concorrência com o tráfego real de visitantes.

A recomendação padrão é entre as 2h e as 5h da manhã, hora local. Isso aplica-se à maioria dos sites, mas vale a pena verificar as suas estatísticas reais.

Abra o MonsterInsights, analise o tráfego por hora e identifique o seu verdadeiro período de menor tráfego. Alguns sites que se destinam a um público internacional não apresentam um período claro de baixo tráfego. Outros atingem o seu ponto mais baixo no início da noite, em vez de durante a madrugada. Organize-se com base nos seus dados, e não numa regra genérica.

Não programe cópias de segurança durante os períodos de maior tráfego. Se enviar uma newsletter às 9h00 às terças-feiras, não execute uma cópia de segurança às 9h00 às terças-feiras. Os picos de tráfego causados pelas campanhas ocorrem precisamente nos momentos em que não se quer uma carga adicional no servidor.

Excluir ficheiros que não precisam de ser copiados

A forma mais rápida de reduzir a carga de backup é diminuir a quantidade de dados a ser copiada. Arquivos mais pequenos são comprimidos mais rapidamente, carregam mais depressa e exercem menos pressão sobre a E/S do disco ao longo do processo.

Os diretórios de cache são o maior benefício. O seu plugin de cache regenera-os automaticamente quando o site é carregado, pelo que não faz sentido fazer uma cópia de segurança deles.

Também vale a pena excluir:

• Ficheiros de registo
• Pastas temporárias de upload
• Quaisquer ficheiros de arquivo deixados no servidor por outros plugins de cópia de segurança

No Duplicator, utilize filtros de ficheiros e bases de dados para excluir dados desnecessários. Recomendo o filtro de cache integrado.

O relatório de análise pré-backup identifica ficheiros de grande dimensão antes da execução da compilação. Vale a pena analisá-lo antes de definir uma programação recorrente. Dedicar alguns minutos a esse relatório pode reduzir significativamente o tamanho do backup.

Faça cópias de segurança do banco de dados com maior frequência do que cópias de segurança completas

A sua biblioteca multimédia quase não muda. A sua base de dados muda constantemente.

Cada nova publicação, comentário, encomenda e envio de formulário é registado na base de dados. É disso que precisa mesmo de fazer cópias de segurança com frequência.

As cópias de segurança diárias apenas da base de dados são rápidas, concluindo-se frequentemente em menos de 30 segundos, e representam uma carga mínima para o servidor. Reserve as cópias de segurança completas do site (ficheiros e base de dados) para execuções semanais em horários de menor movimento.

Esta abordagem permite-lhe obter pontos de recuperação frequentes para os dados mais importantes, mantendo o processo pesado de cópia completa do site como algo pouco frequente.

Utilize o Cron do servidor em vez do WP-Cron

O WordPress possui um sistema de agendamento integrado chamado WP-Cron. O problema é que só é acionado quando alguém visita o site.

Se ninguém visitar o site às 3 da manhã, a cópia de segurança não é executada. Pior ainda, um visitante ao meio-dia pode, inadvertidamente, acionar uma cópia de segurança programada para ser executada durante a noite.

Uma tarefa cron num servidor real é executada de acordo com um horário fixo, independentemente do tráfego. A maioria dos painéis de controlo de alojamento permite aceder à configuração do cron.

Configurar um para o seu plugin de cópias de segurança demora apenas alguns minutos e elimina completamente a imprevisibilidade do WP-Cron. A documentação do Duplicator explica o processo de configuração do cron do lado do servidor, caso ainda não o tenha feito.

Sinais de que as suas cópias de segurança estão a afetar o desempenho do site

Pode não associar a lentidão do site às cópias de segurança, porque a relação temporal não é óbvia. Uma cópia de segurança a ser executada a uma hora invulgar não avisa. Mas há padrões que vale a pena procurar se o seu site tem estado lento e não conseguiu identificar a causa.

Estes são os sinais que indicam que as cópias de segurança estão a tornar o seu site mais lento:

• As lentidões do site atingem o pico à mesma hora todos os dias ou todas as semanas, coincidindo com a sua programação de cópias de segurança
• Os registos de cópias de segurança indicam execuções com falha, incompletas ou em falta
• O seu painel de controlo de alojamento apresenta picos de CPU ou de E/S num horário previsível
• Os visitantes referem lentidão que não corresponde aos seus horários habituais de pico de tráfego

Se dois ou mais desses itens corresponderem ao que está a ver, verifique primeiro a sua programação de cópias de segurança antes de investigar qualquer outra coisa.

Proteja o seu site antes de fazer qualquer alteração

Antes de ajustar os horários de cópia de segurança, mudar os formatos de arquivo ou alterar quaisquer definições do servidor: faça primeiro uma cópia de segurança completa.

Parece óbvio, mas é fácil esquecer-se disso quando se está a meio de um processo de resolução de problemas e se está impaciente por resolver a situação. Foi exatamente isso que me aconteceu e acabei por criar uma lacuna no meu histórico de cópias de segurança mesmo antes de fazer alterações que não correram como esperado.

Erros de configuração durante a configuração do backup podem deixar-te sem qualquer backup funcional. A ironia de comprometer a tua rede de segurança de backup ao tentar melhorar a sua configuração é bem real.

Se quiser testar novas configurações de agendamento ou de ficheiros de cópia de segurança antes de as aplicar ao seu site ativo, o ambiente de teste oferece-lhe um ambiente isolado para confirmar primeiro se tudo funciona corretamente.

O Duplicator Pro permite-lhe criar um site de teste a partir de qualquer cópia de segurança existente com apenas alguns cliques. Não é necessária uma conta de alojamento separada.

Depois de criar o ambiente de teste, poderá resolver problemas sem correr riscos.

Perguntas mais frequentes (FAQs)

O seu site merece uma solução de cópia de segurança que funcione em perfeita sintonia com ele

Os backups devem proteger o seu site, não sobrecarregá-lo. A perda de desempenho causada por um backup mal configurado é real, mas quase sempre é possível resolver o problema sem mudar de alojamento ou ter de reconstruir nada.

Os três fatores mais importantes são: quando é que as cópias de segurança são executadas, o que incluem e que formato utilizam. A maioria dos sites consegue reduzir o impacto no desempenho a quase zero ao ter em conta estes três aspetos.

O seu plugin de cópias de segurança deve proteger o seu site sem competir com ele pelos recursos do servidor. É um equilíbrio mais difícil de alcançar do que parece, especialmente em alojamentos partilhados e económicos, onde as limitações são reais e nem sempre estão documentadas.

Mais de 1,5 milhões de profissionais do WordPress utilizam o Duplicator Pro para gerir cópias de segurança, migrações e recuperação de desastres. O formato DupArchive foi concebido especificamente para os ambientes de alojamento onde as cópias de segurança padrão baseadas em ZIP falham com maior frequência: servidores com recursos limitados, sujeitos a tempos de espera do PHP, quotas de CPU e limites de E/S.

E se quiser testar quaisquer alterações de configuração antes de as aplicar ao seu site ativo, a funcionalidade de staging com um clique permite-lhe criar uma cópia do seu site a partir de qualquer cópia de segurança existente, sem necessidade de uma conta de alojamento separada.

Se este artigo o fez refletir sobre o desempenho das cópias de segurança e o estado do site, vale a pena ler estes guias a seguir.

• Seu site WordPress está sangrando dinheiro a cada segundo que está lento (aqui está a correção)
• Como encriptar ficheiros de cópia de segurança de sítios Web para obter a máxima segurança dos dados
• O site acabou de cair? Aqui está o seu plano completo de recuperação do site
• Políticas de retenção de cópias de segurança de sítios Web: Durante quanto tempo manter as cópias de segurança?
• Por que seu site WordPress precisa de monitoramento de backup (não apenas de backups)