Os Snapshots da NetApp podem ser usados ​​como backups?

Nossa loja depende muito dos Snapshots de volume da NetApp para backups. Usamos backups de fita tradicionais baseados em agentes para alguns de nossos dados, mas geralmente dependemos dos Snapshots para a maioria de nossos sistemas. Além disso, não temos uma política rigorosa de controle de alterações ou nenhum gerenciamento centralizado de configurações, portanto, todosdos nossos servidores, independentemente do backup dos dados fornecidos por seus serviços, precisaria ser reconstruído a partir do bare-metal (e sem nenhuma documentação real). Naturalmente, isso torna os snapshots uma proposta muito atraente para o gerenciamento, pois podemos recuperar todo o servidor, incluindo os dados do usuário e a configuração. Usamos o Virtual Storage Console da NetApp para fazer instantâneos de nossos datastores VMware baseados em NFS e o SnapDrive da NetApp para LUNs (físicas) mapeadas por dispositivo bruto que são apresentadas diretamente aos convidados. Nós capturamos instantâneos críticos fora do local para outro arquivador. Naturalmente, testamos regularmente nosso processo de restauração.

Não posso deixar de me sentir desconfortável com a dependência de snapshots em backups. Para mim, para que uma tecnologia seja considerada suficiente como estratégia de backup, ela precisa atender aos seguintes critérios:

• O backup precisa ser atômico. Ou seja, o backup não pode contar com 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 local)

Entendo que os Snapshots da NetApp funcionam sob uma metodologia Redirect-On-Write (RoW). O layout do arquivo WAFL usa um conjunto de ponteiros (metadados?) Que realmente fazem referência a cada bloco de armazenamento onde quer que esteja. Para fazer uma captura instantânea, o sistema apenas pega uma cópia dos metadados de um volume e a armazena no espaço reservado desse volume. Quaisquer gravações (criações / alterações / exclusões) são redirecionadas para novos blocos. Esse deveria ser o molho especial que torna o WAFL da NetApp tão bom, porque você não precisa ler e gravar os dados antigos no espaço reservado e, em seguida, gravar seus novos dados nos antigos, como os instantâneos Copy-On-Write.

Admito plenamente que posso não entender exatamente como o NetApp Volume Snapshots funciona, mas se meu entendimento for mais ou menos correto, os Snapshots do NetApp falharão em atender aos meus critérios para 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 lá, os metadados serão inúteis.
• A captura instantânea não é separada do sistema. Se alguém excluir o volume errado, perco o instantâneo. Se o NetApp Filer explodir em pequenos gatinhos, perco o backup. Posso usar o SnapMirror para mover meus snapshots para outro arquivador, mas, novamente, ele está apenas movendo os metadados e não os blocos reais. Se eu perder o volume original, não consigo ver como uma captura instantânea copiada para outro Filer ajudará.

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

Os backups servem para duas funções.

• Em primeiro lugar, eles estão lá para permitir que você recupere seus dados, se ficarem 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 desaparecerão.
• Em segundo lugar, e muito mais comumente, os backups são usados ​​para corrigir coisas rotineiras, como exclusões acidentais. Nesse caso de uso, as capturas instantâneas são backups. Eles são indiscutivelmente uma das melhores maneiras de fornecer esse tipo de recuperação, porque disponibilizam as versões anteriores dos dados diretamente para os usuários ou seus SOs como um diretório oculto .snapshot do qual eles podem ler diretamente seus arquivos.

Nenhuma política de retenção

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

Em um volume Netapp com capturas instantâneas, os dados excluídos contidos em uma captura instantânea ocupam espaço de "reserva de snap". Se o volume não estiver cheio e você o tiver configurado dessa maneira, também poderá enviar além dessa reserva de instantâneo e ter instantâneos que ocupam parte do espaço de dados não utilizado. No entanto, se o volume aumentar, todos os instantâneos, exceto os suportados pelos dados no espaço reservado, serão excluídos. A exclusão de capturas instantâneas é determinada apenas pelo espaço disponível e, se precisar excluir capturas instantâneas necessárias para sua política de retenção, será necessário.

Considere esta situação:

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

Nesse momento, sua reserva de instantâneo é completamente usada, assim como o espaço livre de dados que você permitiu que o OnTap use para instantâneos, mas você ainda não perdeu nenhum instantâneo. 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 ao tempo imediatamente após a grande exclusão.

Sumário

Os instantâneos da Netapp não protegem você contra a perda real de dados. Um volume excluído incorreto 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 fazem restaurações de rotina simples e indolores, mas quando não estão disponíveis, você fica exposto.

Eles são um backup, sim. Eu pessoalmente os usei no lugar de incrementos diários antes, mas ainda realizávamos semanalmente as fitas.

Eles protegem muito bem contra erros ou problemas de usuários ou administradores que não sejam da netapp (sistemas acessando volumes).

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

O principal problema, é claro, é que, se alguém gerenciando o netapp exclui o volume, todos os instantâneos acompanham. O SnapMirror para outro arquivador deve proteger adequadamente contra isso.

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

Você obterá melhores backups 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 à medida que a captura instantânea é obtida. Se uma determinada VM e seus dados estiverem contidos inteiramente em um único volume NetApp, o instantâneo dessa VM deverá ser consistente com falhas. Ou seja, deve ser tão bom quanto se você ligasse o servidor e gravasse uma imagem da unidade, o que normalmente significaria verificações do sistema de arquivos e equivalentes do banco de dados. Se os dados de um banco de dados são divididos entre LUNs, parece haver um risco significativo de corrupção de dados.

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

[1] http://www.netapp.com/us/system/pdf-reader.aspx?m=snapmirror.pdf&cc=us

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

Os instantâneos não reconhecem o aplicativo

Só porque você tira um instantâneo do volume de armazenamento subjacente não significa que os dados nesse volume são recuperáveis. O MS SQL é um ótimo exemplo disso - você precisa garantir que seu banco de dados seja consistente com as transações antes de capturar instantaneamente o armazenamento que está usando, caso contrário, como @freiheit mencionou, não há nada melhor do que se recuperar de uma falha grave. Os DBAs adoram usar LUNs diferentes para diferentes partes do SQL para melhor utilizar o sistema de armazenamento, bancos de dados temporários no armazenamento rápido, bancos de dados do sistema no armazenamento mais lento, dados somente leitura ou arquivados no armazenamento em massa e dados de trabalho em algum lugar. Se você estiver apenas capturando instantaneamente esses volumes, é altamente improvável que você possa recuperar seu banco de dados.

A NetApp fornece várias ferramentas do Snap para conscientizar o aplicativo de instantâneos. O SnapManager for SQL fornece esse reconhecimento. No ecossistema da Microsoft, acredito que também haja ferramentas do SnapManager para Exchange e SharePoint. O SnapDrive não tem 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 capturando instantaneamente esses LUNs, 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ê estiver apresentando armazenamento para seus servidores de maneiras diferentes, isso pode complicar sua imagem de instantâneo e recuperação. O ONTAP da NetApp é uma oferta de 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: \ em um armazenamento de dados baseado em NFS e suas unidades de "armazenamento" em LUNs mapeadas por dispositivo bruto. Estávamos tirando instantâneos dos LUNs do RDM, mas não dos datastores baseados em NFS. Isso dificultou a recuperação do servidor .

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

Novamente, o @Basil realmente cobre isso bem, mas vale a pena reiterar. É possível preencher seu Snap Reserve de maneira que o Snpashot Autodelete remova instantâneos que não foram envelhecidos naturalmente para exclusão. Novamente. Isso pode ser muito ruim se você ou seus clientes esperam que três semanas de snapshots estejam disponíveis.

Instantâneos estão em linha

Essa é 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 ativado desaparecer, o backup também ocorrerá. Você pode atenuar isso copiando os instantâneos para outro Filer usando o SnapMirror, como afirmei erroneamente na minha pergunta que a cópia do SnapMirror não é uma cópia completa.

Os instantâneos permitem que más práticas operacionais continuem

Uma coisa que notei é que os instantâneos permitem que gerentes e clientes continuem com um péssimo comportamento operacional. Em nosso ambiente, temos práticas muito ruins de gerenciamento de documentação e configuração. Isso significa que a maioria dos servidores começa com a mesma base (um modelo ou uma imagem), mas é configurada 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 então vêm instantâneos! Não precisamos dar um passo atrás e abordar algumas de nossas práticas operacionais fundamentais porque podemos apenas capturar instantaneamente 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 essa é a lição errada a aprender aqui. Uma lição melhor a aprender é que a estrutura de gerenciamento de configuração, mesmo que seja tão simples quanto um registro de alterações, deve ser copiada para fins de restauração bare-metal. Os snapshots são uma ferramenta fantástica, mas eu posso sentir a tentação de depender excessivamente deles para deter os fundamentos importantes.