VMM-säkerhetskopiering till Google Drive: Schemalagd export, molnsynkronisering och ett enda namnbytesskript

En VMM-säkerhetskopia som bara finns på samma NAS som den virtuella maskinen är egentligen inte en säkerhetskopia. Om den boxen kraschar följer båda kopiorna med. Den här lagringen körs som en Virtual DSM-gäst i Synology Virtual Machine Manager, och vår externa VMM-säkerhetskopia är byggd från två gratisverktyg som följer med DSM: schemalagd export i Virtual Machine Manager och Cloud Sync till Google Drive. Det tog en eftermiddag att installera den. Det tog längre tid att ta reda på varför den tyst hade slutat fungera, och det är delvis anledningen till att den här NAS Hosting 101-artikeln finns. Nedan följer installationen som fungerar, den enda filnamnsfejken som förstör den, det lilla skriptet som fixar den och vad en granskning av våra egna exporter visade.

SynoPower Club-punkt: Varje supporttekniker har en berättelse om kunden vars säkerhetskopior gick gröna i ett år och inte återställde någonting. Jag förväntade mig inte att skriva en om vår egen butik. Vårt VMM-säkerhetskopieringsjobb såg helt felfritt ut i gränssnittet, men den ena värddatorn hade samlat på sig en terabyte av exportfiler som den aldrig kunde rensa, och den andra hade inte producerat en enda fil på tretton dagar. Ingenting var dolt. Allt fanns i en logg som ingen läser. Åtgärden tog en timme; lärdomen är att kontrollera att filerna faktiskt finns där du tror att de är, enligt ett schema, som vilket annat jobb som helst.

Vad en komplett VMM-säkerhetskopiering behöver #

Virtual Machine Manager ger dig tre skyddslager, och varje lager täcker olika fel. En sund VMM-säkerhetskopieringsplan använder mer än ett.

Lager	Var kopian finns	Vad den skyddar mot
Ögonblicksbilder	Samma volym som gästen	En dålig uppdatering eller ett misstag inuti gästen
Replikering (VMM Pro)	En annan NAS i klustret	En NAS-server som inte fungerar, men den andra värden återställer den snabbt
Schemalagd export + Molnsynkronisering	Ett molnkonto utanför webbplatsen	Förlorar hela webbplatsen: brand, stöld, ransomware på LAN

Vi replikerar redan sex gäster till en reservvärd, vilket beskrivs i vår artikel om tre-nods Synology virtuell maskinkluster. Replikering behåller en kopia i byggnaden. Exportlagret är det som behåller en kopia utanför den.

Så fungerar schemalagd export i VMM #

För en VMM-säkerhetskopiering skriver schemalagd export en komplett kopia av en gästfil, diskar och konfiguration, som en enda OVA-fil i en delad mapp. Du väljer målmapp, exportläge, daglig, veckovis eller månadsvis tidsplan och hur många av de senaste filerna som ska behållas. Exporter körs medan gästfilen körs.

Två regler är lätta att missa. För det första konfigureras och skrivs exporten på värden där gästens lagring liv, inte var den körs. I ett kluster kan en gäst köra på en NAS medan dess diskar finns på en annan, och Virtual Machine Manager gråmarkerar det schemalagda exportalternativet på fel värd. För det andra använder schemat den lagringsvärdens klocka.

Dialogrutan visar även det konsekventa läget. Utan Synology Guest Tool installerat i gästprogrammet är exporterna kraschkonsekventa, samma tillstånd som att dra i strömsladden. Det fungerar bra för de flesta arbetsbelastningar, och installation av Guest Tool uppgraderar det till filsystemkonsekvent.

Varför Cloud Sync hoppar över VMM-säkerhetskopior #

Det självklara nästa steget är att rikta Cloud Sync mot exportmappen och låta den ladda upp allt till Google Drive. Vi gjorde just det, och VMM-säkerhetskopiorna kom aldrig fram.

Anledningen är filnamnet. Virtual Machine Manager namnger varje export med en tidsstämpel som innehåller kolon:

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

Cloud Sync laddade inte upp dessa namn till vår Google Drive, så varje export förblev lokal. Filen är giltig; tecknet är problemet. Eftersom exportens tidsstämpelformat inte kan ändras i Virtual Machine Manager måste åtgärden ske mellan exporten och uppladdningen.

Intressant nog har endast schemalagda exporter tidsstämpeln. En manuell export från samma meny sparas helt enkelt som gästnamnet, till exempel spc_4C8G.ova, och Cloud Sync laddar upp det utan att klaga. Det är därför ett snabbt manuellt test kan få hela kedjan att se bra ut medan nattschemat aldrig når molnet.

Konfigurera en VMM-säkerhetskopia till Google Drive i fyra steg #

Detta är den fungerande VMM-säkerhetskopieringskonfigurationen på varje värd som lagrar gäster. Den behöver Virtual Machine Manager, Cloud Sync och ett Google-konto; inget av det behöver VMM Pro.

Byt namn-skriptet bakom vår VMM-säkerhetskopiering #

Skriptet är den enda anpassade delen i VMM-säkerhetskopieringskedjan, och det gör två saker. Det byter namn på varje färdig export, ersätter kolon med bindestreck, och det behåller bara de senaste kopiorna av varje gäst i exportmappen. Det berör bara filer som inte har ändrats på femton minuter, så det byter aldrig namn på en export som fortfarande skrivs.

#!/bin/bash # vm-export-cloud.sh - gör VMM-exporter uppladdningsbara med Cloud Sync. # # VMM namnger exporter " -ÅÅÅÅ-MM-DD TT:MM:SS- .ova". Cloud Sync kommer # inte att ladda upp namn som innehåller ":", vilket också innebär att den aldrig rör vid en export # som fortfarande skrivs. När en export är klar byter den namn på sin plats med ":" ersatt av "-" så Cloud Sync hämtar den och behåller sedan bara de # nyaste KEEP omdöpta exporterna per gäst. (VMM:s egen lagring kan inte längre se # omdöpta filer, så lagring sker här.) # # Användning: vm-export-cloud.sh EXPORT_DIR KEEP [--apply] # Utan --apply skriver den bara ut vad den skulle göra. set -u DIR=${1:?EXPORT_DIR}; KEEP=${2:?KEEP}; APPLY=${3:-} MIN_AGE_MIN=15 # en färdig export är orörd så här länge LOG="$(katalognamn "$(läslänk -f "$0")")/vm-export-cloud.log" say() { echo "$(datum '+%F %T') $*"; [ "$APPLY" = "--apply" ] && echo "$(datum '+%F %T') $*" >> "$LOG"; } run() { if [ "$APPLY" = "--apply" ]; then "$@"; else echo "(test) $*"; fi; } [ -d "$DIR" ] || { say "FEL exportmapp saknas: $DIR"; exit 1; } # 1. byt namn färdiga exporter hitta "$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. behåll den nyaste BEHÅLL omdöpta exporter per gäst (tidsstämpeln finns i namnet) { 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' | sortera -t$'\t' -k1,1 -k2,2r | awk -F'\t' -v keep="$KEEP" '{ n[$1]++; if (n[$1] > keep) print $3 }' | medan IFS= läs -r gammal; säg "delete (beyond newest $KEEP): $old" run rm -f -- "$DIR/$old" done say "done: $(hitta "$DIR" -maxdepth 1 -name '*.ova' | wc -l) exports in $DIR, $(df -h "$DIR" | awk 'NR==2{print $4" free"}')""

Kör den utan det sista argumentet först. I det läget skriver den bara ut det som den skulle byta namn på och ta bort. När utdata ser korrekt ut, schemalägg den med det extra argumentet som gör att den fungerar. Vårt Task Scheduler-jobb körs varje timme som root med ett kommando som detta, ett jobb per exportmapp:

bash /volym1/@vm-export-cloud/vm-export-cloud.sh "/volym3/VM_BK_Export" 3 --tillämpa

En användbar bieffekt av kolonregeln: Cloud Sync kan inte ladda upp en export förrän skriptet har bytt namn på den, och skriptet byter bara namn på färdiga filer. Halvskrivna exporter når aldrig molnet.

Varför skriptet hanterar VMM-säkerhetskopieringskvarhållning #

Virtual Machine Manager har sin egen inställning för lagring, och den fungerar genom att registrera varje export den skapar. När skriptet byter namn på en fil känner Virtual Machine Manager inte längre igen den och kommer aldrig att radera den. Så lagringen flyttas till skriptet, som räknar kopior per gäst från tidsstämpeln i namnet.

På Cloud Sync-sidan avgör en kryssruta vad som händer i Google Drive. Ordalydelsen är lätt att missförstå: Ta inte bort filer i målmappen när de har tagits bort i källmappen.. Om du lämnar den avmarkerad speglar Google Drive NAS-enheten och behåller samma tre kopior. Markera den så behåller molnet alla exporter som någonsin laddats upp, vilket är det säkrare valet mot ransomware, men det växer tills du beskär det manuellt.

Vad en granskning av vår egen export visade #

Innan den här installationen hade vår VMM-säkerhetskopiering körts på båda produktionsvärdarna i ungefär en månad. Att kontrollera filerna istället för instrumentpanelen visade tre separata fel.

• Retention tyst avbruten på en värd. Den lilla databasen som Virtual Machine Manager använder för att spåra exporter kunde inte skapas i exportmappen, så varje körning loggade ett fel och ingen gammal export raderades någonsin. En värd samlade på sig en terabyte med OVA-filer och nådde 97% full.
• Den största gästen slutade exportera. Dess 84 GB-export fick inte längre plats i det återstående utrymmet, så den misslyckades tre dagar i rad utan att vi märkte någon varning.
• Tre scheman som pekar ingenstans. En inställningsändring lämnade tre exportscheman med en tom destination. Från och med den dagen loggade de ett ogiltigt delningsnamn varje minut, över 20 000 gånger, och exporterade ingenting, inklusive schemat för den här arkivet.

Inget av detta visades som ett VMM-säkerhetskopieringsfel vid normal användning. Gästerna körde, butiken tog emot beställningar och replikeringen behöll en kopia på standby-värden. Exportlagret, den enda kopian utanför webbplatsen, hade helt enkelt stoppats. Vi kontrollerar nu exportmapparna och Cloud Sync-uppladdningslistan efter varje ändring av ett schema.

Bandbredds- och lagringsplanering för en VMM-säkerhetskopiering #

Varje VMM-säkerhetskopiaexport är en fullständig kopia, inte en inkrementell kopia, så storleksbestäm dem innan du väljer ett schema. Våra gäster varierar från en liten webbplats på 5 GB till en partnerwebbplats på 84 GB, och den här butikens egen export är cirka 7 GB. För alla gäster laddar ett dagligt schema upp långt över 100 GB per dag.

Google Drive låter varje användare ladda upp 750 GB på 24 timmar, med filer upp till 5 TB, så gränsen är sällan problemet. Uppladdningstid och molnlagring är det. Att ha tre kopior av varje gäst i molnet kräver tre gånger det dagliga totala Drive-utrymmet, och mer om molnet behåller varje kopia. För stora, långsamt föränderliga gäster räcker det ofta med en veckovis export, särskilt när replikering redan täcker daglig återställning.

Varför vi bygger säkerhetskopior på Synology-verktyg #

Allt i den här VMM-säkerhetskopieringskedjan levereras med DSM. Virtual Machine Manager exporterar gästerna, Cloud Sync laddar upp dem, Task Scheduler kör skriptet och samma NAS-enheter lagrar våra filer och kör lagringen. Det finns ingen säkerhetskopieringsagent att licensiera per gäst och ingen separat säkerhetskopieringsserver att underhålla.

De delar vi betalar för är de som ger extra skydd mellan värdar: a VMM Pro-licens för replikering till standby-systemet, och Virtual DSM-licenser för de extra DSM-gästerna. Om du bestämmer dig för vilken utgåva du behöver, vår Virtual Machine Manager vs VMM Pro jämförelse täcker det.

VMM-säkerhetskopieringsgränser och varningar #

En export är en fullständig kopia vid en viss tidpunkt. Utan gästverktyget är det kraschkonsekvent, så databaserna i gästverktyget återställs på samma sätt som de skulle göra efter ett strömavbrott. Testa en återställning av din viktigaste gäst minst en gång.

Att återställa en VMM-säkerhetskopia från molnet innebär att man först laddar ner hela filen. En export på 84 GB tar timmar på en vanlig kontorsanslutning, så molnkopian är till för katastrofer, inte vardagliga misstag. Ögonblicksbilder och replikering hanterar dessa mycket snabbare.

Cloud Sync kan kryptera filer före uppladdning, och vi rekommenderar att du aktiverar det för gäster som lagrar kunddata. Förvara krypteringslösenordet någonstans som inte är beroende av den NAS du skyddar.

Slutligen beror namnbytesskriptet på exportnamnets format. Om en framtida Virtual Machine Manager-uppdatering ändrar det kommer skriptet att sluta matcha filer. Testkörningsläget är det snabbaste sättet att bekräfta att det fortfarande ser dina exporter efter en uppdatering.

Vanliga frågor #

Referenser och videogenomgångar #

• Virtuell maskin i Virtual Machine Manager, kunskapscenterartikeln som behandlar export.
• Hjälp med Cloud Sync, inklusive synkroniseringsriktning och uppgiftsinställningar.
• Lagrings- och uppladdningsgränser för Google Drive, med en daglig uppladdningsgräns på 750 GB.
• Synology VMM-vitbok, om dataskyddslager för virtuella maskiner.
• Aktivitetsschemaläggare i DSM, för att köra namnbytesskriptet som en schemalagd uppgift.

Videor om verktygen i den här kedjan: Cloud Sync och export och migrering av virtuella maskiner på en Synology NAS.

Vill du lägga till replikering mellan värdar utöver din externa kopia? Skaffa en VMM Pro-licens, eller läs hur resten av den här webbplatsen fungerar i vår NAS Hosting 101-serie.