VMM-sikkerhedskopiering til Google Drev: Planlagt eksport, cloud-synkronisering og ét omdøbningsscript

En VMM-backup, der kun ligger på den samme NAS som den virtuelle maskine, er ikke rigtig en backup. Hvis den boks fejler, følger begge kopier med. Denne lagring kører som en Virtual DSM-gæst i Synology Virtual Machine Manager, og vores off-site VMM-backup er bygget op fra to gratis værktøjer, der følger med DSM: planlagt eksport i Virtual Machine Manager og Cloud Sync til Google Drive. Opsætningen tog en eftermiddag. Det tog længere 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ætning, der virker, den ene filnavns-fiasko, der ødelægger den, det lille script, der løser det, og hvad en revision af vores egne eksporter viste.

SynoPower Club Punkt: Enhver supporttekniker har en historie om kunden, hvis backups kørte grønt i et år og ikke gendannede noget. Jeg havde ikke forventet at skrive en om vores egen shop. Vores VMM-backupjob så perfekt sundt ud i brugerfladen, men den ene vært 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æser. Løsningen tog en time; lektien er at kontrollere, at filerne rent faktisk findes, hvor du tror, de er, på en tidsplan, ligesom ethvert andet job.

Hvad en komplet VMM-sikkerhedskopiering kræver #

Virtual Machine Manager giver dig tre beskyttelseslag, og hvert lag dækker en forskellig fejl. En solid VMM-backupplan bruger mere end ét.

Lag	Hvor kopien befinder sig	Hvad den beskytter mod
Snapshots	Samme lydstyrke som gæsten	En dårlig opdatering eller en fejl i gæsten
Replikering (VMM Pro)	Endnu en NAS i klyngen	En NAS-fejl, med hurtig gendannelse på den anden vært
Planlagt eksport + Cloud-synkronisering	En cloud-konto uden for stedet	Tab af hele webstedet: brand, tyveri, ransomware på LAN'et

Vi kopierer allerede seks gæster til en standby-vært, som beskrevet i vores artikel om tre-node Synology virtuel maskinklynge. Replikering opbevarer en kopi i bygningen. Eksportlaget er det, der opbevarer en kopi uden for den.

Sådan fungerer planlagt eksport i VMM #

Ved en VMM-sikkerhedskopi skriver planlagt eksport en komplet kopi af en gæstefil, diske og konfiguration som en enkelt OVA-fil i en delt mappe. Du vælger destinationsmappen, eksporttilstanden, daglig, ugentlig eller månedlig timing, og hvor mange af de seneste filer der skal beholdes. Eksporter kører, mens gæstefilen kører.

To regler er lette at overse. For det første konfigureres og skrives eksporten på den vært, hvor gæstens opbevaring liv, ikke hvor den kører. I en klynge kan en gæst køre på én NAS, mens dens diske sidder på en anden, og Virtual Machine Manager nedtones den planlagte eksportmulighed på den forkerte vært. For det andet bruger tidsplanen den pågældende lagerværts ur.

Dialogboksen viser også den konsistente tilstand. Uden Synology Guest Tool installeret i gæsteprogrammet, er eksporten nedbrudskonsistent, samme tilstand som at trække i strømkablet. Det er fint for de fleste arbejdsbelastninger, og installation af Guest Tool opgraderer det til filsystemkonsistent.

Hvorfor Cloud Sync springer VMM-backupfiler over #

Det oplagte næste skridt er at pege Cloud Sync mod eksportmappen og lade den uploade alt til Google Drev. Det gjorde vi præcis, og VMM-backupfilerne ankom aldrig.

Årsagen er filnavnet. Virtual Machine Manager navngiver hver eksport med et tidsstempel, der indeholder kolon:

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

Cloud Sync ville ikke uploade disse navne til vores Google Drev, så hver eksport forblev lokal. Filen er gyldig; tegnet er problemet. Da eksportens tidsstempelformat ikke kan ændres i Virtual Machine Manager, skal rettelsen ske mellem eksporten og uploaden.

Interessant nok bærer kun planlagte eksporter tidsstemplet. En manuel eksport fra den samme menu gemmes blot som gæstens navn, f.eks. spc_4C8G.ova, og Cloud Sync uploader det uden klager. Derfor kan en hurtig manuel test få hele kæden til at se fin ud, mens den natlige tidsplan aldrig når skyen.

Opsætning af en VMM-sikkerhedskopi til Google Drev i 4 trin #

Dette er den fungerende VMM-backupopsætning på hver vært, der gemmer gæster. Den kræver Virtual Machine Manager, Cloud Sync og en Google-konto; ingen af dem kræver VMM Pro.

Omdøbningsscriptet bag vores VMM-sikkerhedskopi #

Scriptet er det eneste brugerdefinerede element i VMM-backupkæden, og det gør to ting. Det omdøber hver færdig eksport, erstatter kolon med bindestreger, og det gemmer kun de nyeste kopier af hver gæst i eksportmappen. Det berører kun filer, der ikke er ændret i femten minutter, så det omdøber aldrig en eksport, der stadig skrives.

#!/bin/bash # vm-export-cloud.sh - gør VMM-eksporter uploadesbare via Cloud Sync. # # VMM navngiver eksporter " -ÅÅÅÅ-MM-DD TT:MM:SS- .ova". Cloud Sync uploader ikke navne, der indeholder ":", hvilket også betyder, at den aldrig rører en eksport #, der stadig skrives. Når en eksport er færdig, omdøbes den på # stedet med ":" erstattet af "-", så Cloud Sync henter den og beholder derefter kun de # nyeste KEEP omdøbte eksporter pr. gæst. (VMM's egen opbevaring kan ikke længere se # omdøbte filer, så opbevaring udføres her.) # # Brug: vm-export-cloud.sh EXPORT_DIR KEEP [--apply] # Uden --apply udskriver den kun det, den ville gøre. set -u DIR=${1:?EXPORT_DIR}; KEEP=${2:?KEEP}; APPLY=${3:-} MIN_AGE_MIN=15 # en færdig eksport er urørt i så lang tid LOG="$(mappenavn "$(læselink -f "$0")")/vm-export-cloud.log" siger() { echo "$(dato '+%F %T') $*"; [ "$APPLY" = "--anvend" ] && echo "$(dato '+%F %T') $*" >> "$LOG"; } køre() { hvis [ "$APPLY" = "--anvend" ]; derefter "$@"; ellers echo "(test) $*"; fi; } [ -d "$DIR" ] || { siger "FEJL eksportmappe mangler: $DIR"; exit 1; } # 1. omdøb færdige 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øbte eksporter pr. gæst (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"}')""

Kør den uden det sidste argument først. I den tilstand udskriver den kun det, den ville omdøbe og slette. Når outputtet ser korrekt ud, skal du planlægge det med det ekstra argument, der får det til at fungere. Vores Task Scheduler-job kører hver time som root med en kommando som denne, ét job pr. eksportmappe:

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

En nyttig bivirkning af kolonreglen: Cloud Sync kan ikke uploade en eksport, før scriptet har omdøbt den, og scriptet omdøber kun færdige filer. Halvskrevne eksporter når aldrig skyen.

Hvorfor scriptet håndterer VMM-sikkerhedskopiopbevaring #

Virtual Machine Manager har sin egen opbevaringsindstilling, og den fungerer ved at registrere hver eksport, den opretter. Når scriptet omdøber en fil, genkender Virtual Machine Manager den ikke længere og sletter den aldrig. Så opbevaringen flyttes til scriptet, som tæller kopier pr. gæst ud fra tidsstemplet i navnet.

På Cloud Sync-siden bestemmer ét afkrydsningsfelt, hvad der sker i Google Drev. Ordlyden er let at misforstå: Fjern ikke filer i destinationsmappen, når de er fjernet i kildemappen.. 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ærer dem manuelt.

Hvad en revision af vores egen eksport viste #

Før denne opsætning havde vores VMM-backup kørt på begge produktionsværter i omkring en måned. Kontrol af filerne i stedet for dashboardet afslørede tre separate fejl.

• Tilbageholdelse afbrudt lydløst på én vært. Den lille database, som Virtual Machine Manager bruger til at spore eksporter, kunne ikke oprettes i eksportmappen, så hver kørsel registrerede en fejl, og ingen gammel eksport blev nogensinde slettet. En vært stablede en terabyte af OVA-filer op og nåede 97% fuld.
• Den største gæst stoppede med at eksportere. Dens 84 GB eksport passede ikke længere på den tilbageværende plads, så den fejlede tre dage i træk uden nogen advarsel, vi bemærkede.
• Tre tidsplaner peger ingen vegne. En ændring af indstillinger efterlod tre eksportplaner med en tom destination. Fra den dag af loggede de et ugyldigt delingsnavn hvert minut, over 20.000 gange, og eksporterede ingenting, inklusive planen for dette lager.

Intet af dette viste sig som en VMM-backupfejl under normal brug. Gæsterne kørte, butikken tog imod ordrer, og replikeringen gemte en kopi på standby-værten. Eksportlaget, den eneste off-site-kopi, var simpelthen stoppet. Vi kontrollerer nu eksportmapperne og Cloud Sync-uploadlisten efter hver ændring af en tidsplan.

Båndbredde- og lagerplanlægning til en VMM-sikkerhedskopi #

Hver VMM-backupeksport er en fuld kopi, ikke en forøgelse, så sørg for at få den korrekte størrelse, før du vælger en tidsplan. Vores gæster spænder fra et lille websted på 5 GB til et partnerwebsted på 84 GB, og denne butiks egen eksport er på omkring 7 GB. På tværs af alle gæster uploader en daglig tidsplan langt over 100 GB om dagen.

Google Drive giver hver bruger mulighed for at uploade 750 GB på 24 timer, med filer på op til 5 TB, så begrænsningen er sjældent problemet. Uploadtid og cloud-lagring er det. At have tre kopier af hver gæst i skyen kræver tre gange den daglige samlede Drive-plads, og mere, hvis skyen gemmer hver kopi. For store, langsomt skiftende gæster er en ugentlig eksport ofte nok, især når replikering allerede dækker den daglige gendannelse.

Hvorfor vi bygger sikkerhedskopier på Synology-værktøjer #

Alt i denne VMM-backupkæde leveres med DSM. Virtual Machine Manager eksporterer gæsterne, Cloud Sync uploader dem, Task Scheduler kører scriptet, og de samme NAS-enheder gemmer vores filer og kører lagringen. Der er ingen backupagent at licensere pr. gæst og ingen separat backupserver at vedligeholde.

De ting, vi betaler for, er dem, der tilføjer beskyttelse mellem værter: a VMM Pro licens til replikering til standby, og Virtual DSM licenser for de ekstra DSM-gæster. Hvis du beslutter dig for, hvilken udgave du har brug for, er vores Virtual Machine Manager vs. VMM Pro sammenligning dækker det.

VMM-sikkerhedskopieringsgrænser og forbehold #

En eksport er en fuld kopi på et givet tidspunkt. Uden gæsteværktøjet er det konsekvent ved nedbrud, så databaserne i gæsteværktøjet gendannes, som de ville efter et strømafbrydelse. Test en gendannelse af din vigtigste gæst mindst én gang.

Gendannelse af en VMM-backup fra skyen betyder, at man først skal downloade hele filen. En eksport på 84 GB tager timer på en typisk kontorforbindelse, så skykopien er til katastrofer, ikke hverdagsfejl. Snapshots og replikering håndterer disse langt hurtigere.

Cloud Sync kan kryptere filer før upload, og vi anbefaler at aktivere det for gæster, der opbevarer kundedata. Opbevar krypteringsadgangskoden et sted, der ikke afhænger af den NAS, du beskytter.

Endelig afhænger omdøbningsscriptet af eksportnavnets format. Hvis en fremtidig Virtual Machine Manager-opdatering ændrer det, vil scriptet stoppe med at matche filer. Testtilstanden er den hurtigste måde at bekræfte, at den stadig ser dine eksporter efter en opdatering.

Ofte stillede spørgsmål #

Referencer og videogennemgange #

• Virtuel maskine i Virtual Machine Manager, videnscenterartiklen, der dækker eksport.
• Hjælp til Cloud Sync, inklusive synkroniseringsretning og opgaveindstillinger.
• Google Drev-lagerplads og uploadgrænser, med den daglige uploadgrænse på 750 GB.
• Synology VMM-hvidbog, om databeskyttelseslag for virtuelle maskiner.
• Opgaveplanlægger i DSM, for at køre omdøbningsscriptet som en planlagt opgave.

Videoer om værktøjerne i denne kæde: Cloud Sync og eksport og migrering af virtuelle maskiner på en Synology NAS.

Vil du tilføje replikering mellem værter oven i din eksterne kopi? Få en VMM Pro licens, eller læs hvordan resten af denne hjemmeside fungerer i vores NAS Hosting 101-serie.