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.

ONTAP a toujours été capable de capturer des images cohérentes locales et répliquées des données. Bien que les différents volumes sur un système ONTAP AFF/FAS ne soient généralement pas formellement décrits comme un groupe de cohérence, c'est pourtant ce qu'ils sont. Un instantané de ce volume est une image de groupe de cohérence, la restauration de cet instantané est une restauration de groupe de cohérence, et à la fois SnapMirror et SnapVault offrent la réplication de groupe de cohérence.

Les systèmes AFF incluent également un type plus étendu de groupe de cohérence. Plusieurs volumes peuvent être définis comme un groupe de cohérence au sein d'ONTAP. Les instantanés, les clones et la réplication peuvent ensuite être configurés au niveau du groupe de cohérence. Cela simplifie les stratégies de protection des données, car il est possible de définir des politiques sur les ensembles de données, et non plus seulement sur des volumes ou des LUN individuels. Les groupes de cohérence existent également dans les systèmes ASA. Plusieurs LUN ou espaces de noms peuvent être liés au sein d'un groupe de cohérence, lequel peut ensuite être protégé par des instantanés, répliqué, restauré ou cloné.

Les snapshots de groupe de cohérence (CG) constituent une extension de la technologie de snapshot ONTAP de base. Une opération de snapshot standard crée une image cohérente de toutes les données au sein d’un volume AFF/FAS unique ou d’un LUN/espace de noms ASA, mais il est parfois nécessaire de créer un ensemble cohérent de snapshots répartis sur plusieurs ressources de stockage, voire sur plusieurs systèmes de stockage. On obtient ainsi un ensemble de snapshots utilisables de la même manière qu’un snapshot d’un seul volume. Ils peuvent être utilisés pour la restauration des données localement, répliqués à des fins de reprise après sinistre, ou clonés en une seule unité cohérente.

Les snapshots CG offrent une excellente scalabilité. Le cas d'utilisation le plus important connu concerne un environnement de base de données d'environ 1PB réparti sur 12 contrôleurs. Les snapshots CG créés sur ce système ont servi à la sauvegarde, à la restauration et au clonage.

La plupart du temps, lorsqu’un ensemble de données s’étend sur des volumes AFF ou des LUN/espaces de noms ASA, et que l’ordre d’écriture doit être préservé, un groupe de cohérence ONTAP peut simplement être défini et le groupe de volumes, LUN ou espaces de noms peut être géré nativement pour créer des instantanés. Si un logiciel de gestion est utilisé, il doit détecter la nécessité de créer des instantanés de groupe de cohérence et appeler les API requises.

Dans de tels cas, il n'est pas nécessaire de comprendre les détails techniques des snapshots CG. Cependant, il existe des situations dans lesquelles des 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. Les workflows d'automatisation ou l'utilisation de scripts personnalisés pour appeler les API des snapshots CG sont quelques-unes des options. Comprendre la meilleure option et le rôle des snapshots CG nécessite une explication plus détaillée de la technologie.

La création d'un ensemble de snapshots de groupe de cohérence est un processus en deux étapes :

Le blocage en écriture est établi séquentiellement. Cela signifie que, lors de la mise en place du blocage sur plusieurs cibles de stockage, les E/S en écriture sont gelées sur le premier objet de la séquence, et ce blocage se poursuit sur les cibles suivantes. Cela peut sembler, de prime abord, enfreindre l’exigence de préservation de l’ordre d’écriture, mais cela ne concerne que les E/S émises de manière asynchrone sur l’hôte et indépendantes 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.

À titre de contre-exemple, la plupart des activités de journalisation des bases de données sont synchrones. La base de données ne procède à aucune écriture supplémentaire dans le journal tant que l’E/S n’est pas acquittée, et l’ordre de ces écritures doit être préservé. Si une E/S de journalisation arrive sur un LUN isolé, elle n’est pas acquittée et l’application est bloquée lors des écritures suivantes. De même, les E/S de 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 avec un système de fichiers xfs supprime un fichier et que l’E/S qui met à jour les métadonnées du système de fichiers xfs pour supprimer la référence à ce fichier arrive sur un LUN isolé, alors l’activité du système de fichiers est suspendue. Ceci garantit l’intégrité du système de fichiers pendant les opérations de groupe de cohérence (CG).

Une fois le confinement d'écriture configuré sur les cibles, celles-ci sont prêtes pour la création d'instantanés. Il n'est pas nécessaire que les instantanés soient créés simultanément, car l'état des cibles est figé du point de vue des écritures dépendantes. Afin de prévenir toute défaillance de l'application créant les instantanés du groupe de cohérence, le confinement d'écriture initial inclut un délai d'expiration configurable dans lequel ONTAP libère automatiquement le confinement et reprend le traitement des écritures après un nombre de secondes défini. Si tous les instantanés sont créés avant l'expiration de ce délai, l'ensemble résultant constitue 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 consiste à capturer l'intégralité de la structure de la base de données, y compris les fichiers de données, les journaux de restauration et les fichiers de contrôle, à un instant précis. Si la base de données est stockée sur un seul volume, LUN ou espace de noms, le processus est simple ; un instantané peut être créé à tout moment. Si une base de données s'étend sur des volumes AFF ou des LUN/espaces de noms ASA, un instantané de groupe de cohérence (CG) doit être créé. Plusieurs options existent pour créer des instantanés CG, notamment le logiciel NetApp SnapCenter, les fonctionnalités natives de groupe de cohérence ONTAP et les scripts personnalisés.

Les sauvegardes par instantané cohérentes après panne sont principalement utilisées lorsque la restauration à un point précis de la sauvegarde est suffisante. Les journaux d'archive peuvent être appliqués dans certains cas, mais lorsqu'une restauration plus précise à un instant donné est nécessaire, une sauvegarde en ligne est préférable.

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 des architectures de stockage pour les bases de données Oracle, la première décision consiste à déterminer s'il faut utiliser la technologie NetApp SnapRestore basée sur les volumes (VBSR), qui est la technologie sous-jacente utilisée pour la restauration des volumes AFF et des LUN/espaces de noms ASA.

La restauration de base de données par VBSR permet de rétablir quasi instantanément un état antérieur des données. Cependant, comme toutes les données sont restaurées, VBSR peut ne pas convenir à tous les cas d'utilisation. Par exemple, si une base de données, incluant les fichiers de données, les journaux de restauration et les journaux d'archivage, est stockée sur un seul volume AFF et que ce volume est restauré avec VBSR, des données sont perdues car les journaux d'archivage et les journaux de restauration les plus récents sont supprimés. Il en va de même pour les données ASA. Si la base de données entière était stockée dans un seul groupe de cohérence ASA, et que ce groupe était restauré à un état antérieur, certaines données des journaux d'archivage et des journaux de restauration les plus récents seront perdues.

VBSR n'est pas nécessaire pour la restauration. De nombreuses bases de données peuvent être restaurées à l'aide de la restauration de fichiers unique SnapRestore (SFSR) ou simplement en clonant les fichiers de l'instantané dans le système de fichier actif.

VBSR est privilégié lorsque la base de données est très volumineuse ou lorsqu'elle doit être restaurée aussi rapidement que possible, et l'utilisation de VBSR requiert l'isolation des fichiers de données. Dans un environnement NFS, les fichiers de données d'une base de données donnée doivent être stockés dans des volumes dédiés, non contaminés par tout autre type de fichier. Dans un environnement SAN, les fichiers de données doivent être stockés dans des LUN ou des espaces de noms 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.

L'isolation des fichiers de données de cette manière permet de les restaurer à un état antérieur sans endommager les autres systèmes de fichiers.

Pour chaque volume contenant des données Oracle dans un environnement SAN AFF, la `percent-snapshot-space`doit être fixée à zéro, car réserver de l'espace pour un snapshot dans un environnement LUN est inutile. Si la réserve fractionnaire est fixée à 100, un snapshot d'un volume avec des LUNs nécessite suffisamment d'espace libre dans le volume, hors réserve de snapshot, pour absorber 100 % du renouvellement de toutes les données. Si la réserve fractionnaire est fixée à une valeur inférieure, une quantité d'espace libre proportionnellement moindre est requise, mais elle exclut toujours la réserve de snapshot. Cela signifie que l'espace réservé aux snapshots dans un environnement 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.