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

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

• Exclusão acidental de dados: os instantâneos cobrem este caso
• Falha de uma unidade e podridão de bits
  • Falha completa: o RAID cobre este caso
  • Unidade retornando dados inválidos: o recurso de correção de erros do RAID + btrfs cobre este caso

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

No entanto, ouvi dizer que o RAID e os snapshots não são considerados backups adequados, por isso estou me perguntando se perdi alguma coisa.

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

Não, não é.

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

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

Para backup no local , o instantâneo pode ser bom o suficiente, desde que você "exporte" regularmente o instantâneo para outro lugar, onde ele exista como dados passivos.

E teste regularmente se o seu 'instantâneo enviado' pode ser restaurado.

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

Obviamente, o melhor backup é sempre externo. Assim, depois de 'enviar' o instantâneo (s) para um sistema separado, faça uma 'fita adesiva' dos instantâneos regularmente.

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

E, é claro, teste suas fitas para garantir que elas possam ser restauradas.

Nota: Você deseja que o instantâneo ocorra durante a atividade do disco inativo, e de preferência em coordenação com o banco de dados (se houver) para garantir consistência; caso contrário, a cura pode ser pior que a doença. É por isso que o recurso 'snapshot ao vivo' da NetApp e EMC é muito útil: eles adiarão o snapshot de um LUN até que o banco de dados usando o LUN indique que é seguro realizar o snapshot.

O que o HopelessN00b disse. Não.

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

(Alerta de anedota: Uma vez ouvi falar de alguém que tinha o PXE configurado para instalar automaticamente o Fedora mais recente. Seu no-break falhou. Após uma queda de energia, seu servidor foi reiniciado e foi definido como inicialização PXE e ... instalou o Fedora sobre seus dados. coisas estranhas 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.

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

1) Snapshots e armazenamento de back-end PODEM falhar. Portanto, os backups reais devem estar usando um conjunto de eixos separado ou há uma grande chance de perder o conjunto de trabalho principal e os dados de backup @ ao mesmo tempo.

2) Instantâneos "mastigam" o espaço utilizável. Faz sentido usar armazenamento caro e rápido para dados atuais quentes e instantâneos e backups descarregados, sendo dados frios para um armazenamento mais barato e mais lento. Funciona muito bem com 1) BTW.

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

Sim. É uma maneira perfeita de armazenar backups. Nada mais é necessário, diabos, mesmo fazer verificações de integridade é apenas perda de tempo.

Só para confirmar - antes de eu dar mais conselhos ... você trabalha para um concorrente meu, certo? Você realmente faz, certo? 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 protege apenas contra alguém que exclua alguns dados. Agradável. Esse é um erro que ocorre com frequência.

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

• Um pico de energia destruindo a máquina. Estive lá, vi isso.
• Algum controlador de ataque defeituoso ou gravação de memória ** ** no disco - lá vai qualquer coisa.

E uma longa lista de outras coisas.

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

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

É por isso que as fitas balançam - elas não estão conectadas e nada curto, como fogo ou inundação, não as machucará. Pico de energia - 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 fora do local (já mencionei coisas como incêndio e inundação?) (Mais uma vez, quando você trabalha para um concorrente - não existe incêndio em prédios, não é totalmente necessário, como é o seguro contra incêndio, por favor, economize esse dinheiro).

Agora, você pode pensar "oh, 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 vodaphone. Tenho certeza de que você entenderá onde está o problema de um backup interno / in-computer:

http://www.youtube.com/watch?v=ttcQy3bCiiU

Lição aprendida de duas unidades RAID-1 com falha dentro de meia hora uma da outra: 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 ajuda em nada, por exemplo, vírus, exclusão / modificação de dados ou falha catastrófica simples de hardware.

Muitos administradores experientes seguem a conhecida regra de backups 3-2-1:

• Você deve ter pelo menos três cópias dos seus dados, incluindo a fonte principal. 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 dos seus dados.

Os instantâneos violam as três partes:

• Você usa apenas uma única máquina física. Qualquer coisa que afete a máquina inteira, como uma falha na fonte de alimentação, pode levar todos os seus dados.

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

• Você não tem backups externos. Inundações e incêndios acontecem apenas a outros, até que aconteçam com você ...

Assim sendo:

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

• Você precisa ter pelo menos um backup que não seja gerado usando instantâneos. Talvez um bom tararquivo incremental antigo esteja em ordem? Ou uma rsynccópia baseada?

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

Também deve ser destacado que os instantâneos no nível do bloco têm praticamente a mesma garantia de consistência que puxar o plugue da sua máquina e depois copiar os discos. Em geral, você precisaria executar fsckuma restauração ou esperar que o diário seja suficiente.

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

Por fim, lembre-se de que agora estamos falando apenas de cópias dos seus dados atuais . Para se proteger contra falhas (ou violações de segurança) que permanecem sem ser detectadas por algum tempo, você também precisa ter várias cópias antigas de seus dados há algum tempo.

Por si só, não é uma solução de backup . Ele irá reduzir ou eliminar o tempo de inatividade em certos cenários de falha, mas não protegê-lo em tudo de muitos outros

Obviamente, pode ser uma parte muito valiosa de uma solução mais arredondada de disponibilidade + backup:

• RAID mais snapshows no mesmo hardware
• Cópias no local em outro hardware (lembre-se: existem modos de falha que eliminariam toda a caixa, controlador, unidades e tudo de uma só vez)
• Cópias remotas semi-desconectadas
• e, é claro, cópias offline e externas adequadas para desastres verdadeiros

Além disso: teste seus backups regularmente. O pior momento para descobrir que seus backups não estão funcionando é quando você precisa recuperar algo deles ...