Les snapshots + RAID comptent-ils comme une bonne solution de sauvegarde sur site?

Les deux principales raisons pour lesquelles je peux penser à prendre des sauvegardes semblent être prises en compte lorsque j'utilise à la fois des instantanés et RAID avec btrfs. (Par RAID ici, je veux dire RAID1 ou 10)

• Suppression accidentelle de données: les instantanés couvrent ce cas
• Échec d'un entraînement et pourriture du bit
  • Échec complet: RAID couvre ce cas
  • Disque renvoyant des données incorrectes: la fonction de correction d'erreur de RAID + btrfs couvre ce cas

Donc, en tant que solution de sauvegarde sur site, cela semble fonctionner correctement, et il n'a même pas besoin d'un périphérique de stockage de données distinct pour cela!

Cependant, j'ai entendu dire que RAID et les instantanés ne sont pas considérés comme des sauvegardes appropriées, donc je me demande si j'ai raté quelque chose.

Mis à part le fait que btrfs n'est pas encore une technologie mature, pouvez-vous penser à quelque chose que j'ai manqué? Ou ma pensée est-elle correcte et il s'agit d'une solution de sauvegarde sur site valide?

Non ce n'est pas.

Que se passe-t-il lorsque votre système de fichiers ou volume RAID est corrompu? Ou votre serveur est incendié? Ou quelqu'un formate accidentellement le mauvais tableau?

Vous perdez toutes vos données et les sauvegardes non réelles que vous pensiez avoir. C'est pourquoi les vraies sauvegardes sont sur un système complètement différent des données que vous sauvegardez - parce que les sauvegardes protègent contre quelque chose qui se produirait dans le système en question et qui entraînerait une perte de données. Conservez vos sauvegardes sur le même système que vous sauvegardez, et la perte de données sur ce système peut également avoir un impact sur vos "sauvegardes".

Pour la sauvegarde sur site , l'instantané peut être suffisant, à condition que vous «exportiez» régulièrement votre instantané ailleurs, où il existe en tant que données passives.

Et, testez régulièrement si votre «instantané livré» peut être restauré.

C'est ainsi que j'ai implémenté une sauvegarde rapide de certains de mes serveurs: stocker les données sur ZFS, prendre un instantané ZFS, envoyer le delta à un autre serveur, où tout le système de fichiers est recréé (moins le service réel en cours d'exécution).

Bien sûr, la meilleure sauvegarde est toujours hors site. Ainsi, après avoir «expédié» le ou les instantanés vers un système distinct, effectuez régulièrement une «déconnexion» des instantanés.

Ainsi, dans mon système, le serveur qui reçoit les deltas d'instantanés, sauvegarde régulièrement tous ses pools ZFS (y compris les instantanés antérieurs) sur bande.

Et bien sûr, testez vos sorties de bande pour vous assurer qu'elles peuvent être restaurées.

Remarque: Vous souhaiterez que l'instantané ait lieu pendant l'activité du disque au repos, et de préférence en coordination avec la base de données (le cas échéant) pour assurer la cohérence; sinon, le remède pourrait être pire que la maladie. C'est pourquoi la fonction «instantané» en direct de NetApp et EMC est très utile: ils reportent l'instantané d'un LUN jusqu'à ce que la base de données utilisant le LUN indique qu'il est sûr d'exécuter l'instantané.

Ce que HopelessN00b a dit. Non.

Les sauvegardes appropriées se trouvent sur un périphérique distinct de celui en cours de sauvegarde. Que se passe-t-il lorsque vous perdez deux disques ou plus? Que se passe-t-il lorsque votre salle de serveurs brûle? Que se passe-t-il lorsque quelqu'un détruit accidentellement votre baie?

(Alerte anecdote: j'ai entendu parler de quelqu'un qui avait configuré PXE pour installer automatiquement la dernière Fedora. Son onduleur a échoué. Après une panne de courant, son serveur a redémarré et a été configuré pour démarrer PXE et ... a installé Fedora sur ses données. Mon Des choses bizarres se produisent. Heureusement, il avait des sauvegardes appropriées.)

De préférence, vous avez au moins trois copies de vos données, une stockée complètement hors site au cas où le centre de données brûlerait.

Des instantanés correctement implémentés DOIVENT être pris en charge par votre stockage car des sauvegardes décentes les utilisent comme toute première étape de la création d'un travail de sauvegarde. C'est cependant une mauvaise idée d'utiliser des instantanés pour la sauvegarde principale. Les raisons:

1) Les instantanés et le stockage dorsal PEUVENT échouer. Les vraies sauvegardes doivent donc utiliser un ensemble de broches séparé, sinon il y a de grandes chances de perdre à la fois le jeu de travail principal et les données de sauvegarde en même temps.

2) Les instantanés «rongent» l'espace utilisable. Il est logique d'utiliser un stockage rapide et coûteux pour les données chaudes actuelles et les instantanés et les sauvegardes au déchargement étant des données glaciales pour un stockage moins cher et plus lent. Cela fonctionne très bien avec 1) BTW.

3) Les instantanés ralentissent généralement l'ensemble du processus. La plupart des systèmes utilisent la copie sur écriture et cette approche crée une fragmentation. Les redirections sur écriture sont plus rapides mais consomment BEAUCOUP d'espace. Très peu de fournisseurs ont correctement implémenté les instantanés. NetApp avec WAFL et Nimble Storage avec CASL (je ne suis affilié à aucun d'entre eux). Presque tout le monde a des problèmes. Par exemple, Dell Equallogic déclenche une mise à jour (et une perte) de 15 Mo sur chaque octet modifié. C'est cher.

Oui, ça l'est. C'est un moyen idéal pour stocker des sauvegardes. Rien d'autre n'est nécessaire, diable, même faire des vérifications d'intégrité n'est qu'une perte de temps.

Juste pour confirmer - avant de donner plus de conseils ... vous travaillez pour un de mes concurrents, non? Vous le faites vraiment, bien sûr? Non? Oh.

Désolé, NUTS. Non pas du tout. Désolé mec.

Le problème est que vous êtes totalement ouvert à toute erreur qui se produit dans (a) le système et (b) le niveau du système d'exploitation. Vous ne vous protégez essentiellement que contre la suppression de certaines données. Agréable. C'EST une erreur qui se produit souvent.

Ce que vous ne protégez pas, c'est:

• Un pic de puissance anéantissant la machine. J'y suis allé, vu ça.
• Un contrôleur de raid défectueux ou une écriture mémoire sh ** sur le disque - il y a quelque chose.

Et une longue liste d'autres choses.

C'est - naturellement, sauf si vous travaillez pour un de mes concurrents - vous devez toujours faire une sauvegarde:

• Sur un autre ordinateur
• Que vous isolez d'au moins les pics de puissance (même si vous avez un USV).

C'est pourquoi les bandes se balancent - elles ne sont pas connectées et tout ce qui court un feu ou une inondation ne leur fera pas de mal. Pic de puissance - il y a le lecteur de bande et peut-être le robot, mais les bandes qui ne sont pas dans le lecteur ne seront pas affectées.

MEILLEUR serait des sauvegardes hors site (ai-je déjà mentionné des choses comme les incendies et les inondations?) économiser cet argent).

Maintenant, vous pouvez penser "oh, les inondations ne se produisent jamais". Assurez-vous que vous êtes sûr. Voir, voici une vidéo d'une inondation 09.09.09 d'un centre de données vodaphone. Je suis sûr que vous comprendrez où se situe le problème pour une sauvegarde informatique interne / interne:

http://www.youtube.com/watch?v=ttcQy3bCiiU

Leçon tirée de l'échec de deux disques RAID-1 à moins d'une demi-heure l'un de l'autre: le RAID n'est pas un mécanisme de sauvegarde, en aucune façon, forme ou forme.

RAID est un mécanisme de disponibilité qui réduit les temps d'arrêt en cas de défaillance matérielle, mais il ne vous sera d'aucune utilité en cas de virus, de suppression / modification de données ou de panne matérielle catastrophique.

De nombreux administrateurs expérimentés adoptent ce que l'on appelle la règle des sauvegardes 3-2-1:

• Vous devez avoir au moins trois copies de vos données, y compris la source principale. C'est-à-dire qu'une seule sauvegarde n'est pas suffisante et les copies au sein du même système physique ne comptent pas.

• Vous devez utiliser au moins deux méthodes de sauvegarde différentes.

• Vous devez avoir au moins une copie hors site de vos données.

Les instantanés violent les trois parties:

• Vous n'utilisez qu'une seule machine physique. Tout ce qui affecte la machine entière, comme une panne de bloc d'alimentation, pourrait emporter toutes vos données.

• Vous n'utilisez qu'une seule méthode pour vos sauvegardes. Si quelque chose ne va pas, vous ne le découvrirez que lors de la restauration de la sauvegarde dans une situation de crise.

• Vous n'avez aucune sauvegarde hors site. Les inondations et les incendies n'arrivent qu'aux autres, jusqu'à ce qu'ils vous arrivent ...

Donc:

• Vous devez avoir au moins une sauvegarde sur une machine distincte de votre réseau local.

• Vous devez avoir au moins une sauvegarde qui n'est pas générée à l'aide d'instantanés. Peut-être qu'une bonne vieille tararchive incrémentielle pourrait être en ordre? Ou une rsynccopie basée?

• Vous devez avoir au moins une sauvegarde à distance, aussi loin que possible de votre emplacement actuel et certainement pas dans le même bâtiment.

Il convient également de noter que les instantanés au niveau du bloc ont à peu près les mêmes garanties de cohérence que de retirer la fiche de votre machine, puis de copier sur les disques. En général, vous devrez exécuter fsckaprès une restauration ou espérer que le journal est suffisant.

Les instantanés au niveau du système de fichiers devraient être meilleurs, mais ils ne garantiraient toujours pas la cohérence de vos fichiers. Pour de nombreuses applications (les serveurs de bases de données me viennent à l'esprit), la copie des fichiers d'une instance active peut être complètement inutile, car ils peuvent être dans un état incohérent. Vous devrez utiliser leur propre mécanisme de sauvegarde au niveau de l'application pour garantir l'existence d'une copie propre - pour laquelle la règle 3-2-1 s'appliquerait également.

Enfin, gardez à l'esprit qu'en ce moment, nous ne parlons que de copies de vos données actuelles . Pour vous prémunir contre les défaillances (ou les failles de sécurité, d'ailleurs) qui ne sont pas détectées pendant un certain temps, vous devez également disposer de plusieurs copies antérieures de vos données depuis un certain temps.

En soi, ce n'est pas du tout une solution de sauvegarde . Il réduira ou supprimera les temps d'arrêt dans certains scénarios de défaillance, mais ne vous protège pas du tout de nombreux autres

Cela peut bien sûr être un élément très précieux d'une solution de sauvegarde + disponibilité plus complète:

• RAID plus snapshows sur le même matériel
• Copies sur site sur un autre matériel (rappelez-vous: il existe des modes de défaillance qui supprimeraient l'ensemble de la boîte, du contrôleur, des lecteurs et tout d'un coup)
• Copies distantes semi-déconnectées
• et bien sûr des copies hors ligne + hors site appropriées pour de véritables catastrophes

Aussi: assurez-vous de tester régulièrement vos sauvegardes. Le pire moment pour découvrir que vos sauvegardes ne fonctionnent pas, c'est quand vous devez récupérer quelque chose d'eux ...