Mise en place d’une solution de Sauvegarde: les questions à se poser

Au cours de la lecture de cet entrée, vous retrouvez les différents points d’interrogation que toute personne peut être amenée à se poser dans le cadre d’un besoin lié à la mise en place d’un système de sauvegarde. Nous espérons que ces questionnements ainsi que les débuts de réponses apportées allant de l’aide à la définition du besoin, aux choix des solutions candidates en passant aux préparatifs de mise en place jusqu’au déploiement, pourront vous aider à être mieux préparé pour réaliser votre projet.

La différence est importante, car la plupart des méthodes de sauvegardes de systèmes sont orientées vers le fait de permettre une restauration rapide et simple, mais par contre ne permettent pas forcément des restaurations de fichiers pris isolément.Cependant certaines solutions, généralement des produits tiers, peuvent permettre les deux, mais ce n’est pas toujours le cas, aussi il reste judicieux d’opter pour la solution la plus proche de vos besoins dès le départ.Des sauvegardes système impliquent des “dumps” (copie bit à bit) de partitions et/ou de disques complets: accès moins immédiat au contenu, mais simplicité accrue lors de restauration.Quelques éléments de réponses :

  • Si vos sauvegardes “fichiers”, avec le temps finissent pour diverses raisons par contenir des données systèmes (fichiers du système d’exploitation et de logiciels), c’est probablement un signe que votre besoin initial a changé et qu’il serait peut être judicieux de passer à une sauvegarde système.
  • Si vous être confrontés au besoin récurrent de restaurer seulement quelques fichiers ou dossier, par exemple pour corriger une erreur d’un de vos collaborateurs, et que la procédure vous semble trop compliquée et/ou trop chronophage, il est peut être temps d’opter une sauvegarde orientée fichiers plutôt que système.

Il reste évidemment possible et c’est même fortement conseillé, de cumuler les différentes approches. Cela a bien sur un impact sur le coût, il convient donc de bien étudier la situation pour optimiser au mieux, tout en tirant le meilleur parti de chaque approche, de manière complémentaire.

Pour répondre à cela, il faut impérativement anticiper dans quelles circonstances les sauvegardes peuvent être amenées a être utilisées.Le besoin de “revenir en arrière”, sur tout ou une partie des données, est très variable selon les types d’utilisateurs, aussi le mieux est de questionner ceux-ci avant tout. Ce besoin peut également parfois découler d’obligation légale ou administrative.

Type de sauvegardeAvantagesInconvénients
FullJeux de données complets, accès immédiatTaille maximum, temps de sauvegarde long
DifférentielleDeux jeux de donnée maxi (1 full, et le dernier différentiel)Des full doivent être fait régulièrement pour optimiser les temps de restaurations
IncrémentalesPoints de restaurations multiples dans le tempsTemps de restauration long. des full doivent être fait régulièrement, comme pour les différentielle et pour les même raisons

A contrario, si les données n’évoluent que très peu, ces modes de sauvegardes sont très avantageux, car optimisant l’occupation disque, et permettant des points de sauvegardes nombreux.

Dans la pratique par contre, un nombre excessif de sauvegardes incrémentales entraîne lors d’une restauration, un rejeu proportionnellement aussi long et complexe à réaliser qu’il y a de points de sauvegarde à parcourir. C’est pour cette raison, que l’on définit généralement des politiques telles que cet exemple:

JourServeurs A, B et CServeurs D, E et F
Dimanchefullincrémentale
Lundiincrémentalefull
Mardiincrémentaleincrémentale
Mercrediincrémentaleincrémentale
Jeudiincrémentaleincrémentale
Vendrediincrémentaleincrémentale
Samediincrémentaleincrémentale

Dans ce cas, qui n’est bien sur qu’un exemple, chaque serveur est sujet à une sauvegarde complète chaque semaine. Selon vos besoins, ces rotations peuvent être autres: mensuelles, annuelles, ou journalières (ex: une sauvegarde full à minuit, puis une incrémentale toute les 2 heures).

Notez également que l’exécution des full est ici groupée 3 serveurs par 3 serveurs afin de limiter la saturation des liens réseaux. A adapter également selon les besoins.

En l’absence de besoins avérés, l’approche la plus simple possible consiste à effectuer une simple synchronisation, c’est à dire une copie de ce qui a été modifié plutôt qu’une copie systématique de l’ensemble. Cela implique que :

  • Vous n’aurez qu’un seul “cliché” des données datées de l’heure d’exécution de la sauvegarde.
  • Les suppressions de fichiers à la source étant répercutées sur la sauvegarde, une demande de restauration d’un fichier supprimé par erreur ne peut intervenir qu’avant la prochaine exécution de la sauvegarde, après il sera trop tard.

Donc si cela a l’avantage de la simplicité, les limitations sont à prendre sérieusement en compte. A réserver à des situations on l’on sauvegarde avant tout par pure précaution. Dans des situations plus critiques ou le besoin de contrôle est plus grand on privilégiera les autres approches.

Concernant l’utilité, il convient de dialoguer avec les personnes qui exploitent les données, elles sont les mieux placées pour vous signaler une évolution des besoins, des oublis éventuels ou autres perfectionnements possibles.Pour ce qui est d’être utilisable, c’est à la personne en charge des sauvegardes de s’en assurer, probablement en collaboration avec les personnes utilisant les données. Une bonne manière de s’en assurer est de mettre en place des tests de restauration, au plus proche de la situation réelle. Cela est une étape lors de la mise en place d’un PRA.Pensez à prévoir comment réagir en cas de non fonctionnement du test (rollback), il s’agit de ne pas pénaliser la production. La souplesse apportée par le Cloud permet la mise en place facilitée de tel tests et simulations, grâce a la facilité de clonage de VM, les snapshots, le provisioning quasi instantané etc…
A faire confirmer par vos utilisateurs. Dans certains cas, il est effectivement possible d’ignorer beaucoup de choses et ainsi de gagner beaucoup de place.

Vous pouvez souhaiter utiliser le Cloud afin de procéder à la sauvegarde de données présente sur votre station de travail, dans votre entreprise etc. Il existe diverses manières d’y parvenir :

  • Chaque station envoie directement les données sur le Cloud, via un montage réseau, ou script utilisant robocopy, rsync, une application tierce (ex: Dragondisk)
  • A l’inverse, c’est le serveur qui déclenche les sauvegardes des stations de travail. La aussi, plusieurs possibilités: scripts, agents et applications tierces etc.
  • Alternative mixte: une 1ère sauvegarde est gérée et stockée sur une machine locale, puis une copie de sécurité est déposée sur le Cloud.

Enfin, n’hésitez pas à faire appel à notre service de consultance et éventuellement à nos services d’infogérance si vous avez besoin d’accompagnement dans la définition et la mise en place de ce type de sauvegardes vers le Cloud.

Cette disponibilité dépend fortement du secteur d’activité. Totalement impensable dans certains contextes, et parfois souhaité ailleurs.Si cela est envisagé, cela peut avoir l’avantage de rendre les utilisateurs plus autonomes. Encore faut-il clairement définir ce qui est possible (par exemple restauration par l’utilisateur d’un fichier supprimé par erreur) et ce qui n’est pas possible (par exemple, restauration complète d’un poste de travail, qui fait hors contrôle va faire perdre les données récentes).L’idéal étant bien sûr de ne pas exposer les détails de fonctionnement du système de sauvegarde aux utilisateurs. Au lieu de cela, il peut très intéressant d’intégrer dans vos outils et sites des fonctionnalités accessibles, sécurisés et bien encadrées, par exemple :

  • Fonctions de recherche d’emails supprimés dans un Webmail, ou plus globalement, des fonctions de recherches de données supprimées (dans un Groupware, système GED, ERP, etc…)
  • Mise à disposition d’espace de sauvegarde complémentaire, à usage manuel et individuel, constituant ici une commodité s’ajoutant (et ne remplaçant pas) à une politique globale de sauvegarde.

Passons en revue les différents supports envisageables et disponibles avec le service Cloud Computing d’Aruba :

Ce service est décliné en plusieurs modes de facturations. Pour plus de détails : tarifs des packs

Pour utiliser l’Object Storage dans le cadre d’une solution de sauvegarde, il faudra utiliser un connecteur compatible S3 et supporté, ou utiliser la couche d’abstraction DeltaCloud qui supporte Aruba nativement.

Voir les liens suivants:

Avertissement : le fait de manipuler de nombreux fichiers avec Object Storage sera extrêmement pénalisant d’un point de vue performance. La bonne approche consiste donc à envoyer des sauvegardes déjà archivées (fichier tar, rar, zip, ou autres formats spécifiques) sur le Cloud Object Storage. Si besoin, des archives multi-volumes peuvent être utilisées.

AvantagesInconvénients
Coût très compétitifIntégration nécessaire via S3 ou DeltaCloud
Bonnes performances et résilience à la sourceArchivage nécessaire (sauf cas très simples) donc pas d’accès direct aux fichiers sauvegardés
Facilité de partager des archives de sauvegardes si besoin, gestion des droits

Il est possible d’utiliser la nos templates de VM pour les utiliser comme stockage, avec les protocoles de votre choix (NFS, CIFS, iSCSI, SFTP, etc…).

Pour les détails sur les offres disponibles et les coûts au GO du stockage pour les VM et ceux sur différents hyperviseurs, merci de consulter la section Tarifs de notre offre Cloud Computing.

AvantagesInconvénients
Coût modéréLimitation à 2TO par VM (offre Pro)
Bonnes performances et résilience à la sourceLa présence de l’OS peut constituer un point de défaillance supplémentaire
Possibilités de personnalisation avancéeParamétrages réseau, pare-feu, services et protocoles de Stockage, relativement complexes
Simplicité d’accès si des protocoles standards sont utilisés

Notes : Dans le cas de VM présentes sur différent datacenters (ou en dehors d’Aruba), ne pas sous-estimer le soin à apporter au paramétrage des différents pare-feu, ou mise en place éventuelle de VPN. Il convient également de prendre en compte que les taux de transferts entre les datacenters passent par Internet, et sont donc variables.

Pour rappel, l’Unified Storage consiste en la mise à disposition, par incréments de 100GO, de stockage accessible depuis vos VM en utilisant un des protocoles suivant: NFS, CIFS, iSCSI

AvantagesInconvénients
Très grande performance et résilienceCoût plus élevé
Protocoles standards: NFS, CIFS, iSCSI
Volume au-delà de 2TO possibles

La réponse dépend de plusieurs facteurs. Voici deux des plus importants à prendre en compte :

  1. La fréquence d’exécution de la sauvegarde: sauf dans le cas de scénario complexe en plusieurs phases, c’est une limite absolue. Idéalement la durée d’exécution sera bien en deçà, mais dès que des transferts passent par Internet (càd – sortent du réseau du datacenter) les durées peuvent croître très fortement.
  2. Le fait que le type de sauvegarde retenue puisse pénaliser ou non la production (ralentissements, arrêts temporaires de certains services pour le cas de sauvegarde “à froid”, etc…). Si l’approche retenue n’est pas impactante, le fait que la sauvegarde déborde en heures de travail n’est pas handicapant (même si peu idéal). Dans le cas contraire, il faut chercher à modifier l’approche pour que cela “passe” dans la fenêtre horaire impartie (d’autres entrées de ce document pourront donner d’éventuelles pistes de recherche.
Cela dépend entièrement de vos préférences et des contraintes liées à vos activités. Il vous faut toujours considérer que ce qui a été modifié depuis la dernière sauvegarde sera perdu, en cas de restauration de données. Cette durée de perte admissible conditionne directement la fréquence d’exécution.A noter toutefois, qu’il n’est pas obligatoire (et même rarement nécessaire), de voir les données à sauvegarder comme un “tout” solidaire ne pouvant être traité qu’en un seul bloc. Il est possible de déterminer des approches et solutions différentes pour des besoins différents. Cela permet, éventuellement, de faire fonctionner plusieurs solutions en parallèle, et d’avoir plus de souplesse concernant les fréquences d’exécution en ne gardant des fréquences élevées strictement où cela est nécessaire.
Vous avez probablement déjà la réponse à cette question, tant elle est liée à la nature de votre activité.Si ce n’est pas le cas, il est conseillé de procéder à une sorte de simulation de panne ou d’incident dans laquelle tout ou partie de vos données sont supprimées ou corrompues, et une restauration doit avoir lieu. L’observation de ce qui en découle pourra vous donner un début de réponse.Dans le doute, il existe aussi une tentation de répondre “oui” à cette question. Cela dis, si personne n’est enthousiaste à l’idée d’une restauration “lente” de ses donnée, il convient de ne pas perdre de vue l’aspect économique; la rapidité engendre un surcoût, qui n’a rien de marginal.
Cette question a été indirectement abordée dans le point « A quelle fréquence la sauvegarde doit-elle s’exécuter », et les réponses s’appliquent donc ici également.Si la réponse à cette question dans votre cas est “aucune”, il vous faudra vous orienter vers des solutions dites de sauvegardes en continu, tout en gardant en mémoire que ce choix n’est pas anodin en termes de performances et problématique au niveau de son implémentation.

Impossible d’être exhaustif, mais voici quelques pistes :

  • Bases de données: Certaines bases de données peuvent être sauvegardées en mode « fichier » en copiant les fichiers de la base de données, celle-ci étant soit arrêtée le temps de la sauvegarde, soit temporairement “verrouillée” (empêche les modifications). MySQL avec le moteur MyISAM peut rentrer dans ce cas de figure.
  • Pour d’autres types de bases de données, c’est impossible, et il est indispensable d’exporter les données. Par exemple, une base de donnée MySQL avec le moteur InnoDB: les données peuvent être exportées avec mysqldump, ou répliquées sur un nœud esclave (mais attention, une réplication n’est PAS une sauvegarde).

D’autres bases de données (ou services d’annuaires, index partagés, système de cache etc..) peuvent stocker en RAM les données, soit de manière permanente, soit à fin d’optimisation. Il convient d’utiliser les outils recommandés par l’éditeur afin de ne pas perdre ces données.

Oui. Des snapshots ne sont pas des sauvegardes au sens plein du terme, mais peuvent être un complément bienvenu à celles-ci.Une bonne pratique consiste à mettre en place, via le système de taches planifiées une création de snapshot à intervalle régulier.L’avantage est de permettre une restauration complète du système, en un simple clic, donc très rapidement, sans dépendre d’outils tiers.Cependant, vous n’aurez qu’un seul instantané possible par VM, il est donc important de mettre en place une sauvegarde classique pour accéder aux fonctionnalités plus avancés (historique, restauration de fichiers isolés etc….).

Cela peut être une précaution utile, mais il faut bien garder à l’esprit que:

  • Les temps de transfert via Internet sont constamment variables, et moins rapide qu’en interne sur un seul datacenter.
  • Vous aurez besoin de sécuriser les accès par IP publique (pare-feu, configurations logicielles), ou considérer la mise en place d’un VPN.
  • Vous aurez intérêt à effectuer le maximum de prétraitements sur le datacenter de production (archivage, compression, vérifications, etc.) avant l’envoi sur le datacenter distant.

Cela peut être une nécessité, par exemple pour des raisons d’ordre légal ou contractuel. En l’absence de telles obligations, il faut garder à l’esprit les contraintes liées au chiffrement :

  • Fort impact sur les performances
  • Nécessité d’une approche sécuritaire de bout en bout, d’où des procédures plus complexes à définir et à mettre en place.

Là encore, il est judicieux de procéder à des consultations en interne (au sein de votre entreprise, organisation etc…) pour déterminer le besoin exact, valider si le chiffrement des sauvegardes en fait partie. Au cours de cette étape il sera aussi recommandé de réaliser des tests et simulations en situation réelle.

Un dernier point, important : ne pas confondre le chiffrement de sauvegarde avec le stockage d’une sauvegarde sur un support lui-même chiffré.

Certaines formes de système de fichiers chiffrés se veulent être une protection physique dans le cas du vol (d’un ordinateur portable par exemple), en nécessitant l’entrée d’une clef au démarrage de l’ordinateur, permettant par la suite, une fois le système de fichier monté, de le déchiffrer. Cela implique, dans le cas d’un serveur, qu’un éventuel intrus verra les données en clair, puisqu’il le serveur sera déjà allumé lors de l’intrusion.

D’autres formes de systèmes de fichiers, par contre, opèrent sur un modèle transactionnel (à chaque action de lecture/écriture). Cela peut éventuellement convenir, mais il faudra veiller dans tous les cas à bien se renseigner.

Si les sauvegardes sont chiffrées à la source, la question ne se pose pas.

L’objectif est, bien-sûr, d’éviter autant que possible de le faire. Cependant, cela est parfois nécessaire au niveau d’un serveur ou d’un service, afin de garantir la cohérence de la sauvegarde (éviter toute modification pendant la durée de la sauvegarde).Comme vu précédemment dans le point “Est-ce que j’ai des services qui nécessitent des méthodes de sauvegarde spécifiques ?”, pour certains types de services comme les bases de données, il existe généralement des mécanismes pour effectuer des sauvegardes / exports à chaud, en bloquant uniquement les modifications ou en les mettant en file d’attente pour exécution ultérieure.Pour d’autres services, cela n’est pas possible, ou simplement peu pratique. Dans ces cas, il convient de concevoir son architecture dans un schéma de “haute disponibilité”, c’est à dire tolérante aux pannes, mais aussi aux interruptions volontaires d’une partie de l’architecture à fins de maintenance, sauvegardes, tests, …Une approche simple pour mettre en place une telle architecture est le service de Load Balancing proposé par ArubaCloud (visiter ce lien pour consulter la documentation de ce service).

Il est également possible de gérer soi-même le load balancing sur une VM dédiée à cette fonction. Mais afin d’éviter que celle-ci ne devienne un SPOF (un point de défaillance unique), celle-ci devrait être elle-même redondé, tout en déployant un mécanisme de détection de panne et de bascule. Ceci n’est pas forcément des plus simples à mettre en place de manière fiable, d’où l’intérêt du service LoadBalancing d’ ArubaCloud : tout est déjà mis en place, et redondé, il ne reste plus qu’à expliciter les serveurs impliqué et la nature du service.

Retrouvez l’intégralité de cet article et bien plus encore sur notre base de connaissances.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Copyright © 2014 Aruba.