{"id":21498,"date":"2026-09-27T22:09:37","date_gmt":"2026-09-27T14:09:37","guid":{"rendered":"https:\/\/synopower.club\/?post_type=docs&p=21498"},"modified":"2026-09-27T22:09:43","modified_gmt":"2026-09-27T14:09:43","password":"","slug":"vmm-backup-google-drive-cloud-sync","status":"publish","type":"docs","link":"https:\/\/synopower.club\/fr\/docs\/vmm-backup-google-drive-cloud-sync\/","title":{"rendered":"Sauvegarde VMM sur Google Drive\u00a0: exportation planifi\u00e9e, synchronisation cloud et script de renommage unique"},"content":{"rendered":"

Une sauvegarde VMM stock\u00e9e uniquement sur le m\u00eame NAS que la machine virtuelle n'est pas une v\u00e9ritable sauvegarde. Si ce serveur tombe en panne, les deux copies sont perdues. Ce serveur fonctionne comme une machine virtuelle invit\u00e9e Virtual DSM h\u00e9berg\u00e9e sur Synology et Virtual Machine Manager. Notre sauvegarde VMM externe est bas\u00e9e sur deux outils gratuits fournis avec DSM\u00a0: l'exportation planifi\u00e9e dans Virtual Machine Manager et la synchronisation cloud avec Google Drive. La configuration initiale a pris un apr\u00e8s-midi. D\u00e9couvrir pourquoi elle avait cess\u00e9 de fonctionner a \u00e9t\u00e9 plus long, et c'est la raison d'\u00eatre de cet article \u00ab\u00a0H\u00e9bergement NAS\u00a0: les bases\u00a0\u00bb. Vous trouverez ci-dessous la configuration fonctionnelle, le probl\u00e8me li\u00e9 au nom de fichier qui la provoque, le petit script qui le r\u00e9sout et les conclusions d'un audit de nos propres exportations.<\/p>\n\n\n\n

\n

Point SynoPower Club\u00a0:<\/strong> Chaque technicien support a une anecdote \u00e0 raconter sur le client dont les sauvegardes fonctionnaient parfaitement depuis un an sans jamais rien restaurer. Je ne m'attendais pas \u00e0 devoir en \u00e9crire une sur notre propre service. Notre t\u00e2che de sauvegarde VMM semblait parfaitement fonctionnelle dans l'interface, pourtant un serveur avait accumul\u00e9 un t\u00e9raoctet d'exportations impossibles \u00e0 nettoyer, et l'autre n'avait produit aucun fichier depuis treize jours. Rien n'\u00e9tait cach\u00e9. Tout \u00e9tait consign\u00e9 dans un journal que personne ne consulte. La r\u00e9solution du probl\u00e8me a pris une heure\u00a0; la le\u00e7on \u00e0 retenir est de v\u00e9rifier que les fichiers existent bien \u00e0 l'emplacement pr\u00e9vu, selon une planification, comme pour n'importe quelle autre t\u00e2che.<\/p>\n<\/blockquote>\n\n\n\n

Ce dont a besoin une sauvegarde VMM compl\u00e8te<\/h2>\n\n\n\n

Virtual Machine Manager vous offre trois niveaux de protection, chacun couvrant un type de panne diff\u00e9rent. Un plan de sauvegarde VMM efficace en utilise plusieurs.<\/p>\n\n\n\n

Couche<\/th>L\u00e0 o\u00f9 vit la copie<\/th>Ce contre quoi il prot\u00e8ge<\/th><\/tr><\/thead>
Instantan\u00e9s<\/td>M\u00eame volume que l'invit\u00e9<\/td>Une mauvaise mise \u00e0 jour ou une erreur dans le syst\u00e8me invit\u00e9<\/td><\/tr>
R\u00e9plication (VMM Pro)<\/td>Un autre NAS dans le cluster<\/td>Un NAS tombe en panne, mais la r\u00e9cup\u00e9ration est rapide sur l'autre h\u00f4te.<\/td><\/tr>
Exportation programm\u00e9e + synchronisation avec le cloud<\/td>Un compte cloud hors site<\/td>Perte totale du site\u00a0: incendie, vol, ransomware sur le r\u00e9seau local<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Nous dupliquons d\u00e9j\u00e0 six invit\u00e9s sur un h\u00f4te de secours, comme d\u00e9crit dans notre article sur le cluster de machines virtuelles Synology \u00e0 trois n\u0153uds<\/a>. La r\u00e9plication conserve une copie au sein du b\u00e2timent. La couche d'exportation, quant \u00e0 elle, conserve une copie en dehors de celui-ci.<\/p>\n\n\n\n

Fonctionnement de l'exportation planifi\u00e9e VMM<\/h2>\n\n\n\n

Pour une sauvegarde VMM, l'exportation planifi\u00e9e cr\u00e9e une copie compl\u00e8te de la machine virtuelle, de ses disques et de sa configuration, sous la forme d'un fichier OVA unique sur un dossier partag\u00e9. Vous choisissez le dossier de destination, le mode d'exportation (quotidien, hebdomadaire ou mensuel) et le nombre de fichiers les plus r\u00e9cents \u00e0 conserver. L'exportation s'effectue pendant que la machine virtuelle est en cours d'ex\u00e9cution.<\/p>\n\n\n\n

Deux r\u00e8gles sont faciles \u00e0 oublier. Premi\u00e8rement, l'exportation est configur\u00e9e et \u00e9crite sur l'h\u00f4te o\u00f9 se trouve la machine virtuelle invit\u00e9e. stockage<\/strong> Le syst\u00e8me est bas\u00e9 sur le NAS, et non sur l'h\u00f4te o\u00f9 il s'ex\u00e9cute. Dans un cluster, une machine virtuelle peut s'ex\u00e9cuter sur un NAS tandis que ses disques se trouvent sur un autre. De plus, Virtual Machine Manager d\u00e9sactive l'option d'exportation planifi\u00e9e sur l'h\u00f4te incorrect. Enfin, la planification utilise l'horloge de cet h\u00f4te de stockage.<\/p>\n\n\n\n

\"Param\u00e8tres
Nos param\u00e8tres d'exportation programm\u00e9e\u00a0: un dossier partag\u00e9 comme destination, quotidiennement \u00e0 8\u00a0h\u00a000, en conservant les trois fichiers les plus r\u00e9cents.<\/figcaption><\/figure>\n\n\n\n

La bo\u00eete de dialogue indique \u00e9galement l'\u00e9tat de coh\u00e9rence. Sans l'outil invit\u00e9 Synology install\u00e9 dans la machine virtuelle, les exportations sont coh\u00e9rentes en cas de plantage, c'est-\u00e0-dire que l'\u00e9tat est identique \u00e0 celui obtenu apr\u00e8s avoir d\u00e9branch\u00e9 le cordon d'alimentation. Cela convient \u00e0 la plupart des charges de travail, et l'installation de l'outil invit\u00e9 permet d'obtenir une coh\u00e9rence au niveau du syst\u00e8me de fichiers.<\/p>\n\n\n\n

Pourquoi la synchronisation cloud ignore-t-elle les fichiers de sauvegarde VMM\u00a0?<\/h2>\n\n\n\n

L'\u00e9tape suivante logique consiste \u00e0 configurer Cloud Sync pour qu'il pointe vers le dossier d'exportation et transf\u00e8re tous les fichiers vers Google Drive. C'est ce que nous avons fait, mais les fichiers de sauvegarde VMM ne sont jamais arriv\u00e9s.<\/p>\n\n\n\n

La raison tient au nom du fichier. Virtual Machine Manager nomme chaque exportation avec un horodatage contenant des deux-points\u00a0:<\/p>\n\n\n\n

exp_web-2026-09-25 10:29:51-6f713905-cee2-4647-94d5-a5ce6fbdc585.ova<\/code><\/pre>\n\n\n\n
La synchronisation cloud ne pouvait pas transf\u00e9rer ces noms vers notre Google Drive\u00a0; par cons\u00e9quent, chaque exportation restait locale. Le fichier est valide\u00a0; le probl\u00e8me vient du caract\u00e8re. Comme le format d'horodatage d'exportation ne peut pas \u00eatre modifi\u00e9 dans Virtual Machine Manager, la correction doit \u00eatre effectu\u00e9e entre l'exportation et le transfert.<\/p>\n\n\n\n
Il est int\u00e9ressant de noter que seules les exportations programm\u00e9es comportent l'horodatage. Une exportation manuelle depuis le m\u00eame menu est enregistr\u00e9e simplement sous le nom du client, par exemple\u00a0: spc_4C8G.ova<\/code>, et Cloud Sync le t\u00e9l\u00e9charge sans probl\u00e8me. C'est pourquoi un test manuel rapide peut donner l'impression que toute la cha\u00eene fonctionne correctement alors que la planification nocturne n'est jamais synchronis\u00e9e avec le cloud.<\/p>\n\n\n\n
Configurer une sauvegarde VMM sur Google Drive en 4 \u00e9tapes<\/h2>\n\n\n\n
Voici la configuration de sauvegarde VMM fonctionnelle sur chaque h\u00f4te h\u00e9bergeant des machines virtuelles. Elle n\u00e9cessite Virtual Machine Manager, la synchronisation cloud et un compte Google\u00a0; VMM Pro n'est pas requis.<\/p>\n\n\n
\n
\n\n<\/div>\n\n
\n
\n
Planifiez l'exportation<\/h3>\n
Sur le syst\u00e8me h\u00f4te h\u00e9bergeant la machine virtuelle, ouvrez Virtual Machine Manager, s\u00e9lectionnez la machine virtuelle, puis choisissez Action > Exporter > Planifi\u00e9. S\u00e9lectionnez un dossier partag\u00e9 comme destination et d\u00e9finissez la dur\u00e9e d'exportation. Laissez le param\u00e8tre de conservation au nombre de copies que vous souhaitez conserver localement.<\/p>\n<\/div>\n<\/div>\n
\n
Cr\u00e9er la t\u00e2che de synchronisation cloud<\/h3>\n
Dans Cloud Sync, connectez Google Drive et synchronisez le dossier partag\u00e9 d'exportation avec un dossier Drive. Configurez le sens de la synchronisation pour que les modifications locales soient charg\u00e9es, et cochez l'option permettant de ne pas supprimer les fichiers de destination lorsqu'ils sont supprim\u00e9s de la source si vous souhaitez que le cloud conserve les anciennes copies.<\/p>\n<\/div>\n<\/div>\n
\n
Ajoutez le script de renommage<\/h3>\n
Enregistrez le script de cet article sur le NAS et cr\u00e9ez une t\u00e2che planifi\u00e9e qui l'ex\u00e9cute en tant que superutilisateur toutes les heures. Ce script renomme les exportations termin\u00e9es en supprimant les deux-points et conserve la copie la plus r\u00e9cente pour chaque machine virtuelle.<\/p>\n<\/div>\n<\/div>\n
\n
V\u00e9rifiez le premier t\u00e9l\u00e9chargement<\/h3>\n
Apr\u00e8s la prochaine exportation, v\u00e9rifiez que le fichier renomm\u00e9 appara\u00eet bien dans le dossier d'exportation, que Cloud Sync le signale comme t\u00e9l\u00e9charg\u00e9 et que la taille du fichier dans Google Drive correspond \u00e0 celle de l'original.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n\n\n\n\n\n\n
\"Param\u00e8tres
Notre t\u00e2che de synchronisation cloud\u00a0: t\u00e9l\u00e9charger uniquement les modifications locales, avec l\u2019option coch\u00e9e pour que Google Drive conserve les exportations apr\u00e8s leur suppression par le NAS.<\/figcaption><\/figure>\n\n\n\n
Le script de renommage derri\u00e8re notre sauvegarde VMM<\/h2>\n\n\n\n
Ce script est le seul \u00e9l\u00e9ment personnalis\u00e9 de la cha\u00eene de sauvegarde VMM et il remplit deux fonctions\u00a0: il renomme chaque exportation termin\u00e9e en rempla\u00e7ant les deux-points par des tirets et ne conserve dans le dossier d'exportation que les copies les plus r\u00e9centes de chaque machine virtuelle. Il ne modifie que les fichiers inchang\u00e9s depuis quinze minutes, \u00e9vitant ainsi de renommer une exportation en cours d'\u00e9criture.<\/p>\n\n\n\n
#!\/bin\/bash # vm-export-cloud.sh - rend les exportations VMM t\u00e9l\u00e9chargeables par Cloud Sync. # # Les exportations VMM sont nomm\u00e9es " -AAAA-MM-JJ HH:MM:SS- .ova". Cloud Sync ne t\u00e9l\u00e9chargera pas les noms contenant ":", ce qui signifie \u00e9galement qu'il ne touche jamais \u00e0 une exportation en cours d'\u00e9criture. Une fois l'exportation termin\u00e9e, elle est renomm\u00e9e en rempla\u00e7ant ":" par "-" afin que Cloud Sync la prenne en charge, puis ne conserve que les exportations renomm\u00e9es les plus r\u00e9centes par machine virtuelle. (La r\u00e9tention propre \u00e0 VMM ne peut plus voir les fichiers renomm\u00e9s, la r\u00e9tention est donc effectu\u00e9e ici.) Utilisation\u00a0: 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\u00e9e 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\u00e9es\u00a0: trouver \"\u00a0$DIR\u00a0\" -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\u00e9es les plus r\u00e9centes par invit\u00e9 (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"}')"\"<\/code><\/pre>\n\n\n\n
Ex\u00e9cutez-le d'abord sans le dernier argument. Dans ce mode, il n'affiche que les \u00e9l\u00e9ments qu'il renommerait et supprimerait. Une fois le r\u00e9sultat satisfaisant, planifiez-le avec l'argument suppl\u00e9mentaire qui active son ex\u00e9cution. Notre t\u00e2che planifi\u00e9e s'ex\u00e9cute toutes les heures en tant que superutilisateur (root) avec une commande similaire \u00e0 celle-ci, une t\u00e2che par dossier d'exportation\u00a0:<\/p>\n\n\n\n
bash \/volume1\/@vm-export-cloud\/vm-export-cloud.sh "\/volume3\/VM_BK_Export" 3 --apply<\/code><\/pre>\n\n\n\n
Un effet secondaire utile de la r\u00e8gle des deux-points\u00a0: Cloud Sync ne peut pas transf\u00e9rer une exportation tant que le script ne l\u2019a pas renomm\u00e9e, et ce script ne renomme que les fichiers finalis\u00e9s. Les exportations incompl\u00e8tes ne sont jamais transf\u00e9r\u00e9es vers le cloud.<\/p>\n\n\n\n
Pourquoi le script g\u00e8re-t-il la conservation des sauvegardes VMM\u00a0?<\/h2>\n\n\n\n
Virtual Machine Manager poss\u00e8de son propre syst\u00e8me de conservation des donn\u00e9es, qui enregistre chaque exportation cr\u00e9\u00e9e. Une fois qu'un fichier est renomm\u00e9 par le script, Virtual Machine Manager ne le reconna\u00eet plus et ne le supprime jamais. La conservation est donc g\u00e9r\u00e9e par le script, qui comptabilise les copies par invit\u00e9 \u00e0 partir de l'horodatage du nom.<\/p>\n\n\n\n
C\u00f4t\u00e9 synchronisation cloud, une simple case \u00e0 cocher d\u00e9termine ce qui se passe dans Google Drive. Son libell\u00e9 est facilement mal interpr\u00e9t\u00e9\u00a0: Ne supprimez pas les fichiers du dossier de destination lorsqu'ils sont supprim\u00e9s du dossier source.<\/strong>. Si vous laissez cette option d\u00e9coch\u00e9e, Google Drive duplique le NAS et conserve les trois m\u00eames copies. Si vous la cochez, le cloud conserve toutes les exportations jamais t\u00e9l\u00e9charg\u00e9es\u00a0; c\u2019est l\u2019option la plus s\u00fbre contre les ransomwares, mais le volume de donn\u00e9es augmente jusqu\u2019\u00e0 ce que vous le supprimiez manuellement.<\/p>\n\n\n\n
Ce qu'a r\u00e9v\u00e9l\u00e9 un audit de nos propres exportations<\/h2>\n\n\n\n
Avant cette configuration, notre sauvegarde VMM fonctionnait sur les deux h\u00f4tes de production depuis environ un mois. La v\u00e9rification des fichiers, plut\u00f4t que du tableau de bord, a r\u00e9v\u00e9l\u00e9 trois pannes distinctes.<\/p>\n\n\n\n