[TIPS & TRICKS] L’intégration de la technologie Avamar à l’interface RG System

backup avamar

Que vous soyez en phase de découverte du marché de la sauvegarde ou utilisateur aguerri de la technologie Avamar et/ou de la solution RG System, cet article vous permettra à la fois de reprendre les basics, et de bien appréhender tous les mécanismes de notre module Data Backup & Recovery. 

1. Un peu d’histoire

Au commencement était Avamar. Beaucoup vantaient, à juste titre, les performances exceptionnelles de cette solution de backup. Mais la bête n’était pas facile à dompter, et nombreux étaient ceux qui, après s’y être confrontés, ne voulaient plus en entendre parler. Avamar souffrait d’une mauvaise réputation, principalement à cause de son interface graphique vieillissante, lente et peu ergonomique.

De son côté, RG System, éditeur historique d’une solution de Remote Monitoring & Management, souhaitait intégrer un nouveau module de backup à son offre pour augmenter la satisfaction de ses clients. Avamar proposait une solution de pilotage en REST API, ce qui permettait idéalement d’utiliser la puissance de sa technologie en remplaçant intégralement l’interface graphique tant décriée. L’étude de la solution commença fin 2015 et en septembre 2016 sortait la première version du module Data Backup & Restore, mise en production en direct devant un parterre de fans ébahis.

Cette première version, assez limitée, continua son évolution et la continue encore, pour devenir, dans un avenir proche, la solution de backup unique, une solution pour les backuper tous et dans le cloud les conserver.  

2. Un peu de pub

Utiliser le module de backup RG System offre plusieurs avantages par rapport à Avamar natif.

Le premier, et le plus visible, est l’interface graphique. RG System a fait le choix, dès le départ, de la simplicité. Quand on définit une politique de backup, on définit au même endroit quoi sauvegarder, quand et pendant combien de temps, grâce à un wizard simple, élégant, efficace. Alors oui, les puristes d’Avamar rétorqueront qu’avec RG on ne peut pas utiliser le même objet de rétention pour plusieurs machines qui n’auraient pas le même objet dataset mais en partie le même objet schedule. C’est vrai, et c’est assumé. En simplifiant les possibilités on simplifie l’interface, on couvre quand même l’essentiel des besoins et on évite des maux de têtes à tout le monde.

Le second avantage qu’offre RG System est la possibilité de mutualiser facilement un environnement Avamar pour plusieurs clients. Ils peuvent être rattachés au même serveur Avamar, mais chacun est autonome pour définir ses backups, faire ses restaurations et ne voit que sa propre activité. RG définit également un modèle permettant d’estimer la consommation de chaque client sur l’environnement mutualisé, utilisé pour la facturation. Enfin, RG vous permet une certaine souplesse dans votre infrastructure Avamar, en autorisant de basculer un client d’un environnement à un autre, ce qui peut être utile si vous avez, par exemple, sous-dimensionné votre serveur Avamar.

Le troisième avantage du module backup RG System se trouve dans le cœur de métier de l’éditeur : la supervision. Le module de backup est, comme d’autres produits de sauvegarde, relié au système de management de tickets de RG. Vous pourrez ainsi configurer des alertes sur les backups en échec, incomplètes, trop anciennes ou de trop grande taille. Vous pourrez visualiser ces incidents dans le Dashboard RG, et être prévenu de leur évolution par mail et par sms. 

3. Un peu de vocabulaire

Nous tenterons d’expliquer brièvement ici les principales notions qui composent le module de backup. Les notions les plus complexes feront l’objet d’un billet de blog complet.

Pour les lecteurs qui connaîtraient déjà le logiciel Avamar, nous expliquerons également les mécaniques Avamar sous-jacentes aux différentes notions RG. 

3.1 Politique

La politique de backup est l’élément central du module de sauvegarde RG. Elle permet de définir quelles sont les données à sauvegarder, quand les sauvegarder, où les sauvegarder, pendant combien de temps, avec quelles options etc. Les politiques peuvent être définies directement sur les agents RG, ou sur les nœuds pour regrouper plusieurs agents dans une même politique.

Côté Avamar : une politique RG correspond à une politique Avamar (ou un groupe Avamar).

wizard-backup-rgsystem.jpg

 

3.2 Restauration

La restauration est l’opération permettant de récupérer une partie ou l’intégralité d’une sauvegarde. Vous pouvez accéder à l’interface de restauration à partir de la page backup. En fonction du plugin utilisé pour la sauvegarde (cf. 3.3), différentes options de restauration seront proposées.

Côté Avamar : le processus de restauration RG est assez semblable à celui d’Avamar

restore-backup-rgsystem.png

3.3 Plugins

Un plugin de politique de backup correspond au type de données sauvegardées dans cette politique. Chaque politique RG a obligatoirement un et un seul plugin. Si vous voulez sauvegarder plusieurs types de données sur un même agent, vous devez utiliser plusieurs politiques.

Les différents plugins disponibles à ce jour dans RG sont les suivants :

Fichier
Le plugin fichier vous permet de sauvegarder des fichiers et dossiers avec la possibilité d’exclure certains fichiers, dossiers et types de fichiers (par exemple : *.rar). Il est disponible sur Windows ou Linux.
Côté Avamar : le plugin Fichier RG correspond à une combinaison du plugin Avamar Windows File System et du plugin Avamar Linux File System.

Microsoft SQL
Le plugin Microsoft SQL permet de sauvegarder des bases Microsoft SQL. Vous pouvez sélectionner quelles bases/instances vous voulez sauvegarder. Vous pouvez restaurer une seule base ou une instance complète, soit en écrasant la base courante, soit dans un fichier externe pour réimporter les données dans un second temps.
Côté Avamar : le plugin Microsoft SQL correspond au plugin Avamar Windows SQL

3.4 Environnements

L’environnement de backup est l’endroit où les données sont sauvegardées. 

grid-small.png

Cette icône correspond à une sous portion d’un environnement mutualisé.

3.5 Taille des données sauvegardées

La notion de taille totale des données sauvegardée sur un environnement est complexe, et sujette à beaucoup d’incompréhensions. Quand un client achète, disons 1To de backup, il s’attend généralement à pouvoir sauvegarder 1To de données présent sur ses différentes machines. Mais il voudra probablement garder plusieurs versions des sauvegardes, disons pour l’exemple une par jour pendant 4 jours. Il ne pourrait du coup sauvegarder que 250Go de données (1To / 4). Cela dit, les données changent généralement assez peu d’un jour à l’autre, et Avamar possède un algorithme de déduplication des données. Il y a donc fort à parier qu’il puisse sauvegarder beaucoup plus que 250Go, même avec 4 versions, peut-être 900Go par exemple.

On voit bien par cet exemple que parler, sans autres précisions, de 1To de données de backup peut prêter à confusion. Afin de clarifier notre discours quand on parle de taille de donnée de backup, nous avons distingué quatre notions:

Les données sources
Les données sources représentent la taille des données présentes sur les machines à sauvegarder, indépendamment de nombre de versions de sauvegarde à conserver (rétention), ou de déduplication. Si vous avez 5 machines avec sur chacune un répertoire à sauvegarder de 50Go, vos données sources valent 5*50 = 250Go. Si vous lancez une backup par jour sur votre parc, vos données sources seront visibles dans la page du pedigree de l’environnement (cf. 3.4), dans l’encart « Données Sauvegardées (dernières 24H) ».

Les données restaurables
Les données restaurables correspondent à la somme totale des données que vous pouvez restaurer sur votre environnement, indépendamment de la déduplication. Si vous avez par exemple 250Go de données source, avec une sauvegarde par jour et une rétention de 4 jours, vous aurez donc 4 versions de chaque sauvegarde, et donc 250*4 = 1000Go de données restaurables. Les données restaurables sont visibles dans la page du pedigree de l’environnement (cf 3.4), dans les encarts « Données du mois en cours » et « Données du mois précédent ».

Les données réellement consommées sur l’environnement physique
Les données réellement consommées sur un environnement physique correspondent à l’espace disque utilisé sur le serveur Avamar. Cette somme sera très inférieure aux données restaurables, grâce à la déduplication d’Avamar. Si le client est propriétaire de son environnement, ces données seront visibles dans la page du pedigree de l’environnement (cf 3.4), dans l’encart “Stockage”. Pour un environnement mutualisé, chaque client ne peut évidemment pas voir les données réellement consommées, qui n’ont de sens que pour l’ensemble des clients présents sur l’environnement physique.

Les données facturables
La notion de données facturables est utilisée pour pouvoir facturer plusieurs clients dans le cas d’un environnement physique mutualisé en plusieurs environnements virtuels. En effet, aucune des trois notions précédentes ne permet de facturer efficacement les clients en fonction de leurs consommations respectives :

  • les données sources ne prennent pas en compte la rétention – ne facturer qu’en fonction des données sources serait donc très risqué, car un client avec une rétention trop importante risquerait de consommer beaucoup trop d’espace par rapport à ce qu’il paye ;
  • les données restaurables ne prennent pas en compte la déduplication – ne facturer qu’en fonction des données restaurables encouragerait donc les clients à mettre une rétention très faible, alors qu’un des atouts d’Avamar est justement la faible augmentation de la consommation réelle quand on augmente la rétention, grâce à la déduplication ;
  • les données réellement consommées sur l’environnement physique sont globales, Avamar ne permet pas de savoir quel client consomme quoi, mais seulement l’espace disque total utilisé.

RG a donc créé un modèle permettant d’estimer, pour un client, en fonction de la taille de ses backups et de sa rétention, une consommation de backup (les fameuses données facturables). Et c’est cette consommation qui est utilisé, multipliée par son prix au giga, pour le facturer. Comme les données restaurables, les données facturables sont visibles dans la page du pedigree de l’environnement (cf 3.4), dans les encarts “Données du mois en cours” et “Données du mois précédent”. Le détail du modèle de facturation fera l’objet d’un autre article de blog.

Côté Avamar : les notions de données restaurables et facturables sont propres à RG et n’ont pas d’équivalent dans Avamar.

3.6 Supervision des backups

Le monitoring des backups vous permet de surveiller si tout se passe bien dans votre environnement de backup, et d’être alerté quand ce n’est pas le cas. Quatre types d’alertes peuvent être émis :

  • sauvegarde en échec ;
  • sauvegarde incomplète ;
  • sauvegarde trop ancienne (vous pouvez paramétrer au bout de combien de temps sans nouvelle sauvegarde vous voulez être alerté) ;
  • sauvegarde trop importante (vous pouvez paramétrer au-delà de quelle taille de sauvegarde vous voulez être alerté).

Côté Avamar : le système de monitoring de backup est propre à RG System et ne s’appuie pas sur une fonctionnalité Avamar existante.

« Le meilleur des 2 mondes », c’est en conclusion ce que nous nous efforçons de conjuguer dans notre intégration continue de la technologie Avamar dans l’interface RG System. Et parce qu’un long discours ne vaudra jamais la démo, n’hésitez pas à tester la solution par vous-même, c’est gratuit pendant 30 jours !

Partagez cet article