VMM-back-up naar Google Drive: geplande export, cloudsynchronisatie en één hernoemingsscript

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ën 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.

SynoPower Club-punt: 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 één 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.

Wat een complete VMM-back-up nodig heeft #

Virtual Machine Manager biedt drie beschermingslagen, die elk een andere vorm van storing dekken. Een degelijk VMM-back-upplan maakt gebruik van meer dan één beschermingslaag.

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

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

Hoe werkt de geplande exportfunctie van VMM? #

Bij een VMM-back-up schrijft de geplande exportfunctie een volledige kopie van het gastbesturingssysteem, inclusief schijven en configuratie, als één 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.

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 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.

Het dialoogvenster toont ook de consistente status. Zonder de Synology Guest Tool geïnstalleerd 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.

Waarom Cloud Sync VMM-back-upbestanden overslaat #

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.

De reden is de bestandsnaam. Virtual Machine Manager geeft elke export een naam met een tijdstempel dat dubbele punten bevat:

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

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.

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, 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.

Een VMM-back-up naar Google Drive instellen in 4 stappen #

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.

Het hernoemingsscript achter onze VMM-back-up #

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ën 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.

#!/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"}')""

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, één taak per exportmap:

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

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.

Waarom het script de retentie van VMM-backups afhandelt #

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ën per gast telt vanaf het tijdstempel in de bestandsnaam.

Aan de kant van Cloud Sync bepaalt één 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.. Als je deze optie niet aanvinkt, spiegelt Google Drive de NAS en bewaart dezelfde drie kopieën. Vink je de optie aan, dan bewaart de cloud elke export die ooit is geüpload. Dit is de veiligere optie tegen ransomware, maar de cloud groeit wel totdat je de bestanden handmatig verwijdert.

Wat een audit van onze eigen export aan het licht bracht. #

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.

• De retentie is op één host stilletjes verbroken. De kleine database die Virtual Machine Manager gebruikt om exports bij te houden, kon niet in de exportmap worden aangemaakt. Daardoor werd bij elke uitvoering een foutmelding geregistreerd en werden oude exports nooit verwijderd. Eén host verzamelde een terabyte aan OVA-bestanden en bereikte een volle capaciteit van 97%.
• De grootste gast stopte met exporteren. De export van 84 GB paste niet meer in de beschikbare ruimte, waardoor het drie dagen achter elkaar mislukte zonder dat we daar een melding van kregen.
• Drie schema's die nergens heen leiden. Door een wijziging in de instellingen hadden drie exportschema's een lege bestemming. Vanaf die dag registreerden ze elke minuut een ongeldige sharenaam, meer dan 20.000 keer, en exporteerden ze niets, inclusief het schema voor deze winkel.

Dit alles gaf bij normaal gebruik geen aanleiding tot een VMM-back-upfout. De virtuele machines draaiden, de store verwerkte bestellingen en de replicatie zorgde voor een kopie op de standby-host. De exportlaag, de enige kopie op een externe locatie, was simpelweg gestopt. We controleren nu de exportmappen en de Cloud Sync-uploadlijst na elke wijziging in een schema.

Bandbreedte- en opslagplanning voor een VMM-back-up #

Elke VMM-back-upexport is een volledige kopie, geen incrementele kopie, dus bepaal de grootte ervan voordat u een schema kiest. Onze gasten variëren van een kleine website van 5 GB tot een partnerwebsite van 84 GB, en de eigen export van deze winkel is ongeveer 7 GB. Met een dagelijks schema worden er voor alle gasten samen ruim 100 GB per dag geüpload.

Google Drive staat elke gebruiker toe om 750 GB per 24 uur te uploaden, met bestanden tot 5 TB, dus de limiet is zelden het probleem. Uploadtijd en cloudopslag zijn dat wel. Het bewaren van drie kopieën van elke gast in de cloud vereist drie keer de dagelijkse totale Drive-ruimte, en meer als de cloud elke kopie bewaart. Voor grote, langzaam veranderende gasten is een wekelijkse export vaak voldoende, vooral wanneer replicatie al zorgt voor dagelijks herstel.

Waarom we back-ups maken met Synology-tools #

Alles in deze VMM-back-upketen wordt geleverd met DSM. Virtual Machine Manager exporteert de virtuele machines, Cloud Sync uploadt ze, Taakplanner voert het script uit en dezelfde NAS-eenheden slaan onze bestanden op en beheren de opslag. Er is geen back-upagent nodig per virtuele machine en er is geen aparte back-upserver die onderhouden hoeft te worden.

De onderdelen waar we wel voor betalen, zijn de onderdelen die extra bescherming bieden tussen hosts: een VMM Pro-licentie voor replicatie naar de standby-server, en Virtual DSM-licenties voor de extra DSM-gasten. Als u twijfelt welke editie u nodig heeft, onze Vergelijking tussen Virtual Machine Manager en VMM Pro Het dekt het.

Beperkingen en aandachtspunten bij VMM-back-ups #

Een export is een volledige kopie van een momentopname. Zonder de Guest Tool is de back-up crashbestendig, waardoor databases in de virtuele machine op dezelfde manier worden hersteld als na een stroomstoring. Test het herstel van uw belangrijkste virtuele machine minstens één keer.

Het herstellen van een VMM-back-up vanuit de cloud betekent dat het hele bestand eerst gedownload moet worden. Een export van 84 GB duurt uren op een doorsnee kantoorverbinding, dus de cloudkopie is bedoeld voor noodgevallen, niet voor alledaagse fouten. Snapshots en replicatie verwerken die veel sneller.

Cloud Sync kan bestanden versleutelen voordat ze worden geüpload. We raden aan deze functie in te schakelen voor gasten die klantgegevens bewaren. Bewaar het versleutelingswachtwoord op een plek die niet afhankelijk is van de NAS die u beveiligt.

Tot slot is het hernoemingsscript afhankelijk van het formaat van de exportnamen. Als een toekomstige Virtual Machine Manager-update dit formaat wijzigt, zal het script geen bestanden meer herkennen. De testmodus is de snelste manier om te controleren of uw exports na een update nog steeds worden herkend.

Veelgestelde vragen #

Referenties en video-rondleidingen #

• Virtuele machine in Virtual Machine Manager, het kenniscentrumartikel dat over exporteren gaat.
• Hulp bij Cloud Sync, inclusief synchronisatierichting en taakinstellingen.
• Opslag- en uploadlimieten van Google Drive, met een dagelijkse uploadlimiet van 750 GB.
• Synology VMM whitepaper, over gegevensbeschermingslagen voor virtuele machines.
• Taakplanner in DSM, om het hernoemingsscript als een geplande taak uit te voeren.

Video's over de tools in deze reeks: Cloud Sync en het exporteren en migreren van virtuele machines op een Synology NAS.

Wil je naast je externe kopie ook replicatie tussen hosts toevoegen? Schaf een VMM Pro-licentie, Of lees hoe de rest van deze site werkt in onze NAS Hosting 101-serie.