Qual é a melhor forma de fazer uma cópia de segurança do seu sítio Web WordPress?

Qual é a melhor forma de fazer uma cópia de segurança do seu sítio Web WordPress?

Qual é a melhor forma de fazer uma cópia de segurança do seu sítio Web WordPress?

Há quase 14 anos, alguns dos melhores conselhos da história do publicação online foi dispensada.

Foi em maio de 1999 que o filósofo moderno Terius Gray (mais conhecido pelo seu nome artístico ‘Juvenile’), que está no topo das tabelas, aplicou o seu génio lírico à Internet, implorando aos proprietários de sítios Web de todo o mundo que “faça essa coisa voltar.

Para aqueles de vós que não estão a par das últimas definições de calão, “thang”, claro, significa “site.”

Apesar da sua hipérbole, a verdade é que não precisa de ser uma “mulher grande e fina” ou de se referir ao Sr. Gray como “papá grande” para usufruir dos benefícios de uma das decisões mais inteligentes que alguma vez tomará com o seu sítio Web.

Só precisa de ser um proprietário sério de um sítio Web com uma estratégia sólida de recuperação de desastres, cujo primeiro passo é ter sempre cópias de segurança com que possa contar (e controlar).

A melhor forma de fazer cópias de segurança do seu sítio Web?

Então, qual é a melhor forma de fazer uma cópia de segurança do seu site?

Quando se trata de WordPress, existem dois métodos comuns de backup utilizados pela maioria dos proprietários de sites:

  1. Um plug-in do WordPress.
  2. Cópias de segurança do servidor fornecidas por um anfitrião ou cPanel.

Esses métodos funcionam bem… na maioria das vezes. No entanto, há desvantagens.

Primeiro, os plugins são baseados em PHP, que é uma forma ineficiente e pouco fiável de obter backups. Estes plugins, através de PHP, tentam comunicar com o servidor de uma forma que a maioria dos servidores Linux seguros não permitem ou dificultam muito… porque um hacker pode fazer o mesmo.

Por causa disso, os plugins de backup têm que confiar em métodos de fallback que muitas vezes levam a uma alta taxa de falha. Além disso, eles geralmente usam o agendador do WordPress em vez do agendador do Linux, o que também pode levar a problemas de confiabilidade. Isso leva a uma alta taxa de falhas.

Compare isso com a forma como geramos nossos backups diários no Síntese, por exemplo. Fazemos tudo ao nível do Linux e temos talvez uma falha de dois em dois anos.

(Não se preocupe se palavras como “PHP” e “Linux” o estão a assustar, estamos a chegar às coisas boas…)

A segunda desvantagem do método de backup do plugin é que os backups são armazenados dentro do arquivo wp-content pasta. Isto significa que se o seu site for abaixo (ou sofrer corrupção de dados), as suas cópias de segurança também ficarão indisponíveis ou corrompidas.

Quanto aos backups fornecidos pelo host, eles são certamente um bom benefício. Pode ficar descansado sabendo que o seu anfitrião faz uma cópia de segurança diária do seu sítio e armazena uma semana de cópias de segurança.

A maioria dos hosts WordPress gerenciados fornece isso, e deve ser um pré-requisito de qualquer alojamento premium que esteja a considerar.

Também deve ser um pré-requisito que o seu anfitrião armazene estas cópias de segurança numa instalação separada dos seus servidores, caso contrário, existe um ponto único de falha que pode fazer cair o seu site e leve os seus backups com ele.

Mas e se contratar um programador que faz asneira que afunda o seu site e precisa desesperadamente de aceder aos seus ficheiros de cópia de segurança?

Ou se for pirateado e os ficheiros de todo o seu site forem corrompidos?

É provável que tenha de enviar um ticket de suporte e esperar por ajuda. Cada minuto que está à espera representa dólares que está a perder, e mesmo a equipa de suporte mais recetiva nem sempre consegue responder imediatamente a um pedido de restauro.

Existe uma maneira melhor …

Ambas as opções de backups – plugin e fornecido pelo host – são boas opções de segurança, mas são longe do ideal.

Apercebemo-nos disto na Synthesis, e foi por isso que desenvolvemos o nosso Backups pessoais para S3 programar.

Este é um processo ao nível do Linux (não PHP) que faz uma cópia de segurança do seu todo o seu sitee envia-o diariamente para a sua conta Amazon S3.

O que é que isto significa para si?

Significa que os clientes Synthesis que configuram as suas próprias Cópias de Segurança Pessoais têm a tranquilidade de ter cópias de segurança diárias que são armazenadas separadamente dos ficheiros do seu site ativo. Pode aceder a estas cópias de segurança sempre que quiser ou, mais importante ainda, precisa para.

E nem sequer o obrigamos a chamar-nos “big daddy” para ter acesso a Personal Backups for S3. É gratuito para todos os clientes Synthesis, e demora apenas cinco minutos a configurar através do plugin Software Monitor no painel de controlo WP.

4 melhores práticas de recuperação de desastres

Fazer cópias de segurança do seu sítio web é essencial. E para o proprietário de um sítio verdadeiramente sério, ter acesso pessoal imediato às suas cópias de segurança é duplamente essencial.

Mas esse é apenas o primeiro passo para ter um plano sólido de recuperação de desastres.

Vamos analisar quatro práticas recomendadas essenciais de recuperação de desastres.

1. Faça backup de suas coisas.

Nesta altura, compreende que seria uma verdadeira tolice não fazer cópias de segurança do seu site regularmente. Além disso, precisa de encontrar uma forma fiável para que as suas cópias de segurança estejam em o seu controlo.

Além disso, mesmo que armazene cópias de segurança num local fiável (como o Amazon S3), deve descarregar uma cópia de segurança do sítio que funcione para o seu próprio disco rígido, para você possui a derradeira segurança contra falhas.

2. Restaure como último recurso.

Um erro comum quando se trata de recuperação de desastres é saltar primeiro para o que deveria ser o último recurso.

Partindo do princípio de que, no mínimo, o seu anfitrião mantém cópias de segurança diárias para si, raramente está a mais de 24 horas de uma versão limpa do seu site. É ótimo ter isso como alternativa. Mas certifique-se de que é considerado apenas isso: um recurso.

Quando faz um restauro completo do sítio, perde tudo o que foi gerado desde que foi feita a cópia de segurança. Isto pode ser posts, edições, comentários, etc. Porquê ir tão longe quando a maioria dos problemas pode ser resolvida simplesmente substituindo um ficheiro?

3. Pense em “substituir” em vez de restaurar.

Se você ou o seu programador danificarem o seu ficheiro functions.php e este ficar com um ecrã branco no site, não precisa de restaurar o seu site. Só precisa de substituir o ficheiro functions.php danificado por um que seja reconhecidamente bom.

Pode solicitar esta ação específica ao seu alojamento, mas para obter resultados imediatos pode aceder às suas cópias de segurança pessoais, localizar o ficheiro functions.php de uma data em que sabe que estava a funcionar e, em seguida, substituir simplesmente o ficheiro ativo pelo ficheiro de cópia de segurança através de FTP.

Voilà! O seu site está a funcionar novamente e não perdeu nada, exceto alguns minutos de inatividade auto-infligida, que minimizou ao ter uma boa estratégia de recuperação de desastres.

4. Evite desastres em primeiro lugar.

O melhor plano de recuperação de desastres de todos é – obviamente – evitar desastres em primeiro lugar.

Como Ben Franklin disse, “Uma grama de prevenção vale um quilo de cura”.

Existem várias formas de o fazer:

Primeirotenha sempre à mão as suas informações de início de sessão para as contas essenciais. Isso significa preencher o seguinte Lista de verificação de emergência do proprietário do site WP.

Segundo, não edite os ficheiros do WordPress através do editor do painel de controlo. De facto, um empresa de alojamento que tem os seus melhores interesses no coração irá desativar o editor do painel de controlo por defeito.

Faça edite usando FTP e um editor de texto. Se não estiver familiarizado com o FTP, ou se lhe parecer intimidante, este tutorial ser-lhe-á muito útil. A principal vantagem de um editor de texto é que pode Editar/Anular imediatamente as alterações. Esta simples função pode trazer de volta um site que caiu num instante.

Terceiro, faça cópias de segurança de ficheiros individuais antes de edite-os.

Se quiser proteger-se contra um desastre com o functions.php, copie o ficheiro para o seu disco rígido antes de o editar. Depois, se algo correr mal, pode carregar imediatamente a cópia de trabalho a partir do seu ambiente de trabalho, numa questão de segundos, para recuperar o seu site.

Faça isto com qualquer ficheiro que esteja a editar. Demora uma questão de segundos a fazer uma cópia de segurança de um ficheiro. Porque não o faria?

Para si …

Para terminar, permita-me que volte à sabedoria do Sr. Terius “Juvenile” Grey, que fez uma pergunta retórica muito apropriada aos seus ouvintes, que agora lhe coloco a si:

Rapariga, com quem está a brincar? Volte atrás com essa coisa!

Rapariga, rapaz, não importa. Isto está longe de ser uma questão específica de género.

Qualquer proprietário de um site está a brincar desnecessariamente e de forma negligente com o futuro do seu site se não estiver a fazer cópias de segurança diárias e se não existir um plano sólido de recuperação de desastres.

Por isso, faça cópias de segurança do seu sítio Web e saiba exatamente como o vai utilizar quando precisar dele. Se o fizer, poupará energia, tempo e (mais importante) dinheiro.