VMM-sikkerhetskopi til Google Drive: Planlagt eksport, skysynkronisering og ett navneendringsskript

En VMM-sikkerhetskopi som bare ligger på samme NAS som den virtuelle maskinen er egentlig ikke en sikkerhetskopi. Hvis den boksen feiler, følger begge kopiene med den. Denne lagringsplassen kjører som en Virtual DSM-gjest i Synology Virtual Machine Manager, og vår eksterne VMM-sikkerhetskopi er bygget fra to gratisverktøy som følger med DSM: planlagt eksport i Virtual Machine Manager og Cloud Sync til Google Drive. Det tok en ettermiddag å sette det opp. Det tok lengre tid å finne ut hvorfor det stille hadde sluttet å virke, og det er delvis grunnen til at denne NAS Hosting 101-artikkelen finnes. Nedenfor er oppsettet som fungerer, den ene filnavn-særegenheten som ødelegger det, det lille skriptet som fikser det, og hva en revisjon av våre egne eksporter avdekket.

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

Hva en komplett VMM-sikkerhetskopi trenger #

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

Lag	Hvor kopien befinner seg	Hva den beskytter mot
Øyeblikksbilder	Samme volum som gjesten	En dårlig oppdatering eller en feil i gjesten
Replikering (VMM Pro)	En annen NAS i klyngen	En NAS-feil, med rask gjenoppretting på den andre verten
Planlagt eksport + Cloud Sync	En skykonto utenfor nettstedet	Mister hele nettstedet: brann, tyveri, ransomware på LAN-et

Vi kopierer allerede seks gjester til en reservevert, som beskrevet i vår artikkel om tre-noders Synology virtuell maskinklynge. Replikering oppbevarer en kopi i bygningen. Eksportlaget er det som oppbevarer en kopi utenfor.

Slik fungerer planlagt eksport i VMM #

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ålmappe, eksportmodus, daglig, ukentlig eller månedlig timing, og hvor mange av de nyeste filene som skal beholdes. Eksporter kjører mens gjestefilen kjører.

To regler er lette å overse. For det første konfigureres og skrives eksporten på verten der gjestens lagring liv, ikke hvor den kjører. I en klynge kan en gjest kjøre på én NAS mens diskene står på en annen, og Virtual Machine Manager gråer ut alternativet for planlagt eksport på feil vert. For det andre bruker planen klokken til den lagringsverten.

Dialogboksen viser også den konsistente tilstanden. Uten at Synology Guest Tool er installert i gjesteprogrammet, er eksportene krasjkonsistente, samme tilstand som å trekke ut strømledningen. Det er greit for de fleste arbeidsbelastninger, og installering av Guest Tool oppgraderer det til filsystemkonsistent.

Hvorfor Cloud Sync hopper over VMM-sikkerhetskopifiler #

Det åpenbare neste steget er å peke Cloud Sync mot eksportmappen og la den laste opp alt til Google Drive. Vi gjorde nettopp det, og VMM-sikkerhetskopifilene kom aldri frem.

Årsaken er filnavnet. Virtual Machine Manager navngir hver eksport med et tidsstempel som inneholder kolon:

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

Cloud Sync ville ikke laste opp disse navnene til Google Drive, så hver eksport forble lokal. Filen er gyldig; tegnet er problemet. Siden tidsstempelformatet for eksporten ikke kan endres i Virtual Machine Manager, må rettelsen skje mellom eksporten og opplastingen.

Interessant nok har bare planlagte eksporter tidsstempelet. En manuell eksport fra samme meny lagres ganske enkelt som gjestenavnet, for eksempel spc_4C8G.ova, og Cloud Sync laster den opp uten å klage. Derfor kan en rask manuell test få hele kjeden til å se fin ut, mens den nattlige timeplanen aldri når skyen.

Sette opp en VMM-sikkerhetskopi til Google Drive i fire trinn #

Dette er det fungerende VMM-sikkerhetskopioppsettet på hver vert som lagrer gjester. Det trenger Virtual Machine Manager, Cloud Sync og en Google-konto; ingen av dem trenger VMM Pro.

Navneskifteskriptet bak VMM-sikkerhetskopien vår #

Skriptet er den eneste tilpassede delen av VMM-sikkerhetskopikjeden, og det gjør 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ører bare filer som ikke har blitt endret på femten minutter, så det gir aldri nytt navn til en eksport som fortsatt skrives.

#!/bin/bash # vm-export-cloud.sh - gjør VMM-eksporter opplastbare av Cloud Sync. # # VMM navngir eksporter " -ÅÅÅÅ-MM-DD TT:MM:SS- .ova". Cloud Sync vil # ikke laste opp navn som inneholder ":", noe som også betyr at den aldri berører en eksport # som fortsatt skrives. Når en eksport er fullført, omdøpes den på # plass med ":" erstattet av "-", slik at Cloud Sync plukker den opp og beholder deretter bare de # nyeste KEEP omdøpte eksportene per gjest. (VMMs egen oppbevaring kan ikke lenger se # omdøpte filer, så oppbevaring gjøres 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ørt eksport er urørt så 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ør 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ør mv -n "$f" "$new" ferdig # 2. behold den nyeste BEHOLD omdøpte 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ør 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"}')""

Kjør den uten det siste argumentet først. I den modusen skriver den bare ut det den ville gitt nytt navn til og slettet. Når resultatet ser riktig ut, planlegg det med det ekstra argumentet som får det til å fungere. Oppgaveplanleggerjobben vår kjører hver time som root med en kommando som denne, én jobb per eksportmappe:

bash /volum1/@vm-export-cloud/vm-export-cloud.sh "/volum3/VM_BK_Eksport" 3 --bruk

En nyttig bivirkning av kolonregelen: Cloud Sync kan ikke laste opp en eksport før skriptet har gitt den nytt navn, og skriptet gir bare nytt navn til ferdige filer. Halvskrevne eksporter når aldri skyen.

Hvorfor skriptet håndterer VMM-sikkerhetskopioppbevaring #

Virtual Machine Manager har sin egen oppbevaringsinnstilling, og den fungerer ved å registrere hver eksport den oppretter. Når skriptet endrer navn på en fil, gjenkjenner ikke Virtual Machine Manager den lenger og vil aldri slette den. Så oppbevaringen flyttes til skriptet, som teller kopier per gjest fra tidsstempelet i navnet.

På Cloud Sync-siden bestemmer én avmerkingsboks hva som skjer i Google Drive. Ordlyden er lett å misforstå: Ikke fjern filer i målmappen når de er fjernet i kildemappen. Hvis du lar den være 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ærer det manuelt.

Hva en revisjon av vår egen eksport fant #

Før dette oppsettet hadde VMM-sikkerhetskopien vår kjørt på begge produksjonsvertene i omtrent en måned. Å sjekke filene i stedet for dashbordet avdekket tre separate feil.

• Oppbevaring avbrutt stille på én vert. Den lille databasen Virtual Machine Manager bruker til å spore eksporter kunne ikke opprettes i eksportmappen, så hver kjøring logget en feil, og ingen gammel eksport ble noen gang slettet. Én vert stablet opp en terabyte med OVA-filer og nådde 97% full.
• Den største gjesten sluttet å eksportere. Dens 84 GB-eksport fikk ikke lenger plass på den gjenværende plassen, så den feilet tre dager på rad uten at vi la merke til noen advarsel.
• Tre tidsplaner peker ingen vei. En endring i innstillingene etterlot tre eksportplaner med et tomt mål. Fra den dagen av logget de et ugyldig delingsnavn hvert minutt, over 20 000 ganger, og eksporterte ingenting, inkludert planen for denne butikken.

Ingenting av dette viste seg som en VMM-sikkerhetskopifeil ved normal bruk. Gjestene kjørte, butikken tok imot bestillinger, og replikeringen beholdt en kopi på standby-verten. Eksportlaget, den eneste kopien utenfor nettstedet, hadde rett og slett stoppet. Vi sjekker nå eksportmappene og Cloud Sync-opplastingslisten etter hver endring i en tidsplan.

Båndbredde- og lagringsplanlegging for en VMM-sikkerhetskopi #

Hver VMM-sikkerhetskopieksport er en fullstendig kopi, ikke et inkrement, så sørg for at de er store før du velger en tidsplan. Gjestene våre varierer fra et lite nettsted på 5 GB til et partnernettsted på 84 GB, og denne butikkens egen eksport er på omtrent 7 GB. For alle gjester laster en daglig tidsplan opp godt over 100 GB per dag.

Google Drive lar hver bruker laste opp 750 GB i løpet av 24 timer, med filer opptil 5 TB, så grensen er sjelden problemet. Opplastingstid og skylagring er det. Å ha tre kopier av hver gjest i skyen krever tre ganger den daglige totalen i Drive-plass, og mer hvis skyen beholder hver kopi. For store gjester som endrer seg sakte er en ukentlig eksport ofte nok, spesielt når replikering allerede dekker daglig gjenoppretting.

Hvorfor vi bygger sikkerhetskopier på Synology-verktøy #

Alt i denne VMM-sikkerhetskopikjeden leveres med DSM. Virtual Machine Manager eksporterer gjestene, Cloud Sync laster dem opp, Task Scheduler kjører skriptet, og de samme NAS-enhetene lagrer filene våre og kjører lagringen. Det er ingen sikkerhetskopieringsagent å lisensiere per gjest og ingen separat sikkerhetskopieringsserver å vedlikeholde.

De delene vi betaler for er de som gir beskyttelse mellom verter: a VMM Pro-lisens for replikering til standby-systemet, og Virtual DSM-lisenser for de ekstra DSM-gjestene. Hvis du bestemmer deg for hvilken utgave du trenger, kan du bruke vår Virtual Machine Manager vs. VMM Pro sammenligning dekker det.

VMM-sikkerhetskopieringsgrenser og forbehold #

En eksport er en fullstendig kopi på et gitt tidspunkt. Uten gjesteverktøyet er det krasjkonsistent, slik at databasene i gjesteverktøyet gjenopprettes slik de ville gjort etter et strømbrudd. Test en gjenoppretting av den viktigste gjesten minst én gang.

Å gjenopprette en VMM-sikkerhetskopi fra skyen betyr at du må laste ned hele filen først. En eksport på 84 GB tar flere timer på en typisk kontortilkobling, så skykopien er for katastrofer, ikke hverdagsfeil. Øyeblikksbilder og replikering håndterer disse mye raskere.

Cloud Sync kan kryptere filer før opplasting, og vi anbefaler å slå det på for gjester som har kundedata. Oppbevar krypteringspassordet et sted som ikke er avhengig av NAS-en du beskytter.

Til slutt avhenger skriptet for omdøping av eksportnavnformatet. Hvis en fremtidig Virtual Machine Manager-oppdatering endrer det, vil skriptet slutte å matche filer. Prøvemodus er den raskeste måten å bekrefte at det fortsatt ser eksportene dine etter en oppdatering.

Ofte stilte spørsmål #

Referanser og videogjennomganger #

• Virtuell maskin i Virtual Machine Manager, kunnskapssenterartikkelen som dekker eksport.
• Hjelp med Cloud Sync, inkludert synkroniseringsretning og oppgaveinnstillinger.
• Lagrings- og opplastingsgrenser for Google Disk, med en daglig opplastingsgrense på 750 GB.
• Synology VMM-hvitbok, om databeskyttelseslag for virtuelle maskiner.
• Oppgaveplanlegger i DSM, for å kjøre omdøpningsskriptet som en planlagt oppgave.

Videoer om verktøyene i denne kjeden: Cloud Sync, og eksport og migrering av virtuelle maskiner på en Synology NAS.

Vil du legge til replikering mellom verter i tillegg til den eksterne kopien din? Skaff deg en VMM Pro-lisens, eller les hvordan resten av dette nettstedet fungerer i vår NAS Hosting 101-serie.