Estratégia de backup para servidor de pilha LEMP dedicado

Question

Atualmente, temos um aplicativo em execução em um servidor dedicado que utiliza uma pilha LEMP (Linux, Nginx, MariaDB, PHP). No momento, estamos apenas fazendo backups em um intervalo definido (a cada x horas). Eu tenho pesquisado como deveríamos ter um backup ao vivo e estava curioso sobre o que outras pessoas estavam fazendo?

Atualmente, nossa idéia é ter outro servidor em uma localização geográfica diferente que tenha mariadb instalado e, em seguida, sincronizar os bancos de dados, criando uma cópia somente leitura ao vivo de nosso banco de dados de produção neste servidor de backup. Para arquivos enviados por usuários, configuraríamos o rsync para sincronizar com o servidor de backup quando forem feitas alterações no diretório de uploads no servidor de produção. Isso soa como um plano sólido?

Além disso, o pensamento passou pela nossa cabeça de que, se vamos pagar por um servidor dedicado adicional, devemos executar o aplicativo de ambos os servidores, configurando o DNS para round robin entre os dois. Isso não apenas nos forneceria um backup, mas também nos forneceria tolerância a falhas no caso de um dos servidores ficar inativo.

Estamos no caminho certo ou perdemos algum elemento vital?

    

Answer 1

Você está lidando com redundância. Isso é bom. Você pode fazer o failover para o servidor de backup em uma emergência. Esta é uma solução NÃO É UM BACKUP . Você quer que seus backups, especialmente para um aplicativo da web, voltem no tempo.

Se um desenvolvedor acessar e executar DROP TABLE myApp_users , essa alteração será propagada para o servidor de backup somente leitura e você não terá como recuperá-lo. É necessário recuperar um tempo razoável.

Se alguém encontrar uma maneira de atualizar seu logotipo ou um arquivo enviado pelo usuário no servidor principal, a alteração será propagada para o servidor de backup por meio do rsync.

Você precisa despejar o banco de dados em intervalos e copiar os arquivos em algum lugar em intervalos e manter x quantidade de tempo de dados para chamá-lo de um backup .

    

Answer 2

Essa estratégia de backup parece boa. Provavelmente existem maneiras de melhorar, mas isso vai melhorar sua situação atual. Você ainda precisa de backups, para mitigar a corrupção do banco de dados, ataques, etc.

O round robin com DNS básico provavelmente não é a melhor ideia. Alguns clientes sempre usarão o primeiro registro, alguns não serão reprovados. Usando algo um pouco mais inteligente como AWS Route53 ou CloudFlare que pode fazer verificações de integridade e cortar o tráfego para um servidor que não responde funcionaria melhor.