Outil de restauration de backups

  • Auteurs :
    • ChristopheDubreuil
  • Version : 2.0

  • Date de création :

    16/03/2012

  • Modification : Pas de modification

  • Status : En cours d'écriture

  • Relectures :

    Relu par :

  • Validation :
    Validé par :
    • Non validé
  • Destinataire :

  • Commentaires :

  • Vie du document :
    • 1.0 :

      Version initiale

      15/12/2011

images/icon.png



Fonctionnement des backups

Comme chaque serveur a une fonction particulière, il est préférable de laisser chaque serveur organiser sa propre sauvegarde. Ainsi, le serveur LDAP sauvegarde lui-même son propre annuaire, le serveur LAMP sauvegarde la base MySQL, les fichiers servis par le serveur apache,....

Chaque machine hôte ramasse alors l'ensemble des données sauvegardées par les différents serveurs et les stocke sur le serveur de backup.

Il est relativement compliqué de donner l'accès à l'ensemble de ces données sauvegardées, et beaucoup n'ont pas forcément un intérêt direct et immédiat pour les usagers.

Par contre, il est possible de donner accès aux backups des fichiers des usagers déposés sur le contrôleur de domaine

Méthode de backup des données usagers

Il y a de multiples méthodes pour backuper des données. Nous avons utilisé différents outils depuis que nous avons commencé le projet ESCOLAN, entre autre  :

  • Bacula
  • rdiff-backup

Ancienne méthode : bacula

images/bacula.jpeg

Bacula, comme beaucoup d'autres outils de backup générant des jeux de sauvegarde a quelques inconvénients majeurs :

  • La création de plusieurs jeux de backups nécessite d'avoir un volume de stockage disponible très important, largement supérieur à la taille du backup a réaliser.
  • La restauration d'une sauvegarde n'est possible que si la base de donnée de sauvegarde est en état.
  • La reconstitution de la base de donnée en cas de problème peut être problématique, et peut entraîner la perte des données
  • La constitution de trois jeux de backups full nécessite d'avoir un volume de stockage d'environ trois fois le volume des données à sauvegardée

Du coup, les backups avec ce type d'outils sont fragiles et complexes à mettre en œuvre, et la restauration est une opération complexe, longue, et contraignante en terme d'espace de travail.

Nouvelle méthode : rdiff-backup

images/rdiff.png

Rdiff-backup maintient synchrone une copie complète de toutes les données sauvegardées. Cette copie est directement accessible sur le système de fichiers. La restauration des données de la veille est ainsi accessible sans aucune manipulation particulière, ce qui simplifie grandement la restauration des dernières données.

Lors de chaque sauvegarde, le système compare le fichier en cours de sauvegarde et celui en place sur le serveur. Si le fichier est nouveau, il l'ajoute simplement au dossier de backups. S'il a été modifié, le système prend le fichier de la veille, l'archive ( compressé ou non ) , et le remplace par la nouvelle version. L'archivage est horodaté, afin de ne pas risquer de perdre de données. Il est ainsi relativement simple de retrouver une ancienne version d'un fichier.

Le système ne nécessite pas le maintient en état d'une base de donnée externe, les backups étant systématiquement entre le fichier courant et le fichier de la veille.

Ce système de backups nécessite beaucoup moins d'espace de stockage qu'un système genre Bacula. Avec rdiff-backup, on arrive à assurer en moyenne 150 jours de backups. ( contre 3 semaine maxi avec Bacula )

accès aux backups via jbackpack

images/icon.png

Jbackpack est un outil qui permet d'attaquer les backups réalisés par avec rdiff-backup. Lors du lancement, le logiciel se constitue une base de donnée. Cette constitution est un opération d'autant plus longue qu'il y a beaucoup de backups et beaucoup de données sauvegardées.

Les différents essais fait avec jbackpack montrent qu'il est très stable sous linux, mais perfectible sous Windows. Du coup, afin de ne pas imposer l'utilisation d'un linux pour les administrateurs, nos proposons l'architecture suivante :

  • jbackpack est installé sur le serveur de backups
  • Un serveur NX tourne sur le serveur de backups

Principe

L'utilisation du serveur NX permet

  • de gérer la reprise de session ( la perte de connexion du client n'interrompt pas la tache en cours )
  • d’être indépendant du type de plateforme matérielle ( les clients existent pour Windows, mac et linux )
  • de faire fonctionner le jbackpack directement sur le serveur de backups, donc au plus près de la donnée.

Téléchargement du client NX

images/nomachine.jpg

Le client NX est téléchargeable sur le site de nomachine :

http://www.nomachine.com/download.php

Dans la partie "NX client Product", sélectionnez le client qui vous intéresse

Installation du client NX ( sous Windows )

Lancer l'exécutable téléchargé

Lancement et configuration de nx

images/10000000000002B10000018F5CCD3B16.jpg

images/10000000000001F200000177677C5912.jpg

images/10000000000001F200000177E50A403F.jpg

images/10000000000001F20000017717A00F82.jpg

images/100000000000015000000152E2BE009A.jpg

images/10000000000001F2000001772D921BCF.jpg

images/10000000000001F200000177DD1F2C1A.jpg

Une icône est alors créé sur le bureau :

images/10000000000000D60000011A73B9AB24.jpg

Mise en place d'un dossier partagé

Lorsque vous allez utiliser jbackpack, il est possible de monter dans le serveur NX un partage de votre station de travail. Ce partage peut être utilisé pour restaurer les données.

NX a la possibilité d'exporter un partage de votre station vers le serveur, afin de rendre disponible une dossier partagé dans le serveur, pour restaurer les données par exemple.

Pour cela, il faut modifier la configuration précédente, et utiliser l'onglet "service" pour donner à NX le dossier à publier.

Il faut bien entendu que le dossier en question soit partagé par la station ( le serveur utilise le partage pour y placer les données )

Configuration de Jbackpack

images/jbackpack1.jpg

Le répertoire source

C'est le répertoire d’où proviennent les données à sauvegarder, et aussi l'endroit ou elle seront restaurées. Ce partage peut être celui monté par le client NX.

Il est aussi possible de restaurer les données dans /srv/restauration, ce dernier étant ensuite accessible via SSH( WinSCP), ou via Samba.

images/jbackpack2.jpg

Il est déconseillé de restaurer dans /root, ce dossier n'ayant pas forcément assez d'espace disponible pour la restauration

Le répertoire destination

C'est le répertoire dans lequel se trouve le backup. Selon les versions des serveurs de backups, le chemin peut changer. Les chemins possibles sont :

  • /srv/archives/rdb-save/nom_de_la_machine
  • /srv/sshfs/backups/hostaRNE/nom_de_la_machine

La télégestion pourra vous aider à déterminer le bon chemin

images/jbackpack3.jpg

Si jbackpack ne trouve pas de backup dans le dossier sélectionné, il vous affiche le message suivant :

images/pas_backup.jpg

Dés que jbackpack trouve des backups dans le dossier sélectionné, il lance l'indexation.

Indexation des backups

images/database.jpg

images/indexation.jpg

L'indexation est plus ou moins longue en fonction du nombre de backups et du volume de données sauvegardées.

Pour 170 backups, compter une heure.

Lorsque l'indexation est terminée, jbackpack compresse la base de données

images/compression.jpg

L'indexation est enregistrée. Lors de la prochaine connexion, l'indexation ne scanne que les nouveaux backups effectués depuis la dernière utilisation de l'outil.

Il faut terminer en cliquant sur "select"

images/fin_destination.jpg

Exemple de restauration de données

Dans l'exemple suivant, nous allons restaurer les données d'un utilisateur :

Sélectionner la date à laquelle il faut restaurer les donnés

images/restaure0.jpg

Puis sélectionner les données à restaurer :

images/restaure1.jpg

images/restaure2.jpg

images/restaure3.jpg

images/restaure4.jpg

La restauration peut être longue ( extraction des données )

images/restaure_data1.png

images/restaure_data2.png

images/restaure_data3.png

Récupération des données restaurées

Les données restaurées sont soit directement disponibles dans le partage monté par le client NX, soit accessibles via WinSCP ou par partage Samba.

WinSCP est disponible dans le dossier "P:\Maintenance"

Le partage Samba n'est pas accessible sur tous les serveurs de données. Cela dépend de sa version


Catégorie Backups

AdminDocs: Backups/Outil de restauration de backups (last edited 24/08/2015 12:41:06 by ChloeFonck)