Os snapshots da NetApp podem ser usados como backups?

Question

Nossa loja depende muito dos snapshots de volume do NetApp para backups. Usamos backups em fita baseados em agentes tradicionais para alguns dos nossos dados, mas em geral confiamos nos instantâneos para a maioria dos nossos sistemas. Além disso, não temos uma política rigorosa de controle de alterações ou qualquer gerenciamento de configuração centralizado para que todos nossos servidores, independentemente de serem submetidos a backup dos dados fornecidos por seus serviços, precisem ser reconstruídos a partir do zero ( e sem qualquer documentação real). Naturalmente, isso torna os snapshots uma proposta muito atraente para o gerenciamento, pois podemos recuperar todo o servidor, os dados do usuário e a configuração incluída. Usamos o Virtual Storage Console da NetApp para criar instantâneos de nossos datastores VMware baseados em NFS e o SnapDrive da NetApp para LUNs mapeados em dispositivos brutos (físicos) que são apresentados diretamente aos convidados. Nós capturamos instantâneos críticos do SnapMirror para outro arquivador. Naturalmente, testamos regularmente nosso processo de restauração.

Não posso deixar de sentir-me desconfortável com a nossa confiança nos instantâneos dos backups. Para mim, para uma tecnologia considerada suficiente como uma estratégia de backup, ela precisa atender aos seguintes critérios:

• O backup precisa ser atômico. Ou seja, o backup não pode confiar em mais nada para sua recuperação.
• O backup precisa ser separado do sistema do qual é um backup (fora da banda).
• O backup precisa ser copiado ou transportado para o site remoto (fora do site)

EntendoqueossnapshotsdaNetAppfuncionamcomumametodologiaRedirect-On-Write(RoW).Olayoutdearquivo WAFL usa um conjunto de ponteiros (metadados?) Que realmente fazem referência a cada bloco de armazenamento onde quer que seja. Para fazer um instantâneo, o sistema apenas obtém uma cópia dos metadados de um volume e os armazena no espaço reservado desse volume. Quaisquer gravações (criações / alterações / exclusões) são redirecionadas para novos blocos. Este é suposto ser o molho especial que torna o WAFL da NetApp tão bom porque você não tem que ler e depois gravar os dados antigos no espaço reservado e, em seguida, gravar seus novos dados nos antigos snapshots Copy-On-Write.

Eu admito que talvez eu não entenda exatamente como os instantâneos de volume do NetApp funcionam, mas se meu entendimento for mais ou menos correto, os snapshots do NetApp não atenderão aos meus critérios de backups.

• Eles não são atômicos. O "instantâneo" é realmente apenas um conjunto de ponteiros para os dados originais. Se os dados originais não estiverem mais presentes, os metadados serão inúteis.
• O instantâneo não é separado do sistema. Se alguém excluir o volume errado, perco o instantâneo. Se o NetApp Filer explodir em pequenos gatinhos, perco o backup. Eu posso usar o SnapMirror para mover meus instantâneos para outro arquivador, mas novamente, é apenas mover os metadados não os blocos reais. Se eu perder o volume original, não consigo ver como um instantâneo copiado para outro arquivador vai ajudar.

Alguém pode explicar como os snapshots do NetApp podem ser considerados backups? Estou procurando respostas Boa Subjetiva então, por favor, apoiem sua posição com fatos, referências e experiência. Se meu entendimento da tecnologia subjacente estiver incorreto, explique por que e por que isso muda minha conclusão. Se sua loja se basear nos snapshots da NetApp como backups, inclua informações contextuais suficientes para que as pessoas possam ter uma ideia do tipo de política de recuperação que você deve cumprir.

    

Answer 1

Os backups servem duas funções.

• Antes de mais nada, eles estão lá para permitir que você recupere seus dados se eles se tornarem indisponíveis. Nesse sentido, os instantâneos não são backups. Se você perder dados no arquivador (exclusão de volume, corrupção de armazenamento, erro de firmware, etc.), todos os instantâneos para esses dados também serão removidos.
• Em segundo lugar, e muito mais comumente, os backups são usados para corrigir problemas de rotina, como exclusões acidentais. Neste caso de uso, os instantâneos são backups. Eles são indiscutivelmente uma das melhores maneiras de fornecer esse tipo de recuperação, porque eles disponibilizam as versões anteriores dos dados diretamente para os usuários ou seus sistemas operacionais como um diretório oculto .snapshot de onde podem ler diretamente seus arquivos.

Sem política de retenção

Dito isto, embora tenhamos instantâneos e os utilizemos extensivamente, ainda fazemos incrementos noturnos no Netbackup para fita ou domínio de dados. O motivo é que os snapshots não podem manter uma política de retenção de maneira confiável. Se você informar aos usuários que eles poderão fazer o backup de uma granularidade diária durante uma semana e depois uma granularidade semanal durante um mês, não será possível cumprir essa promessa com os instantâneos.

Em um volume Netapp com instantâneos, os dados excluídos contidos em um instantâneo ocupam o espaço "reserva de snap". Se o volume não estiver cheio e você o tiver configurado dessa maneira, também poderá passar por essa reserva de snapshot e ter snapshots que ocupam parte do espaço de dados não utilizado. No entanto, se o volume for preenchido, todos os instantâneos, exceto aqueles com suporte de dados no espaço reservado, serão excluídos. A exclusão de instantâneos é determinada somente pelo espaço de instantâneo disponível e, se precisar excluir os instantâneos necessários para sua política de retenção, ocorrerá.

Considere esta situação:

• Um volume completo com instantâneos regulares e um requisito de retenção de duas semanas.
• Suponha metade da reserva em uso para instantâneos com base na taxa normal de alteração.
• Alguém exclui muitos dados (mais do que a reserva de instantâneos), aumentando drasticamente a taxa de alteração, temporariamente.

Neste ponto, a reserva de snapshots é completamente usada, assim como o espaço livre de dados que você permitiu que o OnTap use para snapshots, mas ainda não perdeu nenhum snapshot. No entanto, assim que alguém preencher o volume com dados, você perderá todos os instantâneos contidos na seção de dados, o que levará seu ponto de recuperação de volta ao tempo imediatamente após a exclusão grande.

Resumo

Os instantâneos do Netapp não cobrem a perda real de dados. Um volume excluído errante ou perda de dados no arquivador exigirá que você reconstrua os dados.

Eles são uma maneira muito simples e elegante de permitir restaurações de rotina simples, mas não são confiáveis o suficiente para substituir uma solução de backup real. Na maioria das vezes, eles tornam as restaurações de rotina simples e indolores, mas quando não estão disponíveis, você fica exposto.

    

Answer 2

Eles são um backup, sim. Eu pessoalmente os usei no lugar dos incrementais diários antes, mas ainda fizemos testes completos semanais para gravar.

Eles protegem muito bem de quaisquer erros ou problemas que não sejam do netapp (sistemas que acessam volumes), de usuários ou administradores.

Eles não protegem contra falhas de hardware catastróficas do próprio aplicativo de rede. Meu entendimento é que o SnapMirror copia todos os dados (no instantâneo) para o outro arquivador [1], então o SnapMirroring para outro arquivador deve proteger esse conjunto de dados da falha catastrófica de um único arquivador.

O maior problema, é claro, é que, se alguém gerenciando o netapp excluir o volume, todos os instantâneos vão com ele. O SnapMirror para outro arquivador deve proteger adequadamente contra isso.

Se todos os arquivadores NetApp estiverem no mesmo datacenter, você não terá nada que cubra um grande desastre, da mesma forma que os backups em fita enviados para fora do local fornecerão a você.

Você obterá backups melhores de suas VMs e de quaisquer bancos de dados (ou coisas semelhantes a bancos de dados), se usar o agente SnapManager apropriado, que coordenará a desativação dos dados brevemente conforme o instantâneo for tirado. Se uma determinada VM e seus dados estiverem contidos inteiramente em um único volume NetApp, a captura instantânea dessa VM deverá ser consistente com a falha. Ou seja, deve ser tão bom quanto se você tivesse puxado o plugue de um servidor e imaginado a unidade, o que normalmente significaria verificações do sistema de arquivos e os equivalentes do banco de dados. Se os dados de um banco de dados forem divididos entre LUNs, parece que há um risco significativo de corrupção de dados.

Se fosse eu, configuraria todos os bancos de dados para fazer backups regulares no disco local e definir esses trabalhos para manter uma cópia ou duas. Isso lhe dá uma garantia muito melhor de recuperação.

[1] link

    

Answer 3

Você deve ler a resposta excelente do @Basil agora, mas aqui estão meus dois centavos:

Os instantâneos não são compatíveis com aplicativos

O fato de você tirar um instantâneo do volume de armazenamento subjacente não significa que os dados nesse volume sejam recuperáveis. O MS SQL é um ótimo exemplo disso - você precisa ter certeza de que seu banco de dados é consistente com transações antes de fazer um snapshot do armazenamento que ele está usando de outra forma como O @freiheit mencionou que você não está melhor do que se recuperando de uma falha difícil. Os DBAs adoram usar diferentes LUNs para diferentes partes do SQL para utilizar melhor o sistema de armazenamento, bancos de dados temporários em armazenamento rápido, bancos de dados do sistema em armazenamento mais lento, dados somente leitura ou arquivados em armazenamento em massa e dados de trabalho intermediários. Se você está apenas fotografando esses volumes, é altamente improvável que você recupere seu banco de dados.

A NetApp fornece várias ferramentas Snap para tornar o reconhecimento de snapshots. O SnapManager for SQL fornece essa percepção. No ecossistema da Microsoft, acredito que também existam ferramentas do SnapManager para o Exchange e o SharePoint. O SnapDrive não possui esse reconhecimento de aplicativo. Ele apenas fornece um método conveniente para gerenciar o armazenamento dentro do convidado.

Se você estiver armazenando todos os dados e configurações do IIS em LUNs e fazendo instantâneos desses LUNs diretamente, não poderá garantir que os dados sejam recuperáveis. Pergunte-me como eu sei ...

Vários tipos de armazenamento podem ter agendas de instantâneos diferentes

Se você está apresentando armazenamento para seus servidores de maneiras diferentes, isso pode complicar sua imagem instantânea e de recuperação. O ONTAP da NetApp é uma oferta multiprotocolo e é muito possível que você esteja usando mais de um método ou tipo de armazenamento para um servidor específico. Em nossa loja, alguns de nossos servidores obtêm sua unidade C: \ sobre um armazenamento de dados baseado em NFS e suas unidades de "armazenamento" em LUNs Mapeadas de Dispositivos Brutos. Estávamos tirando instantâneos dos LUNs RDM, mas não dos datastores baseados em NFS. Isso tornou a recuperação do servidor, difícil.

Os instantâneos não têm uma política de retenção garantida

Mais uma vez, @Basil realmente cobre isso, mas vale a pena reiterar. É possível preencher sua reserva instantânea de maneira que o Snpashot Autodelete remova instantâneos que não tenham sido eliminados naturalmente. Novamente. Isso pode ser muito ruim se você ou seus clientes estiverem esperando que três semanas de instantâneos estejam disponíveis.

Os instantâneos estão em linha

Esta é a desvantagem do armazenamento integrado ... está bem ... integrado. Seus instantâneos residem na mesma plataforma que você está fazendo backup. Se o volume ou o Filer estiver desaparecido, o seu backup também desaparece. Você pode atenuar isso copiando os instantâneos para outro arquivador usando o SnapMirror, conforme afirmei erroneamente na minha pergunta que a cópia do SnapMirror não é uma cópia completa.

Os instantâneos permitem que práticas operacionais ruins continuem

Uma coisa que notei é que os snapshots permitem que gerentes e clientes continuem com um comportamento terrível de operações. Em nosso ambiente, temos práticas de gerenciamento de documentação e configuração muito ruins. Isso significa que a maioria dos servidores começa com a mesma base (um modelo ou uma imagem), mas são configurados manualmente por diferentes grupos de pessoas. À medida que continuam sua vida, os servidores divergem cada vez mais do modelo de maneiras que geralmente não são documentadas ou implementadas com o gerenciamento de configuração.

E depois vêm os instantâneos! Nós não precisamos dar um passo atrás e abordar algumas das nossas práticas operacionais fundamentais, porque podemos apenas capturar todos os nossos servidores! E podemos usar o SnapMirror para mover esses instantâneos para fora do local, para que possamos usá-los como backups!

Eu acho que esta é a lição errada para aprender aqui. Uma melhor lição a aprender é que a estrutura de gerenciamento de configuração, mesmo que seja tão simples quanto um changelog, deve ser submetida a backup para fins de restauração bare-metal. Os instantâneos são uma ferramenta fantástica, mas posso ter a tentação de depender excessivamente deles para a dissuasão de fundamentos importantes.