"Quem precisa de invasores quando você tem administradores de sistemas? Aprenda por que copiar seus dados não significa que eles estão seguros."
Acabo de perder um mês de dados, acidentalmente apaguei boa parte do diretório /var/ e todo o diretório /home/. Não teria sido tão mal se eu não tivesse feito becapes diários em /home/becape/. Ops.
No meu caso cometi o erro de gardar os becapes no mesmo local onde estavam os dados e para piorar a situação, estavam em um diretório frequentemente acessado. Mas isso era o de menos. O servidor tinha apenas um disco rígido. bastaria uma falha de disco para perder meus dados completamente, não importa quantos becapes tivesse feito. Mesmo com dois discos na máquina, ainda seria fácil um evento qualquer, como um erro na controladora do disco, ataques, incêndios, inundações, curtos-circuitos, furtos, etc ocasionar a perda de mais de um disco.
Fazer é diferente de ter.
Se seus dados não estão disponíveis, assim como os sistemas que os processam e os disponibilizam, você tem um problema. No caso do meu servidor, a perda do /var/ e do /home/ o deixou um tanto quanto inútil. Ele exibia erros 404 e nada mais. Parece simples que precisamos fazer becape, mas antes precisamos entender o conceito de que os dados devem ser copiados para um local invulnerável a perdas, ou então estaremos copiando dados de um local para outro.No meu caso cometi o erro de gardar os becapes no mesmo local onde estavam os dados e para piorar a situação, estavam em um diretório frequentemente acessado. Mas isso era o de menos. O servidor tinha apenas um disco rígido. bastaria uma falha de disco para perder meus dados completamente, não importa quantos becapes tivesse feito. Mesmo com dois discos na máquina, ainda seria fácil um evento qualquer, como um erro na controladora do disco, ataques, incêndios, inundações, curtos-circuitos, furtos, etc ocasionar a perda de mais de um disco.
Becapes legítimos?
Há três elementos principais que devem ser considerados ao fazer becapes:
- Um - tenha certeza de que você fez becape dos dados. Tenho visto muitos sistemas que salvam dados em CDs, DVDs ou fitas de forma inadequada, o que resulta em dados irrecuperáveis. É preciso testar cada becape que se faz, mas se isso não for possível, faça no mínimo checagens ocasionais para ter certeza de que os dados podem ser recuperados.
- Dois - mantenha becapes externos em regime somente leitura, ou o mais próximo possível disso. Isto não significa necessariamente que eles devem estar em um local físico diferente, embora seja sempre uma ótima idéia, mas eles têm de estar separados, pelo menos o suficiente para que uma simples falha ou evento, como a formatação de um disco ou a perda de um servidor, não venha a acabar tanto com os dados quanto com os becapes. Um exemplo foi o site AVSIM Online, que perdeu treze anos de dados em decorrência de um simples ataque. O AVSIM tinha dois servidores que copiavam e faziam becape de seus dados simultaneamente. Neste caso, um invasor acessou os dois servidores, e uma vez que eram basicamente idênticos eliminou todos os dados e as cópias realizadas em ambos servidores. O AVSIM Online perdeu seu site, e-mails, arquivos, fóruns e muito mais, e muito provavelmente nunca obterá os dados de volta. No meu caso, tive sorte perdi apenas um mês de arquivos de log e dados coletados, então tudo o que tive de fazer foi esperar um mês e recolher novos dados - que bom que não eram registros financeiros de alguém.
- Três - tenha certeza de que você não vai apagar os arquivos de becape ou zerar o conteúdo do arquivo a menos que tenha 100% de certeza de que nunca precisará do arquivo novamente. Por esse motivo, RAID não é uma solução de becape. Mesmo se você tiver vários discos rígidos em uma configuração RAID de modo que a perda de uma ou de várias não cause a perda de dados, você ainda pode perdê-los por apagar rm, mkfs, etc ou alterar os arquivos cat foo > bar.
- Um - tenha certeza de que você fez becape dos dados. Tenho visto muitos sistemas que salvam dados em CDs, DVDs ou fitas de forma inadequada, o que resulta em dados irrecuperáveis. É preciso testar cada becape que se faz, mas se isso não for possível, faça no mínimo checagens ocasionais para ter certeza de que os dados podem ser recuperados.
- Dois - mantenha becapes externos em regime somente leitura, ou o mais próximo possível disso. Isto não significa necessariamente que eles devem estar em um local físico diferente, embora seja sempre uma ótima idéia, mas eles têm de estar separados, pelo menos o suficiente para que uma simples falha ou evento, como a formatação de um disco ou a perda de um servidor, não venha a acabar tanto com os dados quanto com os becapes. Um exemplo foi o site AVSIM Online, que perdeu treze anos de dados em decorrência de um simples ataque. O AVSIM tinha dois servidores que copiavam e faziam becape de seus dados simultaneamente. Neste caso, um invasor acessou os dois servidores, e uma vez que eram basicamente idênticos eliminou todos os dados e as cópias realizadas em ambos servidores. O AVSIM Online perdeu seu site, e-mails, arquivos, fóruns e muito mais, e muito provavelmente nunca obterá os dados de volta. No meu caso, tive sorte perdi apenas um mês de arquivos de log e dados coletados, então tudo o que tive de fazer foi esperar um mês e recolher novos dados - que bom que não eram registros financeiros de alguém.
- Três - tenha certeza de que você não vai apagar os arquivos de becape ou zerar o conteúdo do arquivo a menos que tenha 100% de certeza de que nunca precisará do arquivo novamente. Por esse motivo, RAID não é uma solução de becape. Mesmo se você tiver vários discos rígidos em uma configuração RAID de modo que a perda de uma ou de várias não cause a perda de dados, você ainda pode perdê-los por apagar rm, mkfs, etc ou alterar os arquivos cat foo > bar.
Teste dos becapes
Esse é um dos passo mais importante ao fazer becapes. Primeiro é preciso descompactar e restaurar os dados; caso contrário como você pode ter certeza de que funcionarão? Depois disso, você poderá dormir tranquilamente sabendo que catástrofes naturais ou administradores de sistema não estragarão seu dia.
baseado no artigo escrito por: Kurt Seifried
em: Revista Linux Magazine # 57 agosto 2009
baseado no artigo escrito por: Kurt Seifried
em: Revista Linux Magazine # 57 agosto 2009
Nenhum comentário:
Postar um comentário