Você pode querer adicionar uma rotina regular de aptitude-create-state-bundle em seu esquema para recuperação completa do sistema. Veja link .
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:
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?
Você pode querer adicionar uma rotina regular de aptitude-create-state-bundle em seu esquema para recuperação completa do sistema. Veja link .
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