Uma pergunta comumente feita sobre o uso de snapshots como estratégia de proteção de dados é o fato de que os dados "reais" e os dados instantâneos estão localizados nas mesmas unidades. A perda dessas unidades resultaria na perda dos dados primários e do backup.

Este é um problema válido. Os snapshots locais são usados para necessidades diárias de backup e recuperação e, nesse aspeto, o snapshot é um backup. Cerca de 99% de todos os cenários de recuperação em ambientes NetApp dependem de snapshots para atender até aos requisitos mais agressivos de rto.

No entanto, os snapshots locais nunca devem ser a única estratégia de backup. É por isso que a NetApp oferece tecnologia como replicação SnapMirror e SnapVault para replicar snapshots para um conjunto independente de unidades com rapidez e eficiência. Em uma solução de arquitetura adequada com snapshots e replicação de snapshot, o uso da fita pode ser minimizado para talvez um arquivamento trimestral ou eliminado totalmente.

Há muitas opções para o uso de cópias ONTAP Snapshot para proteger seus dados. Além disso, os snapshots são a base de muitos outros recursos da ONTAP, incluindo replicação, recuperação de desastres e clonagem. Uma descrição completa da tecnologia de instantâneos está além do escopo deste documento, mas as seções a seguir fornecem uma visão geral.

Existem duas abordagens principais para criar um instantâneo de um conjunto de dados:

Um backup consistente com falhas de um conjunto de dados refere-se à captura de toda a estrutura do conjunto de dados em um único ponto no tempo. Se o conjunto de dados for armazenado em um único volume, o processo será simples. É possível criar um Snapshot a qualquer momento. Se um conjunto de dados abranger volumes, é necessário criar um instantâneo de grupo de consistência (CG). Existem várias opções para criar snapshots CG, incluindo o software NetApp SnapCenter, recursos nativos do grupo de consistência do ONTAP e scripts mantidos pelo usuário.

Backups consistentes com falhas são usados principalmente quando a recuperação do ponto de backup é suficiente. Quando uma recuperação mais granular é necessária, backups consistentes com aplicações geralmente são necessários.

A palavra "consistente" em "consistente com aplicativos" é muitas vezes um erro. Por exemplo, colocar um banco de dados Oracle no modo de backup é referido como um backup consistente com aplicativos, mas os dados não são consistentes ou silenciosos de forma alguma. Os dados continuam a mudar durante todo o backup. Em contraste, a maioria dos backups MySQL e Microsoft SQL Server realmente silenciam os dados antes de executar o backup. A VMware pode ou não tornar certos arquivos consistentes.

O termo "grupo de consistência" refere-se à capacidade de um storage array gerenciar vários recursos de armazenamento como uma única imagem. Por exemplo, um banco de dados pode consistir em 10 LUNs. O array deve ser capaz de fazer backup, restaurar e replicar esses 10 LUNs de maneira consistente. A restauração não é possível se as imagens dos LUNs não forem consistentes no ponto de backup. A replicação desses 10 LUNs requer que todas as réplicas sejam perfeitamente sincronizadas umas com as outras.

ONTAP sempre foi capaz de capturar imagens locais e replicadas consistentes dos dados. Embora os vários volumes em um sistema ONTAP AFF/FAS geralmente não sejam formalmente descritos como um grupo de consistência, é isso que eles são. Um snapshot desse volume é uma imagem de grupo de consistência, a restauração desse snapshot é uma restauração de grupo de consistência, e tanto SnapMirror quanto SnapVault oferecem replicação de grupo de consistência.

Os sistemas AFF também incluem um tipo mais amplo de grupo de consistência. Vários volumes podem ser definidos como um CG dentro do ONTAP. Snapshots, clones e replicação podem então ser configurados no nível do CG. Isso simplifica as estratégias de proteção de dados porque permite que as políticas sejam definidas em conjuntos de dados, não apenas em volumes ou LUNs individuais. Os CGs também existem em sistemas ASA. Vários LUNs ou namespaces podem ser agrupados como um CG e esse CG pode então ser protegido com snapshots, replicado, restaurado ou clonado.

Os snapshots de grupo de consistência (CG) são uma extensão da tecnologia Snapshot do ONTAP. Uma operação de snapshot padrão cria uma imagem consistente de todos os dados em um único volume AFF/FAS ou ASA LUN/namespace, mas às vezes é necessário criar um conjunto consistente de snapshots em vários recursos de storage e até mesmo em vários sistemas de storage. O resultado é um conjunto de snapshots que pode ser usado da mesma forma que um snapshot de apenas um volume individual. Eles podem ser usados para recuperação local de dados, replicados para fins de recuperação de desastres ou clonados como uma única unidade consistente.

Os snapshots do CG são extremamente escaláveis. O maior uso conhecido de um snapshot do CG é para um ambiente de banco de dados de aproximadamente 1PB, abrangendo 12 controladores. Os snapshots do CG criados nesse sistema foram usados para backup, recuperação e clonagem.

Na maioria das vezes, quando um conjunto de dados abrange volumes AFF ou LUNs/namespaces ASA e a ordem de gravação precisa ser preservada, um grupo de consistência ONTAP pode ser simplesmente definido e o grupo de volumes, LUNs ou namespaces pode ser gerenciado nativamente para criar snapshots. Se software de gerenciamento for utilizado, ele deverá detectar a necessidade de snapshots do grupo de consistência e chamar as APIs necessárias.

Não é necessário compreender os detalhes técnicos do snapshot CG nesses casos. No entanto, existem situações em que requisitos complexos de proteção de dados exigem um controle detalhado sobre o processo de proteção e replicação de dados. Fluxos de trabalho automatizados ou o uso de scripts personalizados para chamar as APIs de snapshot CG são algumas opções. Compreender a melhor opção e o papel dos snapshots CG requer uma explicação mais detalhada da tecnologia.

A criação de um conjunto de snapshots de grupo de consistência é um processo de duas etapas:

O isolamento de escrita é estabelecido serialmente. Isso significa que, à medida que o processo de isolamento é configurado em vários destinos de armazenamento, a E/S de escrita é congelada no primeiro objeto da sequência, assim como continua congelada nos destinos que aparecem posteriormente na lista. Inicialmente, isso pode parecer violar o requisito de que a ordem de escrita seja preservada, mas isso se aplica apenas à E/S emitida de forma assíncrona no host e que não depende de outras escritas.

Por exemplo, um banco de dados pode emitir muitas atualizações assíncronas de arquivos de dados e permitir que o sistema operacional reordene a e/S e as complete de acordo com sua própria configuração de agendador. A ordem deste tipo de e/S não pode ser garantida porque a aplicação e o sistema operativo já lançaram a exigência de preservar a ordem de escrita.

Como contraexemplo, a maior parte da atividade de registro de logs em bancos de dados é síncrona. O banco de dados não prossegue com novas gravações de log até que a operação de E/S seja confirmada, e a ordem dessas gravações deve ser preservada. Se uma operação de E/S de log chegar a um LUN isolado, ela não será confirmada e o aplicativo ficará bloqueado em futuras gravações. Da mesma forma, a E/S de metadados do sistema de arquivos geralmente é síncrona. Por exemplo, uma operação de exclusão de arquivo não deve ser perdida. Se um sistema operacional com um sistema de arquivos xfs excluir um arquivo e a E/S que atualizou os metadados do sistema de arquivos xfs para remover a referência a esse arquivo chegar a um LUN isolado, então a atividade do sistema de arquivos será pausada. Isso garante a integridade do sistema de arquivos durante as operações de grupo de consistência.

Após a configuração do isolamento de escrita (write fencing) nos destinos, eles estão prontos para a criação de snapshots. Os snapshots não precisam ser criados exatamente ao mesmo tempo, pois o estado dos destinos é congelado do ponto de vista de escrita dependente. Para evitar falhas no aplicativo que cria os snapshots do grupo de consistência (CG), o isolamento de escrita inicial inclui um tempo limite configurável, no qual ONTAP libera automaticamente o isolamento e retoma o processamento de escrita após um número definido de segundos. Se todos os snapshots forem criados antes do término do período de tempo limite, o conjunto resultante de snapshots constitui um grupo de consistência válido.

Há duas abordagens principais para backups baseados em snapshot:

Um backup consistente com falhas de um banco de dados refere-se à captura de toda a estrutura do banco de dados, incluindo arquivos de dados, redo logs e arquivos de controle, em um ponto no tempo. Se o banco de dados estiver armazenado em um único volume, LUN ou namespace, o processo é simples; um snapshot pode ser criado a qualquer momento. Se um banco de dados abranger volumes AFF ou LUNs/namespaces ASA, um snapshot de grupo de consistência (CG) deve ser criado. Existem várias opções para criar snapshots de CG, incluindo o NetApp SnapCenter software, recursos nativos de grupo de consistência do ONTAP e scripts mantidos pelo usuário.

Os backups instantâneos consistentes com falhas são usados principalmente quando a recuperação do ponto no tempo do backup é suficiente. Os logs de arquivamento podem ser aplicados em algumas circunstâncias, mas quando é necessária uma recuperação mais granular em um ponto no tempo, um backup on-line é preferível.

O procedimento básico para um backup on-line baseado em snapshot é o seguinte:

Este procedimento produz um conjunto de instantâneos contendo datafiles no modo de backup e os logs críticos de arquivo gerados no modo de backup. Estes são os dois requisitos para recuperar um banco de dados. Arquivos como arquivos de controle também devem ser protegidos por conveniência, mas o único requisito absoluto é a proteção para arquivos de dados e logs de arquivo.

Embora clientes diferentes possam ter estratégias muito diferentes, quase todas essas estratégias são baseadas nos mesmos princípios descritos abaixo.

Ao projetar layouts de storage para bancos de dados Oracle, a primeira decisão é se deve ser usada a tecnologia NetApp SnapRestore baseada em volume (VBSR), que é a tecnologia subjacente usada para restaurar volumes AFF e LUNs/namespaces ASA.

O VBSR permite que os dados sejam revertidos quase instantaneamente para um ponto anterior no tempo. Como todos os dados são revertidos, o VBSR pode não ser apropriado para todos os casos de uso. Por exemplo, se um banco de dados inteiro, incluindo datafiles, redo logs e archive logs, estiver armazenado em um único AFF volume e esse volume for restaurado com VBSR, os dados serão perdidos porque os archive logs e os redo logs mais recentes serão descartados. O mesmo se aplica aos dados ASA. Se todo o banco de dados estiver armazenado em um único grupo de consistência ASA e esse grupo for restaurado para um estado anterior, alguns dos archive logs e redo logs mais recentes serão perdidos.

O VBSR não é necessário para a restauração. Muitos bancos de dados podem ser restaurados usando a restauração de arquivo único baseada em arquivo SnapRestore (SFSR) ou simplesmente clonando os arquivos do snapshot de volta para o sistema de arquivos ativo.

O VBSR é preferível quando um banco de dados é muito grande ou quando precisa ser recuperado o mais rápido possível, e o uso do VBSR requer o isolamento dos datafiles. Em um ambiente NFS, os datafiles de um determinado banco de dados devem ser armazenados em volumes dedicados que não sejam contaminados por nenhum outro tipo de arquivo. Em um ambiente SAN, os datafiles devem ser armazenados em LUNs ou namespaces dedicados. Se um volume manager for usado (incluindo Oracle Automatic Storage Management [ASM]), o diskgroup também deve ser dedicado aos datafiles.

Isolar os arquivos de dados dessa maneira permite que eles sejam revertidos a um estado anterior sem danificar outros sistemas de arquivos.

Para cada volume com dados Oracle em um ambiente AFF SAN, o percent-snapshot-space deve ser definido como zero porque reservar espaço para um snapshot em um ambiente LUN não é útil. Se a reserva fracionária for definida como 100, um snapshot de um volume com LUNs exigirá espaço livre no volume, excluindo a reserva do Snapshot, para absorver 100% da rotatividade de todos os dados. Se a reserva fracionária for definida com um valor menor, uma quantidade correspondentemente menor de espaço livre será necessária, mas sempre excluindo a reserva do Snapshot. Isso significa que o espaço da reserva do Snapshot em um ambiente LUN é desperdiçado.

Em um ambiente NFS, há duas opções:

Com a primeira opção, percent-snapshot-space é definido para um valor diferente de zero, normalmente em torno de 20%. Este espaço é então escondido do usuário. Esse valor não cria, no entanto, um limite de utilização. Se um banco de dados com uma reserva de 20% sofrer 30% de rotatividade, o espaço instantâneo pode crescer além dos limites da reserva de 20% e ocupar espaço não reservado.

O principal benefício de definir uma reserva para um valor como 20% é verificar se algum espaço está sempre disponível para instantâneos. Por exemplo, um volume 1TB com uma reserva de 20% permitiria apenas que um administrador de banco de dados (DBA) armazenasse 800GB TB de dados. Essa configuração garante pelo menos 200GBMB de espaço para consumo de snapshot.

Não há preferência clara entre a opção um e a opção dois entre os usuários finais.

O Oracle Doc ID 604683,1 explica os requisitos para suporte a instantâneos de terceiros e as várias opções disponíveis para operações de backup e restauração.

O fornecedor terceirizado deve garantir que os snapshots da empresa estejam em conformidade com os seguintes requisitos:

Os produtos de gerenciamento ONTAP e NetApp da Oracle atendem a esses requisitos.