Sauvegarde VMM sur Google Drive : exportation planifiée, synchronisation cloud et script de renommage unique

Une sauvegarde VMM stockée uniquement sur le même NAS que la machine virtuelle n'est pas une véritable sauvegarde. Si ce serveur tombe en panne, les deux copies sont perdues. Ce serveur fonctionne comme une machine virtuelle invitée Virtual DSM hébergée sur Synology et Virtual Machine Manager. Notre sauvegarde VMM externe est basée sur deux outils gratuits fournis avec DSM : l'exportation planifiée dans Virtual Machine Manager et la synchronisation cloud avec Google Drive. La configuration initiale a pris un après-midi. Découvrir pourquoi elle avait cessé de fonctionner a été plus long, et c'est la raison d'être de cet article « Hébergement NAS : les bases ». Vous trouverez ci-dessous la configuration fonctionnelle, le problème lié au nom de fichier qui la provoque, le petit script qui le résout et les conclusions d'un audit de nos propres exportations.

Point SynoPower Club : Chaque technicien support a une anecdote à raconter sur le client dont les sauvegardes fonctionnaient parfaitement depuis un an sans jamais rien restaurer. Je ne m'attendais pas à devoir en écrire une sur notre propre service. Notre tâche de sauvegarde VMM semblait parfaitement fonctionnelle dans l'interface, pourtant un serveur avait accumulé un téraoctet d'exportations impossibles à nettoyer, et l'autre n'avait produit aucun fichier depuis treize jours. Rien n'était caché. Tout était consigné dans un journal que personne ne consulte. La résolution du problème a pris une heure ; la leçon à retenir est de vérifier que les fichiers existent bien à l'emplacement prévu, selon une planification, comme pour n'importe quelle autre tâche.

Ce dont a besoin une sauvegarde VMM complète #

Virtual Machine Manager vous offre trois niveaux de protection, chacun couvrant un type de panne différent. Un plan de sauvegarde VMM efficace en utilise plusieurs.

Couche	Là où vit la copie	Ce contre quoi il protège
Instantanés	Même volume que l'invité	Une mauvaise mise à jour ou une erreur dans le système invité
Réplication (VMM Pro)	Un autre NAS dans le cluster	Un NAS tombe en panne, mais la récupération est rapide sur l'autre hôte.
Exportation programmée + synchronisation avec le cloud	Un compte cloud hors site	Perte totale du site : incendie, vol, ransomware sur le réseau local

Nous dupliquons déjà six invités sur un hôte de secours, comme décrit dans notre article sur le cluster de machines virtuelles Synology à trois nœuds. La réplication conserve une copie au sein du bâtiment. La couche d'exportation, quant à elle, conserve une copie en dehors de celui-ci.

Fonctionnement de l'exportation planifiée VMM #

Pour une sauvegarde VMM, l'exportation planifiée crée une copie complète de la machine virtuelle, de ses disques et de sa configuration, sous la forme d'un fichier OVA unique sur un dossier partagé. Vous choisissez le dossier de destination, le mode d'exportation (quotidien, hebdomadaire ou mensuel) et le nombre de fichiers les plus récents à conserver. L'exportation s'effectue pendant que la machine virtuelle est en cours d'exécution.

Deux règles sont faciles à oublier. Premièrement, l'exportation est configurée et écrite sur l'hôte où se trouve la machine virtuelle invitée. stockage Le système est basé sur le NAS, et non sur l'hôte où il s'exécute. Dans un cluster, une machine virtuelle peut s'exécuter sur un NAS tandis que ses disques se trouvent sur un autre. De plus, Virtual Machine Manager désactive l'option d'exportation planifiée sur l'hôte incorrect. Enfin, la planification utilise l'horloge de cet hôte de stockage.

La boîte de dialogue indique également l'état de cohérence. Sans l'outil invité Synology installé dans la machine virtuelle, les exportations sont cohérentes en cas de plantage, c'est-à-dire que l'état est identique à celui obtenu après avoir débranché le cordon d'alimentation. Cela convient à la plupart des charges de travail, et l'installation de l'outil invité permet d'obtenir une cohérence au niveau du système de fichiers.

Pourquoi la synchronisation cloud ignore-t-elle les fichiers de sauvegarde VMM ? #

L'étape suivante logique consiste à configurer Cloud Sync pour qu'il pointe vers le dossier d'exportation et transfère tous les fichiers vers Google Drive. C'est ce que nous avons fait, mais les fichiers de sauvegarde VMM ne sont jamais arrivés.

La raison tient au nom du fichier. Virtual Machine Manager nomme chaque exportation avec un horodatage contenant des deux-points :

exp_web-2026-09-25 10:29:51-6f713905-cee2-4647-94d5-a5ce6fbdc585.ova

La synchronisation cloud ne pouvait pas transférer ces noms vers notre Google Drive ; par conséquent, chaque exportation restait locale. Le fichier est valide ; le problème vient du caractère. Comme le format d'horodatage d'exportation ne peut pas être modifié dans Virtual Machine Manager, la correction doit être effectuée entre l'exportation et le transfert.

Il est intéressant de noter que seules les exportations programmées comportent l'horodatage. Une exportation manuelle depuis le même menu est enregistrée simplement sous le nom du client, par exemple : spc_4C8G.ova, et Cloud Sync le télécharge sans problème. C'est pourquoi un test manuel rapide peut donner l'impression que toute la chaîne fonctionne correctement alors que la planification nocturne n'est jamais synchronisée avec le cloud.

Configurer une sauvegarde VMM sur Google Drive en 4 étapes #

Voici la configuration de sauvegarde VMM fonctionnelle sur chaque hôte hébergeant des machines virtuelles. Elle nécessite Virtual Machine Manager, la synchronisation cloud et un compte Google ; VMM Pro n'est pas requis.

Le script de renommage derrière notre sauvegarde VMM #

Ce script est le seul élément personnalisé de la chaîne de sauvegarde VMM et il remplit deux fonctions : il renomme chaque exportation terminée en remplaçant les deux-points par des tirets et ne conserve dans le dossier d'exportation que les copies les plus récentes de chaque machine virtuelle. Il ne modifie que les fichiers inchangés depuis quinze minutes, évitant ainsi de renommer une exportation en cours d'écriture.

#!/bin/bash # vm-export-cloud.sh - rend les exportations VMM téléchargeables par Cloud Sync. # # Les exportations VMM sont nommées " -AAAA-MM-JJ HH:MM:SS- .ova". Cloud Sync ne téléchargera pas les noms contenant ":", ce qui signifie également qu'il ne touche jamais à une exportation en cours d'écriture. Une fois l'exportation terminée, elle est renommée en remplaçant ":" par "-" afin que Cloud Sync la prenne en charge, puis ne conserve que les exportations renommées les plus récentes par machine virtuelle. (La rétention propre à VMM ne peut plus voir les fichiers renommés, la rétention est donc effectuée ici.) Utilisation : vm-export-cloud.sh EXPORT_DIR KEEP [--apply] Sans --apply, il affiche simplement ce qu'il ferait. set -u DIR={1:?EXPORT_DIR}; KEEP={2:?KEEP}; APPLY={3:-} MIN_AGE_MIN=15 Une exportation terminée est ce long LOG="$(dirname "$(readlink -f "$0")")/vm-export-cloud.log" say() { echo "$(date '+%F %T') $*"; [ "$APPLY" = "--apply" ] && echo "$(date '+%F %T') $*" >> "$LOG"; } run() { if [ "$APPLY" = "--apply" ]; then "$@"; else echo " (dry-run) $*"; fi; } [ -d "$DIR" ] || { say "ERREUR : dossier d'exportation manquant : $DIR"; exit 1; } # 1. Renommer les exportations terminées : trouver " $DIR " -maxdepth 1 -type f -name '*:*.ova' -mmin +$MIN_AGE_MIN -print0 | while IFS= read -r -d '' f; do if command -v fuser >/dev/null 2>&1 && fuser -s "$f" 2>/dev/null; then say "skip (in use): $(basename "$f")"; continue fi new="$DIR/$(basename "$f" | tr ':' '-')" say "rename: $(basename "$f") -> $(basename "$new")" run mv -n "$f" "$new" done # 2. Conserver les exportations renommées les plus récentes par invité (l'horodatage est dans le nom) { rechercher "$DIR" -maxdepth 1 -type f -name '*.ova' ! -name '*:*' -printf '%f\n' [ "$APPLY" = "--apply" ] || rechercher "$DIR" -maxdepth 1 -type f -name '*:*.ova' -mmin +$MIN_AGE_MIN -printf '%f\n' | tr ':' '-' } | trier -u | sed -E 's/^(.*)-([0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}-[0-9]{2}-[0-9]{2})-.*\.ova$/\1\t\2\t&/' | awk -F'\t' 'NF==3' | sort -t$'\t' -k1,1 -k2,2r | awk -F'\t' -v keep="$KEEP" '{ n[$1]++; if (n[$1] > keep) print $3 }' | while IFS= read -r old; do say "delete (beyond newest $KEEP): $old" run rm -f -- "$DIR/$old" done say "done: $(find "$DIR" -maxdepth 1 -name '*.ova' | wc -l) exporte dans $DIR, $(df -h "$DIR" | awk 'NR==2{print $4" free"}')""

Exécutez-le d'abord sans le dernier argument. Dans ce mode, il n'affiche que les éléments qu'il renommerait et supprimerait. Une fois le résultat satisfaisant, planifiez-le avec l'argument supplémentaire qui active son exécution. Notre tâche planifiée s'exécute toutes les heures en tant que superutilisateur (root) avec une commande similaire à celle-ci, une tâche par dossier d'exportation :

bash /volume1/@vm-export-cloud/vm-export-cloud.sh "/volume3/VM_BK_Export" 3 --apply

Un effet secondaire utile de la règle des deux-points : Cloud Sync ne peut pas transférer une exportation tant que le script ne l’a pas renommée, et ce script ne renomme que les fichiers finalisés. Les exportations incomplètes ne sont jamais transférées vers le cloud.

Pourquoi le script gère-t-il la conservation des sauvegardes VMM ? #

Virtual Machine Manager possède son propre système de conservation des données, qui enregistre chaque exportation créée. Une fois qu'un fichier est renommé par le script, Virtual Machine Manager ne le reconnaît plus et ne le supprime jamais. La conservation est donc gérée par le script, qui comptabilise les copies par invité à partir de l'horodatage du nom.

Côté synchronisation cloud, une simple case à cocher détermine ce qui se passe dans Google Drive. Son libellé est facilement mal interprété : Ne supprimez pas les fichiers du dossier de destination lorsqu'ils sont supprimés du dossier source.. Si vous laissez cette option décochée, Google Drive duplique le NAS et conserve les trois mêmes copies. Si vous la cochez, le cloud conserve toutes les exportations jamais téléchargées ; c’est l’option la plus sûre contre les ransomwares, mais le volume de données augmente jusqu’à ce que vous le supprimiez manuellement.

Ce qu'a révélé un audit de nos propres exportations #

Avant cette configuration, notre sauvegarde VMM fonctionnait sur les deux hôtes de production depuis environ un mois. La vérification des fichiers, plutôt que du tableau de bord, a révélé trois pannes distinctes.

• La rétention a été silencieusement interrompue sur un hôte. La petite base de données utilisée par Virtual Machine Manager pour le suivi des exportations n'a pas pu être créée dans le dossier d'exportation. Par conséquent, chaque exécution a généré une erreur et aucune ancienne exportation n'a été supprimée. Un serveur a accumulé un téraoctet de fichiers OVA et a atteint la saturation de 97%.
• Le plus gros client a cessé d'exporter. Sa capacité d'exportation de 84 Go ne tenait plus dans l'espace restant, elle a donc échoué trois jours de suite sans que nous ayons remarqué la moindre alerte.
• Trois emplois du temps qui ne mènent nulle part. Une modification des paramètres a entraîné la création de trois planifications d'exportation sans destination. Depuis lors, un nom de partage invalide est enregistré chaque minute, plus de 20 000 fois, et aucune donnée n'est exportée, y compris la planification pour ce magasin.

En utilisation normale, rien de tout cela ne se manifestait par une défaillance de la sauvegarde VMM. Les machines virtuelles fonctionnaient, la boutique prenait les commandes et la réplication conservait une copie sur l'hôte de secours. La couche d'exportation, seule copie hors site, s'était tout simplement arrêtée. Désormais, nous vérifions les dossiers d'exportation et la liste de chargement de Cloud Sync après chaque modification de planification.

Planification de la bande passante et du stockage pour une sauvegarde VMM #

Chaque sauvegarde VMM est une copie complète, et non une incrémentation. Il est donc important de bien dimensionner les sauvegardes avant de choisir une planification. Nos clients ont des sites web allant de 5 Go (petit site) à 84 Go (site partenaire). La sauvegarde de ce magasin pèse environ 7 Go. Au total, une planification quotidienne permet de transférer plus de 100 Go par jour pour l'ensemble des clients.

Google Drive permet à chaque utilisateur de transférer 750 Go en 24 heures, avec des fichiers jusqu'à 5 To. La limite est donc rarement un problème. En revanche, le temps de transfert et l'espace de stockage cloud le sont. Conserver trois copies de chaque machine virtuelle dans le cloud nécessite trois fois l'espace total quotidien disponible sur Drive, et davantage si le cloud conserve chaque copie. Pour les machines virtuelles volumineuses et peu modifiées, une exportation hebdomadaire est souvent suffisante, surtout si la réplication assure déjà la restauration quotidienne.

Pourquoi nous créons nos sauvegardes sur les outils Synology #

Dans cette chaîne de sauvegarde VMM, tous les éléments sont fournis avec DSM. Virtual Machine Manager exporte les machines virtuelles, Cloud Sync les charge, le Planificateur de tâches exécute le script, et les mêmes NAS stockent nos fichiers et gèrent le processus de sauvegarde. Aucun agent de sauvegarde n'est requis par machine virtuelle, ni serveur de sauvegarde distinct à gérer.

Les éléments que nous payons sont ceux qui ajoutent une protection entre les hôtes : un Licence VMM Pro pour la réplication vers le serveur de secours, et Licences Virtual DSM pour les invités DSM supplémentaires. Si vous hésitez sur l'édition qui vous convient, notre Comparaison Virtual Machine Manager vs VMM Pro le couvre.

Limites et mises en garde concernant la sauvegarde VMM #

Une exportation est une copie complète à un instant précis. Sans l'outil Guest, elle est cohérente en cas de panne, ce qui signifie que les bases de données de la machine virtuelle se rétablissent comme après une coupure de courant. Testez la restauration de votre machine virtuelle la plus importante au moins une fois.

Restaurer une sauvegarde VMM depuis le cloud implique de télécharger l'intégralité du fichier. Une exportation de 84 Go prend des heures avec une connexion internet standard ; la copie cloud est donc réservée aux situations critiques, et non aux erreurs courantes. Les snapshots et la réplication permettent de gérer ces situations beaucoup plus rapidement.

Cloud Sync peut chiffrer les fichiers avant leur transfert ; nous recommandons d’activer cette fonction pour les invités qui détiennent des données client. Conservez le mot de passe de chiffrement dans un endroit indépendant du NAS que vous protégez.

Enfin, le script de renommage dépend du format des noms d'exportation. Si une future mise à jour de Virtual Machine Manager modifie ce format, le script ne pourra plus identifier les fichiers. Le mode test est la méthode la plus rapide pour vérifier que vos exportations sont toujours reconnues après une mise à jour.

Questions fréquemment posées #

Références et visites guidées vidéo #

• Machine virtuelle dans Virtual Machine Manager, l'article du centre de connaissances qui traite de l'exportation.
• Aide à la synchronisation cloud, y compris la direction de synchronisation et les paramètres des tâches.
• Limites de stockage et de chargement de Google Drive, avec une limite de téléchargement quotidienne de 750 Go.
• Livre blanc Synology VMM, sur les couches de protection des données pour les machines virtuelles.
• Planificateur de tâches dans DSM, pour exécuter le script de renommage en tant que tâche planifiée.

Vidéos sur les outils de cette chaîne : Cloud Sync, et exportation et migration de machines virtuelles sur un NAS Synology.

Vous souhaitez ajouter une réplication entre hôtes en plus de votre copie hors site ? Obtenez un Licence VMM Pro, ou découvrez comment fonctionne le reste de ce site en notre série d'introduction à l'hébergement NAS.