{"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\/nb\/docs\/vmm-backup-google-drive-cloud-sync\/","title":{"rendered":"VMM-sikkerhetskopi til Google Drive: Planlagt eksport, skysynkronisering og ett navneendringsskript"},"content":{"rendered":"

En VMM-sikkerhetskopi som bare ligger p\u00e5 samme NAS som den virtuelle maskinen er egentlig ikke en sikkerhetskopi. Hvis den boksen feiler, f\u00f8lger begge kopiene med den. Denne lagringsplassen kj\u00f8rer som en Virtual DSM-gjest i Synology Virtual Machine Manager, og v\u00e5r eksterne VMM-sikkerhetskopi er bygget fra to gratisverkt\u00f8y som f\u00f8lger med DSM: planlagt eksport i Virtual Machine Manager og Cloud Sync til Google Drive. Det tok en ettermiddag \u00e5 sette det opp. Det tok lengre tid \u00e5 finne ut hvorfor det stille hadde sluttet \u00e5 virke, og det er delvis grunnen til at denne NAS Hosting 101-artikkelen finnes. Nedenfor er oppsettet som fungerer, den ene filnavn-s\u00e6regenheten som \u00f8delegger det, det lille skriptet som fikser det, og hva en revisjon av v\u00e5re egne eksporter avdekket.<\/p>\n\n\n\n

\n

SynoPower Club-punkt:<\/strong> Enhver supporttekniker har en historie om kunden hvis sikkerhetskopier gikk i vasken i et \u00e5r og ikke gjenopprettet noe. Jeg forventet ikke \u00e5 skrive en om v\u00e5r egen butikk. VMM-sikkerhetskopijobben v\u00e5r s\u00e5 helt fin ut i grensesnittet, men \u00e9n vert hadde samlet opp en terabyte med eksportfiler den aldri kunne rense, og den andre hadde ikke produsert en eneste fil p\u00e5 tretten dager. Ingenting var skjult. Alt var i en logg som ingen leser. Rettingen tok en time; l\u00e6rdommen er \u00e5 sjekke at filene faktisk finnes der du tror de er, p\u00e5 en tidsplan, som enhver annen jobb.<\/p>\n<\/blockquote>\n\n\n\n

Hva en komplett VMM-sikkerhetskopi trenger<\/h2>\n\n\n\n

Virtual Machine Manager gir deg tre lag med beskyttelse, og hvert lag dekker en annen feil. En god VMM-sikkerhetskopiplan bruker mer enn ett.<\/p>\n\n\n\n

Lag<\/th>Hvor kopien befinner seg<\/th>Hva den beskytter mot<\/th><\/tr><\/thead>
\u00d8yeblikksbilder<\/td>Samme volum som gjesten<\/td>En d\u00e5rlig oppdatering eller en feil i gjesten<\/td><\/tr>
Replikering (VMM Pro)<\/td>En annen NAS i klyngen<\/td>En NAS-feil, med rask gjenoppretting p\u00e5 den andre verten<\/td><\/tr>
Planlagt eksport + Cloud Sync<\/td>En skykonto utenfor nettstedet<\/td>Mister hele nettstedet: brann, tyveri, ransomware p\u00e5 LAN-et<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Vi kopierer allerede seks gjester til en reservevert, som beskrevet i v\u00e5r artikkel om tre-noders Synology virtuell maskinklynge<\/a>. Replikering oppbevarer en kopi i bygningen. Eksportlaget er det som oppbevarer en kopi utenfor.<\/p>\n\n\n\n

Slik fungerer planlagt eksport i VMM<\/h2>\n\n\n\n

For en VMM-sikkerhetskopi skriver planlagt eksport en komplett kopi av en gjestfil, disker og konfigurasjon, som en enkelt OVA-fil i en delt mappe. Du velger m\u00e5lmappe, eksportmodus, daglig, ukentlig eller m\u00e5nedlig timing, og hvor mange av de nyeste filene som skal beholdes. Eksporter kj\u00f8rer mens gjestefilen kj\u00f8rer.<\/p>\n\n\n\n

To regler er lette \u00e5 overse. For det f\u00f8rste konfigureres og skrives eksporten p\u00e5 verten der gjestens lagring<\/strong> liv, ikke hvor den kj\u00f8rer. I en klynge kan en gjest kj\u00f8re p\u00e5 \u00e9n NAS mens diskene st\u00e5r p\u00e5 en annen, og Virtual Machine Manager gr\u00e5er ut alternativet for planlagt eksport p\u00e5 feil vert. For det andre bruker planen klokken til den lagringsverten.<\/p>\n\n\n\n

\"Planlagte
V\u00e5re planlagte eksportinnstillinger: en delt mappe som destinasjon, daglig klokken 08:00, med beholdning av de tre nyeste filene.<\/figcaption><\/figure>\n\n\n\n

Dialogboksen viser ogs\u00e5 den konsistente tilstanden. Uten at Synology Guest Tool er installert i gjesteprogrammet, er eksportene krasjkonsistente, samme tilstand som \u00e5 trekke ut str\u00f8mledningen. Det er greit for de fleste arbeidsbelastninger, og installering av Guest Tool oppgraderer det til filsystemkonsistent.<\/p>\n\n\n\n

Hvorfor Cloud Sync hopper over VMM-sikkerhetskopifiler<\/h2>\n\n\n\n

Det \u00e5penbare neste steget er \u00e5 peke Cloud Sync mot eksportmappen og la den laste opp alt til Google Drive. Vi gjorde nettopp det, og VMM-sikkerhetskopifilene kom aldri frem.<\/p>\n\n\n\n

\u00c5rsaken er filnavnet. Virtual Machine Manager navngir hver eksport med et tidsstempel som inneholder 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 laste opp disse navnene til Google Drive, s\u00e5 hver eksport forble lokal. Filen er gyldig; tegnet er problemet. Siden tidsstempelformatet for eksporten ikke kan endres i Virtual Machine Manager, m\u00e5 rettelsen skje mellom eksporten og opplastingen.<\/p>\n\n\n\n
Interessant nok har bare planlagte eksporter tidsstempelet. En manuell eksport fra samme meny lagres ganske enkelt som gjestenavnet, for eksempel spc_4C8G.ova<\/code>, og Cloud Sync laster den opp uten \u00e5 klage. Derfor kan en rask manuell test f\u00e5 hele kjeden til \u00e5 se fin ut, mens den nattlige timeplanen aldri n\u00e5r skyen.<\/p>\n\n\n\n
Sette opp en VMM-sikkerhetskopi til Google Drive i fire trinn<\/h2>\n\n\n\n
Dette er det fungerende VMM-sikkerhetskopioppsettet p\u00e5 hver vert som lagrer gjester. Det trenger Virtual Machine Manager, Cloud Sync og en Google-konto; ingen av dem trenger VMM Pro.<\/p>\n\n\n
\n
\n\n<\/div>\n\n
\n
\n
Planlegg eksporten<\/h3>\n
P\u00e5 verten som lagrer gjesten, \u00e5pne Virtual Machine Manager, velg gjesten, velg Handling, Eksporter, Planlagt, velg en delt mappe som destinasjon og angi tidspunktet. La oppbevaringsinnstillingen v\u00e6re p\u00e5 antall kopier du vil beholde lokalt.<\/p>\n<\/div>\n<\/div>\n
\n
Opprett Cloud Sync-oppgaven<\/h3>\n
I Cloud Sync kobler du til Google Drive og synkroniserer den eksporterte delte mappen med en Drive-mappe. Angi retningen for opplasting av lokale endringer, og merk av for alternativet om ikke \u00e5 fjerne filer i destinasjonen n\u00e5r de fjernes i kilden hvis du vil at skyen skal beholde eldre kopier.<\/p>\n<\/div>\n<\/div>\n
\n
Legg til omd\u00f8pningsskriptet<\/h3>\n
Lagre skriptet fra denne artikkelen p\u00e5 NAS-en og opprett en oppgaveplanleggerjobb som kj\u00f8rer den som root hver time. Den gir nytt navn til ferdige eksporter uten kolon og beholder de nyeste kopiene per gjest.<\/p>\n<\/div>\n<\/div>\n
\n
Bekreft den f\u00f8rste opplastingen<\/h3>\n
Etter neste eksport, bekreft at den omd\u00f8pte filen vises i eksportmappen, at Cloud Sync rapporterer den som opplastet, og at filst\u00f8rrelsen i Google Drive samsvarer med originalen.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n\n\n\n\n\n\n
\"Innstillinger
V\u00e5r Cloud Sync-oppgave: last kun opp lokale endringer, med alternativet avkrysset slik at Google Drive beholder eksportene etter at NAS-en beskj\u00e6rer dem.<\/figcaption><\/figure>\n\n\n\n
Navneskifteskriptet bak VMM-sikkerhetskopien v\u00e5r<\/h2>\n\n\n\n
Skriptet er den eneste tilpassede delen av VMM-sikkerhetskopikjeden, og det gj\u00f8r to ting. Det gir nytt navn til hver ferdige eksport, erstatter kolon med bindestreker, og det beholder bare de nyeste kopiene av hver gjest i eksportmappen. Det ber\u00f8rer bare filer som ikke har blitt endret p\u00e5 femten minutter, s\u00e5 det gir aldri nytt navn til en eksport som fortsatt skrives.<\/p>\n\n\n\n
#!\/bin\/bash # vm-export-cloud.sh - gj\u00f8r VMM-eksporter opplastbare av Cloud Sync. # # VMM navngir eksporter " -\u00c5\u00c5\u00c5\u00c5-MM-DD TT:MM:SS- .ova". Cloud Sync vil # ikke laste opp navn som inneholder ":", noe som ogs\u00e5 betyr at den aldri ber\u00f8rer en eksport # som fortsatt skrives. N\u00e5r en eksport er fullf\u00f8rt, omd\u00f8pes den p\u00e5 # plass med ":" erstattet av "-", slik at Cloud Sync plukker den opp og beholder deretter bare de # nyeste KEEP omd\u00f8pte eksportene per gjest. (VMMs egen oppbevaring kan ikke lenger se # omd\u00f8pte filer, s\u00e5 oppbevaring gj\u00f8res her.) # # Bruk: vm-export-cloud.sh EXPORT_DIR KEEP [--apply] # Uten --apply skriver den bare ut det den ville gjort. set -u DIR=${1:?EXPORT_DIR}; KEEP=${2:?KEEP}; APPLY=${3:-} MIN_AGE_MIN=15 # en fullf\u00f8rt eksport er ur\u00f8rt s\u00e5 lenge LOG="$(mappenavn "$(readlink -f "$0")")\/vm-export-cloud.log" say() { echo "$(dato '+%F %T') $*"; [ "$APPLY" = "--apply" ] && echo "$(dato '+%F %T') $*" >> "$LOG"; } run() { if [ "$APPLY" = "--apply" ]; then "$@"; else echo "(test) $*"; fi; } [ -d "$DIR" ] || { say "FEIL eksportmappe mangler: $DIR"; exit 1; } # 1. gi nytt navn ferdige eksporter finn "$DIR" -maxdepth 1 -type f -name '*:*.ova' -mmin +$MIN_AGE_MIN -print0 | mens IFS= les -r -d '' f; gj\u00f8r if-kommandoen -v fuser >\/dev\/null 2>&1 && fuser -s "$f" 2>\/dev\/null; si deretter "hopp over (i bruk): $(basenavn "$f")"; fortsett fi new="$DIR\/$(basenavn "$f" | tr ':' '-')" si "gi nytt navn til: $(basenavn "$f") -> $(basenavn "$new")" kj\u00f8r mv -n "$f" "$new" ferdig # 2. behold den nyeste BEHOLD omd\u00f8pte eksporter per gjest (tidsstempelet er i navnet) { finn "$DIR" -maxdepth 1 -type f -name '*.ova' ! -name '*:*' -printf '%f\\n' [ "$APPLY" = "--apply" ] || finn "$DIR" -maxdepth 1 -type f -name '*:*.ova' -mmin +$MIN_AGE_MIN -printf '%f\\n' | tr ':' '-' } | sorter -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]++; hvis (n[$1] > keep) print $3 }' | mens IFS= les -r gammel; si "slett (utover nyeste $KEEP): 1TP18Fortalt" kj\u00f8r rm -f -- "$DIR\/1TP18Fortalt" ferdig si "ferdig: $(finn "$DIR" -maksdybde 1 -navn '*.ova' | wc -l) eksporterer i $DIR, $(df -h "$DIR" | awk 'NR==2{print $4" fri"}')"\"<\/code><\/pre>\n\n\n\n
Kj\u00f8r den uten det siste argumentet f\u00f8rst. I den modusen skriver den bare ut det den ville gitt nytt navn til og slettet. N\u00e5r resultatet ser riktig ut, planlegg det med det ekstra argumentet som f\u00e5r det til \u00e5 fungere. Oppgaveplanleggerjobben v\u00e5r kj\u00f8rer hver time som root med en kommando som denne, \u00e9n jobb per eksportmappe:<\/p>\n\n\n\n
bash \/volum1\/@vm-export-cloud\/vm-export-cloud.sh "\/volum3\/VM_BK_Eksport" 3 --bruk<\/code><\/pre>\n\n\n\n
En nyttig bivirkning av kolonregelen: Cloud Sync kan ikke laste opp en eksport f\u00f8r skriptet har gitt den nytt navn, og skriptet gir bare nytt navn til ferdige filer. Halvskrevne eksporter n\u00e5r aldri skyen.<\/p>\n\n\n\n
Hvorfor skriptet h\u00e5ndterer VMM-sikkerhetskopioppbevaring<\/h2>\n\n\n\n
Virtual Machine Manager har sin egen oppbevaringsinnstilling, og den fungerer ved \u00e5 registrere hver eksport den oppretter. N\u00e5r skriptet endrer navn p\u00e5 en fil, gjenkjenner ikke Virtual Machine Manager den lenger og vil aldri slette den. S\u00e5 oppbevaringen flyttes til skriptet, som teller kopier per gjest fra tidsstempelet i navnet.<\/p>\n\n\n\n
P\u00e5 Cloud Sync-siden bestemmer \u00e9n avmerkingsboks hva som skjer i Google Drive. Ordlyden er lett \u00e5 misforst\u00e5: Ikke fjern filer i m\u00e5lmappen n\u00e5r de er fjernet i kildemappen<\/strong>. Hvis du lar den v\u00e6re uavmerket, speiler Google Drive NAS-en og beholder de samme tre kopiene. Hvis du merker av, beholder skyen alle eksporter som noen gang er lastet opp, noe som er det tryggere valget mot ransomware, men det vokser til du beskj\u00e6rer det manuelt.<\/p>\n\n\n\n
Hva en revisjon av v\u00e5r egen eksport fant<\/h2>\n\n\n\n
F\u00f8r dette oppsettet hadde VMM-sikkerhetskopien v\u00e5r kj\u00f8rt p\u00e5 begge produksjonsvertene i omtrent en m\u00e5ned. \u00c5 sjekke filene i stedet for dashbordet avdekket tre separate feil.<\/p>\n\n\n\n