Os snapshots + RAID contam como uma boa solução de backup no local?

18

As duas principais razões pelas quais eu consigo pensar em fazer backups parecem ser resolvidas quando uso snapshots e RAID junto com o btrfs. (Por RAID aqui, quero dizer RAID1 ou 10)

  • Exclusão acidental de dados: os instantâneos abrangem este caso
  • Falha de uma unidade e apodrecimento
    • Falha completa: o RAID abrange este caso
    • Direcione o retorno de dados incorretos: o recurso de correção de erros do RAID + btrfs abrange esse caso

Então, como uma solução de backup no local, isso parece funcionar bem, e nem precisa de um dispositivo de armazenamento de dados separado para isso!

No entanto, ouvi dizer que tanto o RAID quanto os instantâneos não são considerados backups adequados, então estou pensando se perdi alguma coisa.

Além de o btrfs ainda não ser uma tecnologia madura, você pode pensar em algo que eu perdi? Ou o meu pensamento está correto e esta é uma solução válida de backup no local?

    
por 小太郎 09.03.2014 / 13:07

8 respostas

42

Não, não é.

O que acontece quando o seu sistema de arquivos ou volume RAID é corrompido? Ou o seu servidor é incendiado? Ou alguém acidentalmente formata o array errado?

Você perde todos os seus dados e os backups não reais que você pensou que tinha. É por isso que os backups reais estão em um sistema completamente diferente dos dados que você está fazendo backup - porque os backups protegem contra algo que esteja acontecendo com o sistema em questão e causaria perda de dados. Mantenha seus backups no mesmo sistema que você está fazendo o backup, e a perda de dados nesse sistema pode afetar seus "backups" também.

    
por 09.03.2014 / 13:21
11

Para o backup no site , o instantâneo pode ser bom o suficiente, desde que você exporte regularmente o instantâneo em outro lugar, onde existe como dados passivos.

E, teste regularmente se o "instantâneo enviado" pode ser restaurado.

Foi assim que implementei um backup rápido de alguns dos meus servidores: armazene os dados no ZFS, faça um instantâneo do ZFS, envie o delta para outro servidor, onde todo o sistema de arquivos é recriado (menos o serviço real em execução).

É claro que o melhor backup é sempre fora do site. Assim, depois de enviar os instantâneos para um sistema separado, faça uma 'fita' dos instantâneos regularmente.

Portanto, no meu sistema, o servidor que recebe os deltas de snapshots despeja regularmente todos os pools do ZFS (incluindo snapshots anteriores) em fita.

E, claro, teste suas fitas para garantir que ele possa ser restaurado.

Observação: você desejará que o instantâneo ocorra durante a atividade do disco desativado e, de preferência, em coordenação com o banco de dados (se houver) para garantir a consistência; outra coisa, a cura pode ser pior que a doença. É por isso que a NetApp & O recurso EMC 'live snapshot' é muito útil: eles adiarão o instantâneo de um LUN até que o banco de dados que usa o LUN indique que é seguro executar o instantâneo.

    
por 09.03.2014 / 16:47
8

O que o HopelessN00b disse. Não.

Os backups adequados estão em um dispositivo separado do dispositivo que está sendo submetido a backup. O que acontece quando você perde duas ou mais unidades? O que acontece quando sua sala de servidores é queimada? O que acontece quando alguém acidentalmente destrói sua matriz?

(Alerta de anedota: ouvi falar de alguém que tinha o PXE configurado para instalar automaticamente o Fedora mais recente. Sua UPS falhou. Após uma queda de energia, seu servidor foi reiniciado e configurado para inicialização PXE e ... instalou o Fedora em seu dados. Meu ponto? Coisas esquisitas acontecem. Felizmente, ele tinha backups adequados.)

De preferência, você tem pelo menos três cópias de seus dados, uma armazenada completamente fora do local, caso o data center queime.

    
por 09.03.2014 / 13:31
6

Os snapshots adequadamente implementados DEVEM ser suportados pelo seu armazenamento, pois os backups decentes os utilizam como um primeiro estágio da criação de um trabalho de backup. No entanto, é uma má ideia usar instantâneos para backup principal. Razões:

1) Os instantâneos e o armazenamento de back-end CAN falham. Portanto, os backups reais devem estar usando o conjunto de eixos separado ou há uma grande chance de perder os dados do conjunto de trabalho principal e do backup @ ao mesmo tempo.

2) Instantâneos "mastigam" o espaço utilizável. Não faz sentido usar armazenamento caro e rápido para dados atuais quentes e descarregar instantâneos e backups sendo um dado frio para algum armazenamento mais barato e mais lento. Funciona muito bem com 1) BTW.

3) Os instantâneos geralmente reduzem a velocidade de todo o processo. A maioria dos sistemas usa Copy-on-Write e essa abordagem cria fragmentação. O Redirect-on-Write é mais rápido, mas consome muito espaço. Muito poucos fornecedores implementaram adequadamente os instantâneos. NetApp com WAFL e Nimble Storage com CASL (não me associo a nenhum deles). Praticamente todo mundo tem problemas. Por exemplo, a atualização da Dell Equallogic de 15 MB da página (e desperdício) em cada byte alterado. Isso é caro.

    
por 09.03.2014 / 17:47
6

Sim, é. É uma maneira perfeita de armazenar backups. Nada mais é necessário, até mesmo fazer verificações de integridade é apenas um desperdício de tempo.

Só para confirmar - antes de dar mais conselhos ... você trabalha para um concorrente meu, certo? Você realmente sabe, claro? Não? Oh.

Desculpe, NUTS. Não, não mesmo. Desculpe, cara.

O problema é que você está totalmente aberto a qualquer erro que ocorra no (a) sistema e (b) no nível do sistema operacional. Você basicamente só protege contra alguém excluindo alguns dados. Agradável. Esse é um erro que ocorre frequentemente.

O que você não está protegendo é:

  • Um pico de energia limpando a máquina. Estive lá, visto isso.
  • Algum controlador de ataque defeituoso ou memória escrita sh ** no disco - lá vai qualquer coisa.

E uma longa lista de outras coisas.

Isso é - naturalmente, a menos que você trabalhe para um concorrente meu - você sempre faz um backup:

  • Em outro computador
  • Que você isole de pelo menos picos de energia (mesmo se você tiver um USV).

É por isso que as fitas de rock - elas não estão conectadas e nada menos que um incêndio ou uma inundação não os afetará. Power spike - lá vai o leitor de fita e talvez o robô, mas as fitas que não estão no leitor não serão afetadas.

BEST seria backups offsite (já mencionei coisas como fogo e enchente já?) (Mais uma vez, quando você trabalha para um concorrente - não há fogo de construção, não é totalmente necessário, como é o seguro de incêndio , por favor, salve esse dinheiro).

Agora, você pode pensar "ah, inundações nunca acontecem". Certifique-se de ter certeza. Veja, aqui está um vídeo de uma inundação de 09.09.09 de um datacenter de vodaphone. Tenho certeza de que você entenderá qual é o problema para um backup de computador / insite:

link

    
por 09.03.2014 / 18:04
4

Lição aprendida de duas unidades RAID-1 que falham em meia hora uma da outra: o RAID não é um mecanismo de backup, nem de forma alguma.

O RAID é um mecanismo de disponibilidade que reduz o tempo de inatividade em caso de falha de hardware, mas não o ajudará em caso de, e. Vírus, exclusão / modificação de dados ou falha de hardware catastrófica simples.

    
por 09.03.2014 / 21:26
3

Muitos administradores experientes usam o que é conhecido como a regra 3-2-1 dos backups:

  • Você deve ter pelo menos três cópias de seus dados, incluindo a fonte primária. Ou seja um único backup não é suficiente e as cópias dentro do mesmo sistema físico não contam.

  • Você deve usar pelo menos dois métodos de backup diferentes.

  • Você deve ter pelo menos uma cópia externa de seus dados.

Os instantâneos violam as três partes:

  • Você usa apenas uma única máquina física. Qualquer coisa que afete toda a máquina, como uma falha na PSU, pode levar consigo todos os seus dados.

  • Você está usando apenas um método único para seus backups. Se qualquer coisa estiver errado, você só descobrirá quando restaurar o backup em uma situação de crise.

  • Você não tem backups fora do site. Enchentes e incêndios acontecem apenas para os outros, até que eles aconteçam com você ...

Portanto:

  • Você precisa ter pelo menos um backup em uma máquina separada em sua LAN.

  • Você precisa ter pelo menos um backup não gerado usando instantâneos. Talvez um bom arquivo tar incremental possa estar em ordem? Ou uma cópia baseada em rsync ?

  • Você precisa ter pelo menos um backup remoto, o mais longe possível de sua localização atual e definitivamente não no mesmo prédio.

Também deve ser destacado que os instantâneos no nível de bloco têm as mesmas garantias de consistência que a de conectar o plugue em sua máquina e depois copiar os discos. Em geral, você precisaria executar fsck após uma restauração ou esperar que a publicação seja suficiente.

Os instantâneos no nível do sistema de arquivos devem ser melhores, mas eles ainda não garantiriam a consistência de seus arquivos. Para muitos aplicativos (servidores de banco de dados lembram-se) copiar os arquivos de uma instância ativa pode ser completamente inútil, uma vez que eles podem estar em um estado inconsistente. Você precisaria usar seu próprio mecanismo de backup em nível de aplicativo para garantir a existência de uma cópia limpa - para a qual a regra 3-2-1 também se aplicaria.

Por fim, lembre-se de que, no momento, estamos falando apenas de cópias de seus dados atuais . Para se proteger contra falhas (ou brechas de segurança, por exemplo) que não são detectadas por algum tempo, você também precisa ter várias cópias antigas de seus dados há um bom tempo.

    
por 10.03.2014 / 13:53
2

Por si só, não é uma solução de backup . Isso reduzirá ou removerá o tempo de inatividade em determinados cenários de falha, mas não protege você de todos os outros

Pode, claro, ser uma parte muito valiosa de uma solução mais abrangente de disponibilidade + backup:

  • RAID mais snapshows no mesmo hardware
  • Cópias no local em outro hardware (lembre-se: existem modos de falha que eliminariam a caixa inteira, o controlador, as unidades e tudo de uma vez)
  • Cópias remotas semi-desconectadas
  • e, claro, cópias off-line + off-line adequadas para desastres true

Além disso, certifique-se de testar regularmente seus backups. O pior momento para descobrir que seus backups não estão funcionando é quando você precisa recuperar algo deles ...

    
por 10.03.2014 / 11:05