O que você acha da estratégia de backup do Debian? [fechadas]

2

Eu não sou realmente um administrador de sistemas, eu sou principalmente um desenvolvedor com algum conhecimento unix, e porque nós não temos nenhum administrador de sistema competente, eu tenho delegado a tarefa de implementar a estratégia de backup.

Temos muitos servidores web, alguns estão executando o Mysql Srevers, outro apache, outro está executando o nginx e estamos usando o SVN como um sistema de versionamento.

Estávamos ansiosos para implementar uma estratégia de backup e para restaurar automaticamente um servidor.

Temos duas possibilidades:

  1. RSYNC todo o DISCO todos os dias
  2. Analise nossa configuração e normalize cada etapa da instalação, faça backup somente dessas informações e use a replicação do MySQL e o SVN para restaurar dados e faça rsync para fazer backup apenas das opções de configuração e da lista de pacotes

Para nosso ponto de vista, o primeiro método tem a vantagem de ser muito simples de implementar e tem a desvantagem de usar muitos recursos do servidor (CPU / RAM / largura de banda)

Como não queríamos ver nossos servidores atrasados devido a um script de backup em execução, decidimos ir mais fundo com (2).

Depois de alguma reflexão, tive a ideia de que cada um dos nossos servidores pode ser dividido em 5 partes

1 - Dados do servidor da web

O SVN pode lidar com todos os nossos arquivos php / css / js / html, só precisamos ter um arquivo de configuração que armazene informações sobre pastas e repositórios. Por exemplo: no arquivo /etc/backup/svn_folders.list, eu teria

FOLDERNAME1    SVN Repository Address1
FOLDERNAME2    SVN Repository Address2
etc...

Em caso de falha, basta analisar esse arquivo e fazer check-out do SVN.

2 - backup de dados MySQL com replicação

Nós temos 3 servidores mysql principais, eu implementei em um servidor de backup mysql_multi, com 3 instâncias do mysql runnning ao mesmo tempo, sendo cada uma das salvas dos servidores principais. Então, todo dia, eu

Stop slaves
mysqldump
start slave

Dessa forma, tenho certeza de que nossos principais servidores MySQL não são afetados pelo processo de backup. Então, para os servidores principais, eu só preciso estocar essas informações em um arquivo conf /etc/backup/mysql.info     serverID = ID

Para recuperar o banco de dados, terei que obter esse serverID do arquivo conf e, em seguida, rsync a imagem de despejo correspondente do servidor de backup para o servidor restaurado.

3 - Lista de pacotes

Com o debian, é fácil saber a lista completa de pacotes instalada no sistema. Um cron apenas armazenará esta lista em     /etc/backup/package.list

4 - Aplicativos personalizados

Em algum momento, precisamos instalar pacotes manualmente (perl, compilação, etc ...) Eu estava pensando em criar uma pasta / etc / backup / manual / contendo todo o script de instalação automatizada, em seguida, na restauração, executando cada script nesta pasta deve fazer o truque

5 - Arquivos de configuração

Um arquivo /etc/backup/conf_data.list com uma lista de todos os diretórios de configuração (Ex: / etc), pode ser analisado por meio de um cronjob e, em seguida, rsynced no servidor de backup.

Na restauração, precisamos primeiro restaurar o /etc/apt/sources.list, fazendo o passo - e 4, e então rsync os arquivos de configuração salvos de volta ao servidor.

Por favor, deixe-me saber o que você pensa sobre esse conceito. Você já implementou algo assim? Você se deparou com problemas?

    
por Ant 02.03.2012 / 04:27

2 respostas

1

Você pode querer adicionar uma rotina regular de aptitude-create-state-bundle em seu esquema para recuperação completa do sistema. Veja link .

    
por 14.03.2012 / 11:27
1

Acho que você criou um plano decente, mas há 2 erros acima. O rSync só faz o backup das alterações, não do disco inteiro, e o rsync deve obter os arquivos de configuração se eles mudarem, independentemente de você ter configurado corretamente.

Minha opinião é que você precisa começar com uma avaliação sólida do que perder esses dados custaria e decidir se vale a pena aumentar a perda com base no seu conhecimento. Se o custo for maior do que a sua zona de conforto, você precisa obter alguma consultoria ou contratar outra empresa para implementar uma estratégia sólida. Sem ofensa, mas se houver um risco significativo, você não quer ficar segurando a bolsa quando as rodas saírem do vagão. Eu tenho visto pessoas perderem seus empregos por causa de coisas assim. Eles querem ir além, mas quando algo não dá certo, eles estão bem acima de suas cabeças. Às vezes você só precisa saber quando desistir. Você ainda pode ter entrada, mas não assumir a culpa se falhar.

Apenas ny .02

    
por 02.03.2012 / 04:48