Eu tenho um sistema IDS linux autônomo que venho montando. Ele executa o MySQL localmente, bem como ntop, nagios, base, snort, apache etc. Eu quero ser capaz de fazer um backup do sistema que tem tudo do sistema antigo para que eu possa fazer um dd rápido a partir de uma imagem estática de o sistema e depois restaurá-lo para o último estado.
De acordo com o meu conhecimento, eu não posso DD um sistema ao vivo, o que me deixa com uma perda de como obter tudo do servidor backup.
Eu nunca usei o rsync no passado, e acho que pode ser a solução, mas não tenho certeza se posso usá-lo em um banco de dados mysql ao vivo.
Tenho certeza que isso vai precisar de uma abordagem em camadas, mas qualquer entrada seria útil.
editar:
Os sistemas que estão sendo monitorados são pouco tráfego na maior parte do tempo, e o apache é apenas para as UIs da web para os aplicativos, portanto, não é tão sobrecarregado quanto parece
Para o mysql você pode usar o mysqldump para despejar o conteúdo do banco de dados em um arquivo. Além disso, você normalmente só precisa fazer backup dos arquivos de configuração ( /etc e quaisquer outros diretórios modificados), de quaisquer outros diretórios de dados, arquivos de log e da lista de pacotes instalados. Você deve poder restaurar o sistema fazendo uma nova instalação do SO, instalando os pacotes da lista e substituindo os arquivos de dados e configuração.
Você sabe, eu sou um grande fã de desligar o servidor e usar algo como o Clonezilla ou o Norton Ghost para criar uma imagem desse otário.
Mesmo que as 11 da noite de sexta-feira, uma por mês ... você tenha a ideia.
Algumas horas de "inatividade programada" valem HORAS e HORAS de recuperação de falhas.
Como eu digo à minha assistente, "Eu não estou dizendo isso porque sou esperta. Estou dizendo isso porque, em certo ponto, fui estúpida e aprendi minha lição da maneira mais difícil!"
Obrigado pela sua atualização. Ok, então não há tempo de inatividade para este servidor.
É possível construir um "warm standby" que você pode usar nas 2-3 horas necessárias para clonar o disco?
A desativação da rede é às 3h da manhã de domingo?
Certamente tem que haver ALGUM modo de agendar algum tempo de inatividade?
Estou apenas tentando fornecer uma solução "simples" para você. : -)
Eu vejo duas opções na sua situação:
Você pode usar o rsync em um banco de dados ativo, mas pode corromper os dados. Pare o banco de dados, execute o rsync e inicie-o novamente. Você também pode descarregar o DB e o rsync desse arquivo.
Sou realmente um grande fã de usar dirvish para backups. É basicamente apenas um script em perl que facilita a realização de backups com o rsync.
Para o banco de dados mysql, você realmente precisa usar o utilitário mysqldump ou algo especificamente projetado para essa finalidade. Copiar arquivos de banco de dados com o rsync não é uma boa ideia.
Normalmente, pode-se apenas rsync o conteúdo do sistema de arquivos para outro local e é isso. O backup incremental deve ser bem rápido (alguns minutos? Dependendo da largura de banda disponível para o rsync e com que frequência você faz backup) para que você possa até mesmo reduzir os serviços problemáticos com quase nenhum efeito (notei o "sem tempo de inatividade") exigência).
O ofensor comum para essa prática é o banco de dados MySQL que não manipula bem os snapshots. Você pode resolver esse problema usando a sugestão de Kamil de descarregar para o arquivo SQL e fazer o backup, ou fazer algum tipo de "backup ativo". A vantagem da última abordagem é que o rsync gosta muito mais - criar um novo dump SQL para cada backup tende a fazer com que o rsync copie todo o banco de dados toda vez, o que é um processo demorado para grandes bancos de dados. Usando o "backup quente", você pode aproveitar a capacidade do rsync de copiar apenas as alterações nos dados. A Innobase (criadores do InnoDB) vende um produto comercial para fazer backups a todo o banco de dados. Descobri que, desde que você não tenha muitas gravações de banco de dados, você pode usar LOCK TABLES , rsync os arquivos binários e UNLOCK TABLES . quando você restaura o MySQL acha que você teve um travamento do servidor e recupera bem (você quer executar mysqlcheck após a recuperação).
Outro método para fazer o backup de seu servidor, um pouco como a primeira sugestão de Dave, é fazer backup de um dispositivo de invasão em espera. Esta é uma abordagem muito diferente da minha primeira resposta, então estou colocando em outra resposta.
O que você pode fazer é configurar seu servidor usando o software raid (mdraid) com o espelhamento. Então, quando você quiser tirar um instantâneo, desconecte um dispositivo de ataque ( mdadm /dev/md0 --fail /dev/sdb1 --remove /dev/sdb1 ), dd do conteúdo do dispositivo desconectado do servidor e reconecte-o à raid ( mdadm --re-add /dev/sdb1 ). A sincronização do ataque copiará todos os dados que foram alterados enquanto o dispositivo estava desligado.
Quando você restaura, você pode dd os mesmos dados para ambos os dispositivos RAID (é um espelho mesmo assim). A imagem restaurada ficaria, na pior das hipóteses, como se o servidor tivesse perdido a energia durante uma transação, portanto você deve usar um sistema de arquivos de registro no diário e bancos de dados transacionais de qualquer maneira.
Você provavelmente desejaria usar um sistema de 3 unidades nesse caso, para que seu sistema pudesse lidar com um desastre durante o backup. Nesse caso, você também quer ter um espelho de 3 direções e desconectar o terceiro dispositivo para backup. ou até mesmo montá-lo em uma baia de hot-switch e retirá-lo fisicamente conforme descrito em este tópico (por favor leia o tópico se você quiser fazer desta forma - o autor original tem alguns problemas com os comandos específicos e sua ordem)
estou usando
Blockquote
rsync --delete --times --recursive --perms --owner --group --verbose --progress --stats -e ssh [email protected]: / backup1 / / backup1 /
Blockquote
no segundo servidor nesse servidor eu tenho configuração lvm por isso é muito fácil executar o backup apenas tirar uma foto que você pode seguir link
Dê uma olhada no backupEdge em www.microlite.com
(Pena que eles não tenham uma versão do windows)
A clonagem não é um esquema de backup viável para um sistema de produção.
Procure pelo livro "Unix Backup and Recovery" de Curtis Preston. Fazer backup de um sistema ao vivo é possível com muitos aplicativos comerciais, bem como aplicativos de código aberto, como o Amanda. Haverá uma curva de aprendizado, no entanto.
Normalmente, o aspecto mais desafiador de se apoiar é a recuperação. Comece a planejar a recuperação primeiro. Se você não puder arcar com o sistema para fazer o backup, não será possível restaurá-lo.