Notre boutique s'appuie fortement sur les instantanés de volume NetApp pour les sauvegardes. Nous utilisons des sauvegardes sur bande traditionnelles basées sur des agents pour certaines de nos données, mais dans l'ensemble, nous comptons sur les instantanés pour la majorité de nos systèmes. En outre , nous ne disposons pas d' une politique de contrôle des changements rigoureux ou d' une gestion centralisée de la configuration si tousde nos serveurs, que les données fournies par leurs services soient sauvegardées ou non, devraient être reconstruites à partir du bare-metal (et sans véritable documentation). Naturellement, cela fait des instantanés une proposition très intéressante pour la gestion car nous pouvons simplement récupérer l'intégralité du serveur, les données utilisateur et la configuration incluses. Nous utilisons la console de stockage virtuelle de NetApp pour créer des instantanés de nos banques de données VMware basées sur NFS et SnapDrive de NetApp pour les LUN mappés (physiques) de périphériques bruts qui sont présentés directement aux invités. Nous SnapMirror instantanés critiques hors site vers un autre Filer. Naturellement, nous testons régulièrement notre processus de restauration.
Je ne peux pas m'empêcher de me sentir mal à l'aise avec notre dépendance à l'égard des instantanés sur les sauvegardes. Pour moi, pour qu'une technologie soit considérée comme suffisante comme stratégie de sauvegarde, elle doit répondre aux critères suivants:
- La sauvegarde doit être atomique. C'est-à-dire que la sauvegarde ne peut compter sur rien d'autre pour sa récupération.
- La sauvegarde doit être séparée du système dont il s'agit (hors bande).
- La sauvegarde doit être copiée ou transportée vers un site distant (hors site)
Je crois comprendre que les instantanés NetApp fonctionnent selon une méthodologie de redirection sur écriture (RoW). La disposition des fichiers WAFL utilise un ensemble de pointeurs (métadonnées?) Qui font référence à chaque bloc de stockage où qu'il se trouve. Pour créer un instantané, le système prend simplement une copie des métadonnées d'un volume et la stocke dans l'espace réservé de ce volume. Toutes les écritures (créations / modifications / suppressions) sont redirigées vers de nouveaux blocs. C'est censé être la sauce spéciale qui rend la WAFL de NetApp si géniale parce que vous n'avez pas à lire, puis à écrire les anciennes données dans l'espace réservé, puis à écrire vos nouvelles données sur les anciennes, comme les instantanés de copie sur écriture.
J'admets pleinement que je ne peux pas comprendre exactement comment fonctionnent les instantanés de volume NetApp, mais si ma compréhension est plus ou moins correcte, les instantanés NetApp ne répondent pas à mes critères de sauvegarde.
- Ils ne sont pas atomiques. Le "cliché" n'est en réalité qu'un ensemble de pointeurs vers les données d'origine. Si les données d'origine ne sont plus là, les métadonnées sont inutiles.
- L'instantané n'est pas séparé du système. Si quelqu'un supprime le mauvais volume, je perds l'instantané. Si le NetApp Filer explose en minuscules petits chatons, je perds la sauvegarde. Je peux utiliser SnapMirror pour déplacer mes instantanés vers un autre Filer mais encore une fois, il s'agit simplement de déplacer les métadonnées et non les blocs réels. Si je perds le volume d'origine, je ne vois pas comment un instantané copié dans un autre Filer va aider.
Quelqu'un peut-il expliquer comment les instantanés NetApp peuvent être considérés comme des sauvegardes? Je recherche de bonnes réponses subjectives , veuillez donc étayer votre position par des faits, des références et de l'expérience. Si ma compréhension de la technologie sous-jacente est incorrecte, veuillez expliquer où et pourquoi cela change ma conclusion. Si votre boutique s'appuie sur des instantanés NetApp comme sauvegardes, veuillez inclure suffisamment d'informations contextuelles pour que les utilisateurs puissent avoir une idée du type de politique de récupération que vous devez respecter.