{"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\/da\/docs\/vmm-backup-google-drive-cloud-sync\/","title":{"rendered":"VMM-sikkerhedskopiering til Google Drev: Planlagt eksport, cloud-synkronisering og \u00e9t omd\u00f8bningsscript"},"content":{"rendered":"

En VMM-backup, der kun ligger p\u00e5 den samme NAS som den virtuelle maskine, er ikke rigtig en backup. Hvis den boks fejler, f\u00f8lger begge kopier med. Denne lagring k\u00f8rer som en Virtual DSM-g\u00e6st i Synology Virtual Machine Manager, og vores off-site VMM-backup er bygget op fra to gratis v\u00e6rkt\u00f8jer, der f\u00f8lger med DSM: planlagt eksport i Virtual Machine Manager og Cloud Sync til Google Drive. Ops\u00e6tningen tog en eftermiddag. Det tog l\u00e6ngere tid at finde ud af, hvorfor den stille og roligt var holdt op med at virke, og den del er grunden til, at denne NAS Hosting 101-artikel findes. Nedenfor er den ops\u00e6tning, der virker, den ene filnavns-fiasko, der \u00f8del\u00e6gger den, det lille script, der l\u00f8ser det, og hvad en revision af vores egne eksporter viste.<\/p>\n\n\n\n

\n

SynoPower Club Punkt:<\/strong> Enhver supporttekniker har en historie om kunden, hvis backups k\u00f8rte gr\u00f8nt i et \u00e5r og ikke gendannede noget. Jeg havde ikke forventet at skrive en om vores egen shop. Vores VMM-backupjob s\u00e5 perfekt sundt ud i brugerfladen, men den ene v\u00e6rt havde stablet en terabyte af eksportfiler op, som den aldrig kunne rense, og den anden havde ikke produceret en eneste fil i tretten dage. Intet var skjult. Det hele var i en log, som ingen l\u00e6ser. L\u00f8sningen tog en time; lektien er at kontrollere, at filerne rent faktisk findes, hvor du tror, de er, p\u00e5 en tidsplan, ligesom ethvert andet job.<\/p>\n<\/blockquote>\n\n\n\n

Hvad en komplet VMM-sikkerhedskopiering kr\u00e6ver<\/h2>\n\n\n\n

Virtual Machine Manager giver dig tre beskyttelseslag, og hvert lag d\u00e6kker en forskellig fejl. En solid VMM-backupplan bruger mere end \u00e9t.<\/p>\n\n\n\n

Lag<\/th>Hvor kopien befinder sig<\/th>Hvad den beskytter mod<\/th><\/tr><\/thead>
Snapshots<\/td>Samme lydstyrke som g\u00e6sten<\/td>En d\u00e5rlig opdatering eller en fejl i g\u00e6sten<\/td><\/tr>
Replikering (VMM Pro)<\/td>Endnu en NAS i klyngen<\/td>En NAS-fejl, med hurtig gendannelse p\u00e5 den anden v\u00e6rt<\/td><\/tr>
Planlagt eksport + Cloud-synkronisering<\/td>En cloud-konto uden for stedet<\/td>Tab af hele webstedet: brand, tyveri, ransomware p\u00e5 LAN'et<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Vi kopierer allerede seks g\u00e6ster til en standby-v\u00e6rt, som beskrevet i vores artikel om tre-node Synology virtuel maskinklynge<\/a>. Replikering opbevarer en kopi i bygningen. Eksportlaget er det, der opbevarer en kopi uden for den.<\/p>\n\n\n\n

S\u00e5dan fungerer planlagt eksport i VMM<\/h2>\n\n\n\n

Ved en VMM-sikkerhedskopi skriver planlagt eksport en komplet kopi af en g\u00e6stefil, diske og konfiguration som en enkelt OVA-fil i en delt mappe. Du v\u00e6lger destinationsmappen, eksporttilstanden, daglig, ugentlig eller m\u00e5nedlig timing, og hvor mange af de seneste filer der skal beholdes. Eksporter k\u00f8rer, mens g\u00e6stefilen k\u00f8rer.<\/p>\n\n\n\n

To regler er lette at overse. For det f\u00f8rste konfigureres og skrives eksporten p\u00e5 den v\u00e6rt, hvor g\u00e6stens opbevaring<\/strong> liv, ikke hvor den k\u00f8rer. I en klynge kan en g\u00e6st k\u00f8re p\u00e5 \u00e9n NAS, mens dens diske sidder p\u00e5 en anden, og Virtual Machine Manager nedtones den planlagte eksportmulighed p\u00e5 den forkerte v\u00e6rt. For det andet bruger tidsplanen den p\u00e5g\u00e6ldende lagerv\u00e6rts ur.<\/p>\n\n\n\n

\"VMM-sikkerhedskopiering
Vores planlagte eksportindstillinger: en delt mappe som destination, dagligt kl. 08:00, med de tre nyeste filer.<\/figcaption><\/figure>\n\n\n\n

Dialogboksen viser ogs\u00e5 den konsistente tilstand. Uden Synology Guest Tool installeret i g\u00e6steprogrammet, er eksporten nedbrudskonsistent, samme tilstand som at tr\u00e6kke i str\u00f8mkablet. Det er fint for de fleste arbejdsbelastninger, og installation af Guest Tool opgraderer det til filsystemkonsistent.<\/p>\n\n\n\n

Hvorfor Cloud Sync springer VMM-backupfiler over<\/h2>\n\n\n\n

Det oplagte n\u00e6ste skridt er at pege Cloud Sync mod eksportmappen og lade den uploade alt til Google Drev. Det gjorde vi pr\u00e6cis, og VMM-backupfilerne ankom aldrig.<\/p>\n\n\n\n

\u00c5rsagen er filnavnet. Virtual Machine Manager navngiver hver eksport med et tidsstempel, der indeholder kolon:<\/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 ville ikke uploade disse navne til vores Google Drev, s\u00e5 hver eksport forblev lokal. Filen er gyldig; tegnet er problemet. Da eksportens tidsstempelformat ikke kan \u00e6ndres i Virtual Machine Manager, skal rettelsen ske mellem eksporten og uploaden.<\/p>\n\n\n\n
Interessant nok b\u00e6rer kun planlagte eksporter tidsstemplet. En manuel eksport fra den samme menu gemmes blot som g\u00e6stens navn, f.eks. spc_4C8G.ova<\/code>, og Cloud Sync uploader det uden klager. Derfor kan en hurtig manuel test f\u00e5 hele k\u00e6den til at se fin ud, mens den natlige tidsplan aldrig n\u00e5r skyen.<\/p>\n\n\n\n
Ops\u00e6tning af en VMM-sikkerhedskopi til Google Drev i 4 trin<\/h2>\n\n\n\n
Dette er den fungerende VMM-backupops\u00e6tning p\u00e5 hver v\u00e6rt, der gemmer g\u00e6ster. Den kr\u00e6ver Virtual Machine Manager, Cloud Sync og en Google-konto; ingen af dem kr\u00e6ver VMM Pro.<\/p>\n\n\n
\n
\n\n<\/div>\n\n
\n
\n
Planl\u00e6g eksporten<\/h3>\n
P\u00e5 den v\u00e6rt, der gemmer g\u00e6sten, skal du \u00e5bne Virtual Machine Manager, v\u00e6lge g\u00e6sten, v\u00e6lge Handling, Eksporter, Planlagt, v\u00e6lge en delt mappe som destination og indstille tidspunktet. Lad opbevaringsindstillingen v\u00e6re p\u00e5 det antal kopier, du vil beholde lokalt.<\/p>\n<\/div>\n<\/div>\n
\n
Opret Cloud Sync-opgaven<\/h3>\n
I Cloud Sync skal du forbinde Google Drive og synkronisere den eksporterede delte mappe med en Drive-mappe. Angiv retningen for upload af lokale \u00e6ndringer, og mark\u00e9r indstillingen for ikke at fjerne filer i destinationen, n\u00e5r de fjernes i kilden, hvis du vil have, at skyen beholder \u00e6ldre kopier.<\/p>\n<\/div>\n<\/div>\n
\n
Tilf\u00f8j omd\u00f8bningsscriptet<\/h3>\n
Gem scriptet fra denne artikel p\u00e5 NAS'en, og opret et Task Scheduler-job, der k\u00f8rer det som root hver time. Det omd\u00f8ber f\u00e6rdige eksporter uden kolon og gemmer de nyeste kopier pr. g\u00e6st.<\/p>\n<\/div>\n<\/div>\n
\n
Bekr\u00e6ft den f\u00f8rste upload<\/h3>\n
Efter den n\u00e6ste eksport skal du bekr\u00e6fte, at den omd\u00f8bte fil vises i eksportmappen, at Cloud Sync rapporterer den som uploadet, og at filst\u00f8rrelsen i Google Drev matcher originalen.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n\n\n\n\n\n\n
\"Opgaveindstillinger
Vores Cloud Sync-opgave: upload kun lokale \u00e6ndringer, med indstillingen markeret, s\u00e5 Google Drive gemmer eksporterede filer, efter NAS'en har besk\u00e5ret dem.<\/figcaption><\/figure>\n\n\n\n
Omd\u00f8bningsscriptet bag vores VMM-sikkerhedskopi<\/h2>\n\n\n\n
Scriptet er det eneste brugerdefinerede element i VMM-backupk\u00e6den, og det g\u00f8r to ting. Det omd\u00f8ber hver f\u00e6rdig eksport, erstatter kolon med bindestreger, og det gemmer kun de nyeste kopier af hver g\u00e6st i eksportmappen. Det ber\u00f8rer kun filer, der ikke er \u00e6ndret i femten minutter, s\u00e5 det omd\u00f8ber aldrig en eksport, der stadig skrives.<\/p>\n\n\n\n
#!\/bin\/bash # vm-export-cloud.sh - g\u00f8r VMM-eksporter uploadesbare via Cloud Sync. # # VMM navngiver eksporter " -\u00c5\u00c5\u00c5\u00c5-MM-DD TT:MM:SS- .ova". Cloud Sync uploader ikke navne, der indeholder ":", hvilket ogs\u00e5 betyder, at den aldrig r\u00f8rer en eksport #, der stadig skrives. N\u00e5r en eksport er f\u00e6rdig, omd\u00f8bes den p\u00e5 # stedet med ":" erstattet af "-", s\u00e5 Cloud Sync henter den og beholder derefter kun de # nyeste KEEP omd\u00f8bte eksporter pr. g\u00e6st. (VMM's egen opbevaring kan ikke l\u00e6ngere se # omd\u00f8bte filer, s\u00e5 opbevaring udf\u00f8res her.) # # Brug: vm-export-cloud.sh EXPORT_DIR KEEP [--apply] # Uden --apply udskriver den kun det, den ville g\u00f8re. set -u DIR=${1:?EXPORT_DIR}; KEEP=${2:?KEEP}; APPLY=${3:-} MIN_AGE_MIN=15 # en f\u00e6rdig eksport er ur\u00f8rt i s\u00e5 lang tid LOG="$(mappenavn "$(l\u00e6selink -f "$0")")\/vm-export-cloud.log" siger() { echo "$(dato '+%F %T') $*"; [ "$APPLY" = "--anvend" ] && echo "$(dato '+%F %T') $*" >> "$LOG"; } k\u00f8re() { hvis [ "$APPLY" = "--anvend" ]; derefter "$@"; ellers echo "(test) $*"; fi; } [ -d "$DIR" ] || { siger "FEJL eksportmappe mangler: $DIR"; exit 1; } # 1. omd\u00f8b f\u00e6rdige eksporter 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" done # 2. behold den nyeste BEHOLD omd\u00f8bte eksporter pr. g\u00e6st (tidsstemplet er i navnet) { 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' | sorter -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 sig "slet (ud over nyeste $KEEP): $old" run rm -f -- "$DIR\/$old" done sig "done: $(find "$DIR" -maxdepth 1 -name '*.ova' | wc -l) exports in $DIR, $(df -h "$DIR" | awk 'NR==2{print $4" free"}')"\"<\/code><\/pre>\n\n\n\n
K\u00f8r den uden det sidste argument f\u00f8rst. I den tilstand udskriver den kun det, den ville omd\u00f8be og slette. N\u00e5r outputtet ser korrekt ud, skal du planl\u00e6gge det med det ekstra argument, der f\u00e5r det til at fungere. Vores Task Scheduler-job k\u00f8rer hver time som root med en kommando som denne, \u00e9t job pr. eksportmappe:<\/p>\n\n\n\n
bash \/volume1\/@vm-export-cloud\/vm-export-cloud.sh "\/volume3\/VM_BK_Export" 3 --anvend<\/code><\/pre>\n\n\n\n
En nyttig bivirkning af kolonreglen: Cloud Sync kan ikke uploade en eksport, f\u00f8r scriptet har omd\u00f8bt den, og scriptet omd\u00f8ber kun f\u00e6rdige filer. Halvskrevne eksporter n\u00e5r aldrig skyen.<\/p>\n\n\n\n
Hvorfor scriptet h\u00e5ndterer VMM-sikkerhedskopiopbevaring<\/h2>\n\n\n\n
Virtual Machine Manager har sin egen opbevaringsindstilling, og den fungerer ved at registrere hver eksport, den opretter. N\u00e5r scriptet omd\u00f8ber en fil, genkender Virtual Machine Manager den ikke l\u00e6ngere og sletter den aldrig. S\u00e5 opbevaringen flyttes til scriptet, som t\u00e6ller kopier pr. g\u00e6st ud fra tidsstemplet i navnet.<\/p>\n\n\n\n
P\u00e5 Cloud Sync-siden bestemmer \u00e9t afkrydsningsfelt, hvad der sker i Google Drev. Ordlyden er let at misforst\u00e5: Fjern ikke filer i destinationsmappen, n\u00e5r de er fjernet i kildemappen.<\/strong>. Hvis du ikke markerer den, spejler Google Drive NAS'en og beholder de samme tre kopier. Marker den, og skyen beholder alle eksporterede filer, der nogensinde er uploadet, hvilket er det sikrere valg mod ransomware, men som vokser, indtil du besk\u00e6rer dem manuelt.<\/p>\n\n\n\n
Hvad en revision af vores egen eksport viste<\/h2>\n\n\n\n
F\u00f8r denne ops\u00e6tning havde vores VMM-backup k\u00f8rt p\u00e5 begge produktionsv\u00e6rter i omkring en m\u00e5ned. Kontrol af filerne i stedet for dashboardet afsl\u00f8rede tre separate fejl.<\/p>\n\n\n\n