Como se proteger contra perda de servidor em um orçamento

Sou uma empresa pequena e com pouco orçamento, fornecendo sites e bancos de dados para instituições de caridade e clientes sem fins lucrativos.

Eu tenho alguns servidores Debian Linux VPS e garanto que tenho backups diários para um VPS diferente daquele em que o serviço está hospedado.

Recentemente, uma das minhas empresas de hospedagem me disse que duas unidades falharam simultaneamente e que os dados foram perdidos para sempre. Coisas acontecem, disseram desculpas, o que mais eles poderiam fazer? Mas isso me fez pensar em maneiras econômicas de obter basicamente um VPS novamente no caso de um hardware ou outra falha relacionada ao host.

Atualmente eu teria que

1. Gire um novo VPS
2. Obtenha o backup do último dia (que inclui bancos de dados, raiz da web e configuração específica do site) no VPS e configure-o como o último, etc.
3. Atualize o DNS e aguarde a propagação.

Provavelmente levaria um dia ou mais para conseguir isso, com a propagação de DNS sendo uma grande incógnita, embora eu tenha o TTL definido muito baixo (cerca de uma hora).

Alguns hosts fornecem instantâneos que podem ser usados ​​para replicar uma configuração para um novo VPS, mas ainda existe o IP e isso não ajuda no caso em que a empresa anfitriã cancela / suspende uma conta completamente (estive lendo sobre isso comportamento de certos provedores de hospedagem e isso me assustou! Não estou fazendo nada de spam / desonesto e fico de olho na segurança, mas sei que eles literalmente têm o poder de fazer isso e sou bastante avessa a riscos).

Isso, combinado com a escolha de hosts respeitáveis, é o melhor que posso fazer sem procurar uma solução incrivelmente cara?

Para mim, escolher hosts respeitáveis ​​e fazer backups regulares - os quais você já parece estar fazendo - é tão bom quanto você pode fazer sem começar a pensar em planejamento de continuidade de negócios, configurações de alta disponibilidade, SLAs e assim por diante.

Eu digo às pessoas que você obtém 99% de tempo de atividade gratuitamente (ou seja, sem gastar nada extra em alta disponibilidade). São cerca de três dias e meio de inatividade por ano. Cada 9 a mais nesse tempo de atividade aumenta o custo entre três e dez vezes.

Se as pessoas não estão prontas para pagar esse tipo de dinheiro, é um erro enganá-las, pensando que podem obter proteção extra de qualquer significado.

Pequenas empresas com orçamentos pequenos, especialmente organizações sem fins lucrativos, normalmente não terão condições de oferecer alta disponibilidade. A questão é: se você praticamente não tem orçamento, como é o caso em situações como essa, qual é a sua estratégia de restauração?

Eu tenho alguns clientes como este, e é isso que eu faço:

Primeiro, para alguns deles, eu tenho um backup incremental e um dump completo do banco de dados a cada seis horas. Um cliente já estava usando o CrashPlan Pro, então apenas o usei. Faça o que fizer, você precisa ter um backup restaurável.

Eu tenho um manual simples do ansible que reuni em cerca de uma hora (sem ter trabalhado anteriormente com o ansible) que instala o nginx, php-fpm e o MariaDB e os prepara para hospedar um site ou sites. A execução desse manual de instruções resulta em um servidor (ou servidores) pronto para hospedar um aplicativo Web típico, e posso simplesmente restaurar o host virtual nginx, os arquivos do aplicativo e o banco de dados para ele.

O resultado disso é que posso acessar um site desse tipo em apenas alguns minutos, em oposição à maneira manual, que pode levar uma hora ou mais.

A complexidade da implementação depende da pilha de aplicativos, mas, idealmente, você deseja configurar um "hot standby" (em um provedor diferente), com os dados sendo replicados em tempo real (ou o mais próximo possível).

Fazer o argumento comercial de ter 2 servidores "ativos" é tão simples quanto comparar a perda potencial de receita durante um período de "recuperação de imagens" com as despesas de outro servidor.

Lembre-se de que o tempo de atividade não é o mesmo que a integridade dos dados. Você pode ter um tempo de atividade de 99,99% e perdeu todos os seus dados duas vezes em um ano, desde que o servidor tenha sido reiniciado "em breve". A maioria dos provedores de VPS garante que seu servidor esteja em execução, NÃO que seus dados estejam seguros. Seus dados são seu problema :(.

O que você está procurando é algo que armazene seus backups em um servidor separado e (IMHO) nem mesmo no mesmo provedor. Dependendo do tamanho dos dados que você está falando, um disco rígido portátil pode ser usado como uma terceira linha de defesa offline. Faça backup dos dados como você estava fazendo e copie-os regularmente (ou apenas as alterações, se possível) para o disco rígido portátil ou mesmo para um computador local. Também existem opções razoavelmente baratas, como o Backblaze, para soluções de backup, mas o preço dependerá da quantidade de dados de que você está falando. Se você puder fazer backups incrementais, será muito mais barato que os backups completos, mas os backups incrementais podem ser muito difíceis, dependendo de onde os dados estão armazenados (arquivos simples = fácil, banco de dados = não tão fácil).

A resposta depende totalmente da sua arquitetura e requisitos. Algum tempo atrás, três discos falharam em um servidor meu, derrubando mais de 20 vm quando um Raid 6 falhou.

Eu escrevi sobre isso em

https://www.linkedin.com/pulse/20140827173324-2064263-how-i-nearly-lost-my-business-to-3-hard-discs

Mas: como isso é crítico, tivemos backups - diariamente para itens não importantes, 15 minutos para bancos de dados e e-mails. Caramba, agora eu adicionei um servidor que é replicado para outra máquina a cada 30 segundos.

Você não diz nada sobre a pilha, nada sobre qualquer orçamento - portanto, o melhor e único conselho aqui é ir a algum provedor de nuvem e começar a usar seus mecanismos de backup. Mas comece a definir o que você realmente precisa.

Além disso - o orçamento para esse backup deve estar no seu preço. Ele precisa ser pago. E qualquer infraestrutura que você precisar ... você precisa. Não é "ridículo caro" então.