La question couramment posée sur l'utilisation des snapshots en tant que stratégie de protection des données est le fait que les données « réelles » et les données de snapshot se trouvent sur les mêmes disques. La perte de ces disques entraînerait la perte des données primaires et de la sauvegarde.

Ce problème est valide. Les snapshots locaux sont utilisés pour les besoins quotidiens de sauvegarde et de restauration, et dans ce sens, le snapshot est une sauvegarde. Dans les environnements NetApp, près de 99 % des scénarios de restauration s'appuient sur des copies Snapshot pour répondre aux exigences de RTO les plus strictes.

Toutefois, les snapshots locaux ne doivent jamais être la seule stratégie de sauvegarde. C'est pourquoi NetApp propose des technologies telles que la réplication SnapMirror et SnapVault pour répliquer rapidement et efficacement des copies Snapshot sur un ensemble indépendant de disques. Dans une solution bien conçue avec des snapshots et une réplication Snapshot, l'utilisation des bandes peut être réduite au minimum, voire même à une archive trimestrielle, ou totalement éliminée.

Vous pouvez utiliser les copies Snapshot ONTAP pour protéger vos données, et les copies Snapshot sont la base de nombreuses autres fonctionnalités ONTAP, notamment la réplication, la reprise d'activité et le clonage. Une description complète de la technologie Snapshot ne fait pas partie du présent document, mais les sections suivantes offrent un aperçu général.

Il existe deux approches principales pour créer un snapshot d'un dataset :

Une sauvegarde cohérente après panne d'un dataset fait référence à la capture de l'ensemble de la structure du dataset à un point dans le temps. Si le dataset est stocké dans un seul volume, le processus est simple ; il est possible de créer une copie Snapshot à tout moment. Si un dataset s'étend sur plusieurs volumes, un snapshot de groupe de cohérence doit être créé. Plusieurs options sont disponibles pour la création des snapshots de groupe de cohérence, notamment le logiciel NetApp SnapCenter, les fonctionnalités natives de groupe de cohérence ONTAP et les scripts gérés par l'utilisateur.

Les sauvegardes cohérentes après panne sont principalement utilisées lorsque la restauration au point de sauvegarde est suffisante. Lorsqu'une restauration plus granulaire est nécessaire, des sauvegardes cohérentes au niveau des applications sont généralement nécessaires.

Le mot "cohérent" dans "application-cohérente" est souvent un mal nommer. Par exemple, le placement d'une base de données Oracle en mode de sauvegarde est appelé sauvegarde cohérente au niveau des applications, mais les données ne sont en aucun cas rendues cohérentes ou suspendues. Les données continuent de changer tout au long de la sauvegarde. En revanche, la plupart des sauvegardes MySQL et Microsoft SQL Server ont effectivement mis les données au repos avant d'exécuter la sauvegarde. VMware peut rendre certains fichiers cohérents ou non.

Le terme « groupe de cohérence » fait référence à la capacité d'une baie de stockage à gérer plusieurs ressources de stockage comme une seule image. Par exemple, une base de données peut comprendre 10 LUN. La baie doit pouvoir sauvegarder, restaurer et répliquer ces 10 LUN de manière cohérente. La restauration n'est pas possible si les images des LUN n'étaient pas cohérentes au point de sauvegarde. La réplication de ces 10 LUN nécessite que tous les réplicas soient parfaitement synchronisés.

Le terme « groupe de cohérence » n'est pas souvent utilisé lors des discussions sur ONTAP, car la cohérence a toujours été une fonction de base de l'architecture de volumes et d'agrégats au sein de ONTAP. De nombreuses autres baies de stockage gèrent des LUN ou des systèmes de fichiers en tant qu'unités individuelles. Ils peuvent ensuite être configurés en tant que « groupe de cohérence » pour la protection des données, mais cette étape supplémentaire est nécessaire dans la configuration.

ONTAP a toujours pu capturer des images locales et répliquées cohérentes de données. Bien que les différents volumes d'un système ONTAP ne soient généralement pas officiellement décrits comme des groupes de cohérence, c'est ce qu'ils sont. Une copie Snapshot de ce volume est une image de groupe de cohérence. La restauration de ce Snapshot correspond à une restauration de groupe de cohérence. SnapMirror et SnapVault proposent tous deux une réplication de groupe de cohérence.

Les copies Snapshot de groupe de cohérence (cg-snapshots) sont une extension de la technologie Snapshot ONTAP de base. Une opération de snapshot standard crée une image cohérente de toutes les données d'un même volume, mais il est parfois nécessaire de créer un ensemble cohérent de snapshots sur plusieurs volumes et même sur plusieurs systèmes de stockage. Il en résulte un ensemble de snapshots qui peuvent être utilisés de la même manière qu'un snapshot d'un seul volume individuel. Elles peuvent être utilisées pour la restauration des données locales, répliquées à des fins de reprise après incident ou clonées sous la forme d'une unité cohérente unique.

L'utilisation la plus connue des cg-snapshots concerne un environnement de base de données d'environ 1 po de capacité couvrant 12 contrôleurs. Les snapshots de groupe de cohérence créés sur ce système ont été utilisés pour la sauvegarde, la restauration et le clonage.

La plupart du temps, lorsqu'un dataset s'étend sur des volumes et que l'ordre d'écriture doit être préservé, le logiciel de gestion choisi utilise automatiquement un snapshot de groupe de cohérence. Dans ce cas, il n'est pas nécessaire de comprendre les détails techniques des cg-snapshots. Toutefois, les exigences complexes en matière de protection des données nécessitent un contrôle détaillé du processus de protection et de réplication des données. Certains workflows d'automatisation ou scripts personnalisés permettent d'appeler les API cg-Snapshot. Pour comprendre la meilleure option et le rôle de cg-snapshot, vous devez fournir une explication plus détaillée de la technologie.

La création d'un ensemble de snapshots des groupes de cohérence s'effectue en deux étapes :

L'escrime d'écriture est établi en série. Cela signifie que lorsque le processus de recel est configuré sur plusieurs volumes, les E/S d'écriture sont bloquées sur le premier volume de la séquence au fur et à mesure qu'elles continuent d'être validées sur les volumes qui apparaissent plus tard. Cela peut sembler initialement contraire à l'exigence de préservation de l'ordre d'écriture, mais cela s'applique uniquement aux E/S émises de manière asynchrone sur l'hôte et ne dépend pas d'autres écritures.

Par exemple, une base de données peut émettre de nombreuses mises à jour asynchrones des fichiers de données et permettre au système d'exploitation de réorganiser les E/S et de les compléter selon sa propre configuration de planificateur. L'ordre de ce type d'E/S ne peut pas être garanti car l'application et le système d'exploitation ont déjà libéré l'obligation de conserver l'ordre d'écriture.

Par exemple, la plupart des activités de journalisation de la base de données sont synchrones. La base de données ne procède pas à d'autres écritures de journal tant que les E/S n'ont pas été acquittées et que l'ordre de ces écritures doit être conservé. Si une E/S de journal arrive sur un volume clôturé, elle n'est pas validée et l'application se bloque lors d'écritures ultérieures. De même, les E/S des métadonnées du système de fichiers sont généralement synchrones. Par exemple, une opération de suppression de fichier ne doit pas être perdue. Si un système d'exploitation doté d'un système de fichiers xfs supprime un fichier et que les E/S qui ont mis à jour les métadonnées du système de fichiers xfs pour supprimer la référence à ce fichier ont été reçues sur un volume isolé, l'activité du système de fichiers est alors interrompue. Cela garantit l'intégrité du système de fichiers pendant les opérations cg-Snapshot.

Une fois l'isolation d'écriture configurée sur les volumes cibles, ils sont prêts pour la création d'instantanés. Les snapshots n'ont pas besoin d'être créés précisément en même temps, car l'état des volumes est figé du point de vue de l'écriture dépendant. Pour éviter toute faille dans l'application qui crée les instantanés cg, l'escrime d'écriture initiale inclut un délai configurable dans lequel ONTAP libère automatiquement l'escrime et reprend le traitement d'écriture après un nombre défini de secondes. Si tous les snapshots sont créés avant l'expiration du délai, le jeu de snapshots résultant est un groupe de cohérence valide.

Il existe deux approches principales des sauvegardes basées sur des snapshots :

Une sauvegarde cohérente après panne d'une base de données fait référence à la capture à un moment précis de l'ensemble de la structure de la base de données, y compris les fichiers de données, les journaux de reprise et les fichiers de contrôle. Si la base de données est stockée sur un seul volume, le processus est simple ; il est possible de créer un Snapshot à tout moment. Si la base de données s'étend sur plusieurs volumes, un snapshot de groupe de cohérence doit être créé. Plusieurs options sont disponibles pour la création des snapshots de groupe de cohérence, notamment le logiciel NetApp SnapCenter, les fonctionnalités natives de groupe de cohérence ONTAP et les scripts gérés par l'utilisateur.

Les sauvegardes Snapshot cohérentes après panne sont principalement utilisées lorsque la restauration au point de sauvegarde est suffisante. Les journaux d'archivage peuvent être appliqués dans certains cas, mais lorsqu'une restauration granulaire à un point dans le temps est nécessaire, il est préférable d'effectuer une sauvegarde en ligne.

La procédure de base pour une sauvegarde en ligne basée sur un snapshot est la suivante :

Cette procédure permet d'obtenir un ensemble de snapshots contenant les fichiers de données en mode de sauvegarde et les journaux d'archivage critiques générés en mode de sauvegarde. Il s'agit des deux conditions requises pour restaurer une base de données. Il est également conseillé de protéger les fichiers tels que les fichiers de contrôle, mais la seule condition absolue est la protection des fichiers de données et des journaux d'archivage.

Même si différents clients peuvent avoir des stratégies très différentes, la quasi-totalité de ces stratégies s'appuient sur les mêmes principes que ceux décrits ci-dessous.

Lors de la conception d'infrastructures de volumes pour les bases de données Oracle, la première décision est d'utiliser ou non la technologie VBSR (Volume-Based NetApp SnapRestore).

La fonction SnapRestore basée sur les volumes permet de rétablir quasi instantanément un volume à un point antérieur. Toutes les données du volume étant rétablies, VBSR peut ne pas convenir à toutes les utilisations. Par exemple, si l'intégralité d'une base de données, y compris les fichiers de données, les journaux de reprise et les journaux d'archivage, est stockée sur un seul volume restauré avec VBSR, les données sont perdues, car les nouveaux journaux d'archivage et les données de reprise sont supprimés.

La technologie VBSR n'est pas requise pour la restauration. De nombreuses bases de données peuvent être restaurées avec SFSR (Single File SnapRestore) ou en copiant simplement les fichiers du snapshot vers le système de fichiers actif.

La technologie VBSR est recommandée pour les bases de données très volumineuses ou si une restauration doit être effectuée le plus rapidement possible et que l'utilisation de VBSR nécessite l'isolement des fichiers de données. Dans un environnement NFS, les fichiers de données d'une base de données doivent être stockés sur des volumes dédiés non endommagés par d'autres types de fichiers. Dans un environnement SAN, les fichiers de données doivent être stockés sur des LUN dédiés sur des volumes dédiés. Si un gestionnaire de volumes est utilisé (y compris Oracle Automatic Storage Management (ASM)), le groupe de disques doit également être dédié aux fichiers de données.

Cette méthode d'isolement des fichiers de données permet de rétablir leur état antérieur sans endommager d'autres systèmes de fichiers.

Pour chaque volume contenant des données Oracle dans un environnement SAN, le percent-snapshot-space Doit être défini sur zéro car il n'est pas utile de réserver de l'espace pour un snapshot dans un environnement LUN. Si la réserve fractionnaire est définie sur 100, un snapshot d'un volume avec des LUN nécessite suffisamment d'espace libre dans le volume, à l'exception de la réserve Snapshot, pour absorber 100 % de CA de toutes les données. Si la réserve fractionnaire est définie sur une valeur inférieure, une quantité d'espace libre correspondante est nécessaire, mais elle exclut toujours la réserve snapshot. Cela signifie que l'espace de réserve du snapshot dans un environnement de LUN est gaspillé.

Dans un environnement NFS, deux options sont possibles :

Avec la première option, percent-snapshot-space est défini sur une valeur différente de zéro, généralement autour de 20 %. Cet espace est alors masqué par l'utilisateur. Toutefois, cette valeur ne crée pas de limite d'utilisation. Si une base de données avec une réservation de 20 % connaît un chiffre d'affaires de 30 %, l'espace snapshot peut dépasser les limites de la réserve de 20 % et occuper un espace non réservé.

Le principal avantage de la définition d'une réserve sur une valeur telle que 20 % est de vérifier qu'un peu d'espace est toujours disponible pour les snapshots. Par exemple, un volume de 1 To avec une réserve de 20 % permettrait uniquement à un administrateur de base de données (DBA) de stocker 800 Go de données. Cette configuration garantit au moins 200 Go d'espace pour la consommation de snapshots.

Quand percent-snapshot-space est défini sur zéro, tout l'espace du volume est disponible pour l'utilisateur final, ce qui offre une meilleure visibilité. L'administrateur de base de données doit comprendre que, s'il constate qu'un volume de 1 To exploite les snapshots, cet espace de 1 To est partagé entre les données actives et le renouvellement du Snapshot.

Il n'existe pas de préférence claire entre l'option 1 et l'option 2 parmi les utilisateurs finaux.

Oracle Doc ID 604683.1 décrit les conditions requises pour la prise en charge des snapshots tiers et les nombreuses options disponibles pour les opérations de sauvegarde et de restauration.

Les fournisseurs tiers doivent garantir la conformité de leurs snapshots à plusieurs exigences :

Les produits de gestion Oracle de ONTAP et NetApp sont conformes à ces exigences.