{"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\/nl\/docs\/vmm-backup-google-drive-cloud-sync\/","title":{"rendered":"VMM-back-up naar Google Drive: geplande export, cloudsynchronisatie en \u00e9\u00e9n hernoemingsscript"},"content":{"rendered":"

Een VMM-back-up die alleen op dezelfde NAS staat als de virtuele machine, is eigenlijk geen echte back-up. Als die NAS uitvalt, gaan beide kopie\u00ebn verloren. Deze opslag draait als een Virtual DSM-gast in een Synology Virtual Machine Manager-systeem, en onze externe VMM-back-up is gebouwd met twee gratis tools die standaard bij DSM worden geleverd: geplande export in Virtual Machine Manager en Cloud Sync naar Google Drive. Het instellen ervan kostte een middag. Het uitzoeken waarom het plotseling was gestopt met werken duurde langer, en dat is de reden voor dit artikel over NAS-hosting voor beginners. Hieronder staat de werkende configuratie, de ene eigenaardigheid met bestandsnamen die het laat mislukken, het kleine script dat het oplost, en wat een audit van onze eigen exports aan het licht bracht.<\/p>\n\n\n\n

\n

SynoPower Club-punt:<\/strong> Elke supportmedewerker kent wel een verhaal over een klant wiens back-ups een jaar lang groen bleven, maar uiteindelijk niets herstelden. Ik had niet verwacht dat ik er zelf zo'n verhaal over zou schrijven. Onze VMM-back-uptaak zag er in de interface perfect uit, maar \u00e9\u00e9n host had een terabyte aan exportbestanden verzameld die nooit konden worden opgeschoond, en de andere had al dertien dagen geen enkel bestand meer aangemaakt. Niets was verborgen. Het stond allemaal in een logbestand dat niemand leest. De oplossing duurde een uur; de les is: controleer of de bestanden daadwerkelijk bestaan waar je denkt dat ze staan, volgens een vast schema, net als bij elke andere taak.<\/p>\n<\/blockquote>\n\n\n\n

Wat een complete VMM-back-up nodig heeft<\/h2>\n\n\n\n

Virtual Machine Manager biedt drie beschermingslagen, die elk een andere vorm van storing dekken. Een degelijk VMM-back-upplan maakt gebruik van meer dan \u00e9\u00e9n beschermingslaag.<\/p>\n\n\n\n

Laag<\/th>Waar de kopie zich bevindt<\/th>Waar het tegen beschermt<\/th><\/tr><\/thead>
Momentopnamen<\/td>Hetzelfde volume als de gast<\/td>Een slechte update of een fout in de gastsoftware.<\/td><\/tr>
Replicatie (VMM Pro)<\/td>Nog een NAS in het cluster<\/td>Een NAS-storing, met snel herstel op de andere host.<\/td><\/tr>
Geplande export + Cloudsynchronisatie<\/td>Een cloudaccount op een externe locatie<\/td>Het hele systeem kwijtraken: brand, diefstal, ransomware op het LAN.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

We repliceren al zes gasten naar een standby-host, zoals beschreven in ons verslag over de virtuele machinecluster met drie knooppunten (Synology)<\/a>. Replicatie zorgt ervoor dat er een kopie in het gebouw blijft. De exportlaag zorgt ervoor dat er een kopie buiten het gebouw blijft.<\/p>\n\n\n\n

Hoe werkt de geplande exportfunctie van VMM?<\/h2>\n\n\n\n

Bij een VMM-back-up schrijft de geplande exportfunctie een volledige kopie van het gastbesturingssysteem, inclusief schijven en configuratie, als \u00e9\u00e9n OVA-bestand naar een gedeelde map. U kiest de bestemmingsmap, de exportmodus, de frequentie (dagelijks, wekelijks of maandelijks) en hoeveel van de meest recente bestanden u wilt bewaren. Exports worden uitgevoerd terwijl het gastbesturingssysteem actief is.<\/p>\n\n\n\n

Twee regels worden vaak over het hoofd gezien. Ten eerste wordt de export geconfigureerd en geschreven op de host waar de gast zich bevindt. opslag<\/strong> leeft, niet waar het draait. In een cluster kan een gastbesturingssysteem op de ene NAS draaien terwijl de schijven zich op een andere bevinden, en Virtual Machine Manager maakt de optie voor geplande export op de verkeerde host grijs. Ten tweede gebruikt de planning de klok van die opslaghost.<\/p>\n\n\n\n

\"Instellingen
Onze geplande exportinstellingen: een gedeelde map als bestemming, dagelijks om 08:00 uur, waarbij de drie nieuwste bestanden worden bewaard.<\/figcaption><\/figure>\n\n\n\n

Het dialoogvenster toont ook de consistente status. Zonder de Synology Guest Tool ge\u00efnstalleerd in het gastbesturingssysteem, zijn exports crash-consistent, in dezelfde toestand als wanneer de stroomkabel wordt losgekoppeld. Dat is prima voor de meeste workloads, en door de Guest Tool te installeren, wordt de status verbeterd naar bestandssysteem-consistent.<\/p>\n\n\n\n

Waarom Cloud Sync VMM-back-upbestanden overslaat<\/h2>\n\n\n\n

De voor de hand liggende volgende stap is om Cloud Sync naar de exportmap te laten verwijzen en alles naar Google Drive te laten uploaden. Dat hebben we precies gedaan, maar de VMM-back-upbestanden zijn nooit aangekomen.<\/p>\n\n\n\n

De reden is de bestandsnaam. Virtual Machine Manager geeft elke export een naam met een tijdstempel dat dubbele punten bevat:<\/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
Cloud Sync uploadde die namen niet naar onze Google Drive, waardoor elke export lokaal bleef. Het bestand is geldig; het teken is het probleem. Omdat het tijdstempelformaat van de export niet kan worden gewijzigd in Virtual Machine Manager, moet de oplossing tussen de export en de upload plaatsvinden.<\/p>\n\n\n\n
Opvallend is dat alleen geplande exports een tijdstempel bevatten. Een handmatige export vanuit hetzelfde menu wordt opgeslagen met alleen de gastnaam, bijvoorbeeld: spc_4C8G.ova<\/code>, En Cloud Sync uploadt het zonder problemen. Daarom kan een snelle handmatige test de hele keten er prima uit laten zien, terwijl het nachtelijke schema de cloud nooit bereikt.<\/p>\n\n\n\n
Een VMM-back-up naar Google Drive instellen in 4 stappen<\/h2>\n\n\n\n
Dit is de werkende VMM-back-upconfiguratie op elke host die virtuele machines opslaat. Hiervoor zijn Virtual Machine Manager, Cloud Sync en een Google-account nodig; VMM Pro is hiervoor niet vereist.<\/p>\n\n\n
\n
\n\n<\/div>\n\n
\n
\n
Plan de export<\/h3>\n
Open op de host waarop de gast is opgeslagen Virtual Machine Manager, selecteer de gast, kies Actie, Exporteren, Gepland, kies een gedeelde map als bestemming en stel de tijd in. Laat de bewaarinstelling staan op het aantal kopie\u00ebn dat u lokaal wilt bewaren.<\/p>\n<\/div>\n<\/div>\n
\n
Maak de Cloud Sync-taak aan.<\/h3>\n
Verbind Google Drive in Cloud Sync en synchroniseer de gedeelde exportmap met een Drive-map. Stel de uploadrichting in naar lokale wijzigingen en vink de optie aan om bestanden in de bestemming niet te verwijderen wanneer ze in de bron worden verwijderd, als u wilt dat de cloud oudere kopie\u00ebn bewaart.<\/p>\n<\/div>\n<\/div>\n
\n
Voeg het hernoemingsscript toe<\/h3>\n
Sla het script uit dit artikel op de NAS op en maak een taakplanner aan die het elk uur als root uitvoert. Het script hernoemt voltooide exports zonder dubbele punten en bewaart de meest recente kopie\u00ebn per gast-VM.<\/p>\n<\/div>\n<\/div>\n
\n
Controleer de eerste upload.<\/h3>\n
Controleer na de volgende export of het hernoemde bestand in de exportmap verschijnt, of Cloud Sync aangeeft dat het is ge\u00fcpload en of de bestandsgrootte in Google Drive overeenkomt met het origineel.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n\n\n\n\n\n\n
\"Instellingen
Onze taak voor cloudsynchronisatie: alleen lokale wijzigingen uploaden, met de optie aangevinkt zodat Google Drive de exportbestanden bewaart nadat de NAS ze heeft verwijderd.<\/figcaption><\/figure>\n\n\n\n
Het hernoemingsscript achter onze VMM-back-up<\/h2>\n\n\n\n
Het script is het enige aangepaste onderdeel van de VMM-backupketen en doet twee dingen. Het hernoemt elke voltooide export, waarbij dubbele punten worden vervangen door streepjes, en het bewaart alleen de meest recente kopie\u00ebn van elke virtuele machine in de exportmap. Het raakt alleen bestanden aan die de afgelopen vijftien minuten niet zijn gewijzigd, dus het hernoemt nooit een export die nog wordt geschreven.<\/p>\n\n\n\n
#!\/bin\/bash # vm-export-cloud.sh - maakt VMM-exports uploadbaar via Cloud Sync. # # VMM-namen exports " -JJJJ-MM-DD HH:MM:SS- .ova". Cloud Sync uploadt geen namen die ":" bevatten, wat ook betekent dat het nooit een export aanraakt die nog wordt geschreven. Zodra een export is voltooid, wordt deze op de plaats hernoemd met ":" vervangen door "-", zodat Cloud Sync deze oppakt en vervolgens alleen de nieuwste hernoemde exports per gast bewaart. (De eigen retentie van VMM kan hernoemde bestanden niet meer zien, dus de retentie wordt hier uitgevoerd.) Gebruik: vm-export-cloud.sh EXPORT_DIR KEEP [--apply] Zonder --apply wordt alleen afgedrukt wat het zou doen. set -u DIR={1:?EXPORT_DIR}; KEEP={2:?KEEP}; APPLY={3:-} MIN_AGE_MIN=15 voltooid export is untouched this 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 "ERROR export folder missing: $DIR"; exit 1; } # 1. Hernoem voltooide exports find "$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" voltooid # 2. behoud de nieuwste BEHOUD hernoemde exports per gast (tijdstempel staat in de naam) { find "$DIR" -maxdepth 1 -type f -name '*.ova' ! -name '*:*' -printf '%f\\n' [ "$APPLY" = "--apply" ] || find "$DIR" -maxdepth 1 -type f -name '*:*.ova' -mmin +$MIN_AGE_MIN -printf '%f\\n' | tr ':' '-' } | sort -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) exporteert in $DIR, $(df -h "$DIR" | awk 'NR==2{print $4" free"}')"\"<\/code><\/pre>\n\n\n\n
Voer het eerst uit zonder het laatste argument. In die modus wordt alleen afgedrukt wat er hernoemd en verwijderd zou worden. Zodra de uitvoer er goed uitziet, kunt u de taak plannen met het extra argument dat de actie activeert. Onze taakplanner voert elk uur een taak uit als root met een commando zoals dit, \u00e9\u00e9n taak per exportmap:<\/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
Een nuttig neveneffect van de dubbele puntregel: Cloud Sync kan een exportbestand pas uploaden nadat het script het heeft hernoemd, en het script hernoemt alleen voltooide bestanden. Half afgemaakte exportbestanden bereiken de cloud nooit.<\/p>\n\n\n\n
Waarom het script de retentie van VMM-backups afhandelt<\/h2>\n\n\n\n
Virtual Machine Manager heeft een eigen bewaarinstelling en registreert elke export die het maakt. Zodra het script een bestand hernoemt, herkent Virtual Machine Manager het niet meer en zal het nooit verwijderen. De bewaarfunctie wordt daarom overgenomen door het script, dat het aantal kopie\u00ebn per gast telt vanaf het tijdstempel in de bestandsnaam.<\/p>\n\n\n\n
Aan de kant van Cloud Sync bepaalt \u00e9\u00e9n selectievakje wat er in Google Drive gebeurt. De formulering ervan is gemakkelijk verkeerd te interpreteren: Verwijder geen bestanden in de bestemmingsmap wanneer ze in de bronmap worden verwijderd.<\/strong>. Als je deze optie niet aanvinkt, spiegelt Google Drive de NAS en bewaart dezelfde drie kopie\u00ebn. Vink je de optie aan, dan bewaart de cloud elke export die ooit is ge\u00fcpload. Dit is de veiligere optie tegen ransomware, maar de cloud groeit wel totdat je de bestanden handmatig verwijdert.<\/p>\n\n\n\n
Wat een audit van onze eigen export aan het licht bracht.<\/h2>\n\n\n\n
Voordat deze configuratie werd toegepast, draaide onze VMM-back-up al ongeveer een maand op beide productiehosts. Door de bestanden te controleren in plaats van het dashboard, werden drie afzonderlijke fouten gevonden.<\/p>\n\n\n\n