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

Question

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

Eu tenho alguns servidores Debian Linux VPS e asseguro que eu tenha 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, eles disseram desculpe, o que mais eles poderiam fazer? Mas isso me fez pensar sobre maneiras econômicas de basicamente recuperar um VPS no caso de um hardware ou outra falha relacionada ao host.

Atualmente eu teria que

1. Crie 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 espere que ele se propague.

Provavelmente levaria um dia ou mais para alcançar isso, com a propagação do DNS sendo um grande desconhecido, embora eu tenha o TTL configurado bem baixo (hora ou mais).

Alguns hosts fornecem snapshots que podem ser usados para replicar uma configuração para um novo VPS, mas ainda há o IP e isso não ajuda no caso de a empresa host cancelar / suspender uma conta imediatamente (já estive ler sobre esse comportamento de certos provedores de hospedagem e isso me assusta! Eu não estou fazendo nada de spam / desonesto e fico de olho na segurança, mas percebo que eles literalmente têm o poder de fazer isso e eu sou bastante averso ao risco) .

É isso, combinado com a escolha de hosts confiáveis, o melhor que posso fazer sem precisar de uma solução incrivelmente cara?

    

Answer 1

Para mim, escolher hosts respeitáveis e fazer backups regulares - que você já está fazendo - é o melhor que pode fazer sem começar a pensar em planejamento de continuidade de negócios, configurações de alta disponibilidade, SLAs e assim em.

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

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

    

Answer 2

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

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

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

Eu tenho um playbook ansioso simples que eu coloquei em cerca de uma hora (não tendo trabalhado anteriormente com ansible) que instala nginx, php-fpm e MariaDB e prepara-os para hospedar um site ou sites. Executar este playbook resulta em um servidor (ou servidores) que estão prontos para hospedar um aplicativo da Web típico, e eu posso simplesmente restaurar o host virtual nginx, os arquivos do aplicativo e o banco de dados para ele.

O resultado disso é que posso criar um site desse tipo a partir de backup em apenas alguns minutos, ao contrário do modo manual que pode levar uma hora ou mais.

    

Answer 3

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

Criar um caso de negócios para ter dois servidores "ativos" é tão simples quanto comparar a possível perda de receita durante um período de "recuperação de imagens" com o gasto de outro servidor.

    

Answer 4

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

O que você está procurando é algo que irá armazenar 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 de seus dados como você vem fazendo e, em seguida, copie regularmente (ou apenas as alterações, se possível) para o disco rígido portátil ou até mesmo um computador local. Há também 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 do que backups completos, mas backups incrementais podem ser muito difíceis, dependendo de onde os dados são armazenados (arquivos simples = fácil, banco de dados = não é tão fácil).

    

Answer 5

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

Eu escrevi sobre isso em

link

Mas: porque isso é crítico, nós tivemos backups - diariamente para coisas não importantes, 15 minutos para bancos de dados e e-mails. Poxa, agora 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 - então o melhor e único conselho aqui é ir a algum provedor de nuvem e começar a usar seus mecanismos de backup. Mas comece definindo o que você realmente precisa.

Além disso, o orçamento para este backup deve estar no seu preço. Precisa ser pago. E seja qual for a infra-estrutura que você precisa ... você precisa disso. Não é "ridículo caro" então.