Sauvegarde de backups Veeam sur l’espace de stockage cloud (AWS) – partie 3 sur 3

Les principes des technologies employées et la configuration de base de la Storage Gateway ont été expliqués dans les deux premières parties de ce blog. Dans la troisième et dernière partie de cette série d’article, je me tourne vers la configuration dans Veeam.

Ajout dans Veeam

J’ajoute maintenant la VTL via iSCSI sur le futur serveur de bande Veeam.

A présent, je vois le MediaChanger et plusieurs Tape Drives. Je peux maintenant les connecter.

Dans le Device Manager, je dois encore charger les pilotes pour le Changer et les Drives. Les Tape Drives s’affichent maintenant :

Si ce n’est pas le cas, vous devez charger le pilote LTO 5 par défaut.

Pour le Medium Changer, j’utilise le “Sony TSL-A500C Autoloader” dans Veeam.

Dans Veeam 9.5, j’ajoute maintenant le serveur de bande auquel nous avions auparavant joint la bibliothèque iSCSI.

Je clique sur les autres fenêtres sans les modifier.

Je vois maintenant la bibliothèque et les bandes dans Veeam. Si vous vous demandez pourquoi il y en a trois tout d’un coup: c’est parce que j’en ai rajouté une après.

Avant de commencer les sauvegardes, je vais encore dans les options du Changer.

Je sélectionne “Use nativ SCSI command instead of Windows driver” :

Je crée maintenant un pool de médias dans Veeam. Un pool de médias GFS dans Veeam enregistre les données sur la bande selon le principe grand-père – père – fils.

Pour mon test, je laisse tous les réglages sur le standard. Je ne sélectionne que la VTL AWS que j’avais créée auparavant. Je définis ici que les bandes sont ajoutées automatiquement par Free Pool si la sauvegarde en requiert de nouvelles.

Je laisse les temps de rétention sur les valeurs standard car ils ne servent qu’à des fins de démonstration.

Nous pouvons aussi crypter le contenu avec Veeam :

A la fin, j’obtiens encore un récapitulatif. Je le confirme avec “Finish”.

Je crée maintenant un nouveau Tape Job pour tester le tout :

Dans la première fenêtre, je définis un nom pour cette tâche. Je peux éventuellement ajouter un commentaire.

Je peux maintenant définir la source des données qui doivent être écrites sur la bande. Je choisis une tâche de sauvegarde.

Ici, je définis le pool de média à utiliser pour le Full Backup. Je sélectionne le “GFSPool1” créé auparavant.

Si je veux être sûr pour le cloud AWS, je dois d’abord bien réfléchir au moment de l’«éjection» des médias, car cette action peut provoquer un passage de S3 à Glacier. Cela prolongerait énormément les temps de récupération.

Pour nos besoins, je laisse le “Scheduling” dans l’état proposé par le fabricant :

Je lance la tâche en cochant “Run the job when I click Finish” et en confirmant :

Ici, la vitesse est lente parce que la connexion à la passerelle locale se fait à travers une section LAN à 1 Gbit déjà sollicitée. Au moment de la sauvegarde, la ligne est entièrement utilisée.

Dès que le disque cache est épuisé et que trop de données sont en suspens pour le téléversement vers S3 d’AWS, le transfert de données de Veeam vers l’appareil de stockage est gelé. Cela se reflète dans le diagramme suivant :

C’est le moment de se souvenir de la taille de notre disque cache: 20 Go. On voit ici toute l’importance d’une bonne définition du disque :