VMM biztonsági mentés a Google Drive-ra: Ütemezett exportálás, felhőszinkronizálás és egyetlen átnevezési szkript

Egy olyan VMM biztonsági mentés, ami csak ugyanazon a NAS-on található, mint a virtuális gép, valójában nem biztonsági mentés. Ha ez a modul meghibásodik, mindkét másolat vele együtt megy. Ez a tároló Virtual DSM vendégként fut az Synology Virtual Machine Manager szerveren, és a külső VMM biztonsági mentésünk két ingyenes, a DSM-mel együtt érkező eszközzel készült: az ütemezett exportálással az Virtual Machine Manager szerveren és a felhőalapú szinkronizálással a Google Drive-ra. A beállítása egy délutánt vett igénybe. Annak kiderítése, hogy miért állt le csendben a működése, tovább tartott, és ez az oka annak, hogy létezik ez a NAS Hosting 101 cikk. Az alábbiakban látható a működő beállítás, az egyetlen fájlnévbeli furcsaság, ami elrontja, a kis szkript, ami kijavítja, és hogy mit hozott nyilvánosságra a saját exportjaink auditja.

SynoPower Club pont: Minden támogatási mérnöknek van egy története az ügyfélről, akinek a biztonsági mentései egy évig zölden futottak, és semmit sem állítottak vissza. Nem gondoltam volna, hogy a saját műhelyünkről fogok írni. A VMM biztonsági mentési feladatunk tökéletesen egészségesnek tűnt a felületen, mégis az egyik gazdagép egy terabájtnyi exportot halmozott fel, amit soha nem tudott megtisztítani, a másik pedig tizenhárom napja egyetlen fájlt sem készített. Semmi sem volt elrejtve. Minden egy naplóban volt, amit senki sem olvas. A javítás egy órát vett igénybe; a tanulság az, hogy ellenőrizzük, hogy a fájlok valóban ott vannak-e, ahol gondoljuk, hogy vannak, ütemterv szerint, mint bármely más feladatnál.

Mire van szüksége egy teljes VMM biztonsági mentésnek? #

Az Virtual Machine Manager három védelmi réteget kínál, és mindegyik más-más hibát fed le. Egy megbízható VMM biztonsági mentési terv többet is használ.

Réteg	Hol lakik a másolat	Ami ellen véd
Pillanatképek	Ugyanolyan hangerővel, mint a vendég	Rossz frissítés vagy hiba a vendégben
Replikáció (VMM Pro)	Egy másik NAS a klaszterben	Egy NAS meghibásodása, a másik gazdagépen gyors helyreállítás
Ütemezett exportálás + Felhőszinkronizálás	Egy felhőalapú fiók külső helyszínen	Az egész oldal elvesztése: tűz, lopás, zsarolóvírus a LAN-on

Már hat vendéget replikáltunk egy készenléti gazdagépre, ahogy azt a leírásunkban is leírtuk. három csomópontos Synology virtuálisgép-klaszter. A replikáció a másolatot az épületben tartja. Az export réteg az, ami a másolatot azon kívül tartja.

A VMM ütemezett exportálásának működése #

VMM biztonsági mentés esetén az ütemezett exportálás a vendéggép, a lemezek és a konfiguráció teljes másolatát egyetlen OVA-fájlként írja ki egy megosztott mappába. Ön választja ki a célmappát, az exportálás módját, a napi, heti vagy havi időzítést, valamint azt, hogy a legújabb fájlok közül hányat tartson meg. Az exportálás a vendéggép futása közben fut.

Két szabályt könnyű figyelmen kívül hagyni. Először is, az exportálás azon a gépen van konfigurálva és írva, ahol a vendéggép található. tárolás él, nem pedig az, hogy hol fut. Egy fürtben egy vendéggép futtatható az egyik NAS-on, miközben a lemezei egy másikon vannak, és az Virtual Machine Manager szürkén jeleníti meg az ütemezett exportálási opciót a rossz gépen. Másodszor, az ütemezés az adott tárológép óráját használja.

A párbeszédpanel a konzisztens állapotot is mutatja. Ha az Synology Guest Tool nincs telepítve a vendég rendszeren, az exportálások összeomlás-konzisztensek, ugyanolyan állapotban vannak, mint amikor kihúzzuk a tápkábelt. Ez a legtöbb munkaterheléshez megfelelő, és a Guest Tool telepítése fájlrendszer-konzisztensre frissíti.

Miért hagyja ki a Cloud Sync a VMM biztonsági mentési fájljait? #

A következő nyilvánvaló lépés az, hogy a Cloud Sync-et az exportmappára irányítsuk, és hagyjuk, hogy mindent feltöltsön a Google Drive-ra. Pontosan ezt tettük, és a VMM biztonsági mentési fájljai soha nem érkeztek meg.

Az ok a fájlnév. Az Virtual Machine Manager minden exportálást egy kettőspontokat tartalmazó időbélyeggel nevez el:

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

A Cloud Sync nem töltötte fel ezeket a neveket a Google Drive-ra, így minden exportálás lokális maradt. A fájl érvényes; a karakter a probléma. Mivel az exportálás időbélyegének formátuma nem módosítható az Virtual Machine Manager-ben, a javításnak az exportálás és a feltöltés között kell megtörténnie.

Érdekes módon csak az ütemezett exportok tartalmazzák az időbélyeget. Ugyanebből a menüből történő manuális exportálás egyszerűen vendégnévként kerül mentésre, például spc_4C8G.ova, és a Cloud Sync panasz nélkül feltölti. Ezért egy gyors manuális teszttel az egész lánc rendben lévőnek tűnhet, míg az éjszakai ütemterv soha nem jut el a felhőbe.

VMM biztonsági mentés beállítása a Google Drive-ra 4 lépésben #

Ez a működő VMM biztonsági mentési beállítás minden olyan gazdagépen, amely a vendégeket tárolja. Szükség van hozzá Virtual Machine Manager-re, Cloud Sync-re és egy Google-fiókra; egyikhez sem kell VMM Pro.

A VMM biztonsági mentésünk mögött álló átnevezési szkript #

A szkript a VMM biztonsági mentési láncának egyetlen egyéni eleme, és két dolgot végez. Átnevezi az összes befejezett exportálást, a kettőspontokat kötőjelekre cserélve, és csak az egyes vendégfájlok legújabb másolatait tartja meg az exportmappában. Csak azokat a fájlokat érinti, amelyek tizenöt perce nem változtak, így soha nem nevez át olyan exportálást, amely még írás alatt áll.

#!/bin/bash # vm-export-cloud.sh - a VMM exportok feltölthetővé tétele a Cloud Sync által. # # VMM exportok elnevezése " -ÉÉÉÉ-HH-NN ÓÓ:PP:MM- .ova". A Cloud Sync # nem tölti fel a ":"-t tartalmazó neveket, ami azt is jelenti, hogy soha nem érinti a még írás alatt álló exportokat #. Miután egy export befejeződött, a program átnevezi azt a # helyén a ":" helyére "-" kerül, így a Cloud Sync felveszi, majd vendégenként csak a # legújabb KEEP átnevezett exportokat tartja meg. (A VMM saját megőrzési funkciója már nem látja az # átnevezett fájlokat, ezért a megőrzés itt történik.) # # Használat: vm-export-cloud.sh EXPORT_DIR KEEP [--apply] # A --apply nélkül csak azt írja ki, hogy mit tenne. set -u DIR=${1:?EXPORT_DIR}; KEEP=${2:?KEEP}; APPLY=${3:-} MIN_AGE_MIN=15 # egy befejezett export ennyi ideig érintetlen marad LOG="$(könyvtárnév "$(readlink -f "$0")")/vm-export-cloud.log" say() { echo "$(date '+%F %T') $*"; [ "$APPLY" = "--apply" ] && echo "$(date '+%F %T') $*" >> "$LOG"; } run() { if [ "$APPLY" = "--apply" ]; then "$@"; else echo " (szárazon futtatás) $*"; fi; } [ -d "$DIR" ] || { say "HIBA export mappa hiányzik: $DIR"; exit 1; } # 1. Nevezd át a kész exportokat 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. megtartja a legújabbat KEEP átnevezett exportok vendégenként (az időbélyeg a névben van) { 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' | sort -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 azt mondja, hogy "törlés (a legújabb $KEEP-en túl): $old" run rm -f -- "$DIR/$old" done say "done: $(find "$DIR" -maxdepth 1 -name '*.ova' | wc -l) exportálás $DIR-be, $(df -h "$DIR" | awk 'NR==2{print $4" free"}')""

Először az utolsó argumentum nélkül futtassa. Ebben a módban csak azt írja ki, amit átnevezne és törölne. Ha a kimenet megfelelőnek tűnik, ütemezze a műveletet végrehajtó extra argumentummal. A Feladatütemező feladatunk óránként fut root felhasználóként egy ilyen paranccsal, exportmappánként egy feladat:

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

A kettőspont-szabály egy hasznos mellékhatása: a Cloud Sync nem tud feltölteni egy exportálást, amíg a szkript át nem nevezi azt, és a szkript csak a kész fájlokat nevezi át. A félig megírt exportálások soha nem érik el a felhőt.

Miért kezeli a szkript a VMM biztonsági mentések megőrzését? #

Az Virtual Machine Manager saját adatmegőrzési beállítással rendelkezik, és úgy működik, hogy minden létrehozott exportálást rögzít. Miután a szkript átnevez egy fájlt, az Virtual Machine Manager már nem ismeri fel azt, és soha nem törli. Így a adatmegőrzési beállítás a szkriptbe kerül, amely a névben található időbélyeg alapján számolja a vendégenkénti másolatokat.

A Cloud Sync oldalán egyetlen jelölőnégyzet határozza meg, hogy mi történjen a Google Drive-ban. A megfogalmazása könnyen félreérthető: Ne távolítsa el a célmappában lévő fájlokat, amikor a forrásmappában eltávolítják őket. Hagyd üresen, és a Google Drive tükrözi a NAS-t, ugyanazt a három másolatot megtartva. Ha bejelölöd, a felhő minden feltöltött exportot megőrz, ami biztonságosabb választás a zsarolóvírusok ellen, de addig növekszik, amíg manuálisan meg nem metszed.

Mit állapított meg saját exportunk ellenőrzése? #

A beállítás előtt a VMM biztonsági mentésünk körülbelül egy hónapja futott mindkét éles gépen. A fájlok ellenőrzése az irányítópult helyett három külön hibát tárt fel.

• A retenció csendben megszakadt az egyik gazdagépen. Az Virtual Machine Manager által az exportok nyomon követésére használt kis adatbázist nem sikerült létrehozni az exportmappában, így minden futtatás hibát jelzett, és egyetlen régi export sem törlődött. Az egyik hoszt egy terabájtnyi OVA fájlt halmozott fel, és elérte a 97% mappát.
• A legnagyobb vendég abbahagyta az exportot. A 84 GB-os export már nem fért el a megmaradt helyen, így három egymást követő napon meghibásodott mindenféle riasztás nélkül.
• Három, sehová sem mutató menetrend. Egy beállításmódosítás miatt három exportálási ütemterv üres célhellyel maradt. Attól a naptól kezdve percenként érvénytelen megosztási nevet rögzítettek, több mint 20 000 alkalommal, és semmit sem exportáltak, beleértve az áruház ütemtervét sem.

Normál használat során semmi sem mutatott VMM biztonsági mentési hibát. A vendégek futottak, az áruház fogadta a rendeléseket, és a replikáció egy másolatot tartott a készenléti gazdagépen. Az exportálási réteg, az egyetlen külső helyszínen lévő másolat, egyszerűen leállt. Most minden ütemezés-módosítás után ellenőrizzük az exportmappákat és a Cloud Sync feltöltési listáját.

Sávszélesség és tárhely tervezése VMM biztonsági mentéshez #

Minden VMM biztonsági mentés exportálása teljes másolat, nem pedig növekmény, ezért az ütemezés kiválasztása előtt méretezze át őket. Vendégeink száma az 5 GB-os kis weboldalaktól a 84 GB-os partnerwebhelyekig terjed, és ennek az áruháznak a saját exportja körülbelül 7 GB. Az összes vendég esetében egy napi ütemterv több mint 100 GB-ot tölt fel.

A Google Drive minden felhasználó számára 750 GB feltöltését teszi lehetővé 24 óra alatt, akár 5 TB méretű fájlok esetén, így a korlát ritkán jelent problémát. A feltöltési idő és a felhőalapú tárhely igen. Ha minden vendégről három másolatot tárolunk a felhőben, az a napi Drive-tárhely háromszorosát igényli, és még többet is, ha a felhő minden másolatot tárol. Nagy, lassan változó vendégek esetén gyakran elegendő a heti exportálás, különösen akkor, ha a replikáció már fedezi a napi helyreállítást.

Miért készítünk biztonsági mentéseket az Synology Tools segítségével? #

A VMM biztonsági mentési láncában található összes elem a DSM-mel együtt érkezik. Az Virtual Machine Manager exportálja a vendéggépeket, a Cloud Sync feltölti azokat, a Feladatütemező futtatja a szkriptet, és ugyanazok a NAS egységek tárolják a fájljainkat és futtatják a tárhelyet. Nincs vendéggépenként licencelendő biztonsági mentési ügynök, és nincs külön karbantartásra szoruló biztonsági mentési szerver.

Azokért a dolgokért fizetünk, amelyek védelmet nyújtanak a hosztok között: a VMM Pro licenc a készenléti tárolóba való replikációhoz, és Virtual DSM licenc a DSM további vendégeinek. Ha azon gondolkodik, hogy melyik kiadásra van szüksége, a mi Virtual Machine Manager és VMM Pro összehasonlítás lefedi azt.

VMM biztonsági mentési korlátok és kikötések #

Az exportálás egy teljes másolat egy adott időpontban. A Guest Tool nélkül az összeomlás konzisztens, így a vendéggépen belüli adatbázisok úgy állnak helyre, mint áramkimaradás után. A legfontosabb vendéggép visszaállítását legalább egyszer teszteld.

Egy VMM biztonsági mentés felhőből történő visszaállítása azt jelenti, hogy először le kell tölteni a teljes fájlt. Egy 84 GB-os exportálás órákig tart egy tipikus irodai kapcsolaton, így a felhőalapú másolat katasztrófákra, nem pedig a mindennapi hibákra szolgál. A pillanatképek és a replikáció sokkal gyorsabban kezeli ezeket.

A Cloud Sync képes titkosítani a fájlokat a feltöltés előtt, és azt javasoljuk, hogy kapcsolja be a szolgáltatást azoknak a vendégeknek, akik ügyféladatokat tárolnak. A titkosítási jelszót olyan helyen tárolja, amely nem függ a védett NAS-tól.

Végül, az átnevezési szkript az exportált név formátumától függ. Ha egy jövőbeli Virtual Machine Manager frissítés megváltoztatja, a szkript a továbbiakban nem fog fájlokat egyeztetni. A próbafuttatás mód a leggyorsabb módja annak, hogy megerősítsük, hogy a frissítés után is látja az exportált fájlokat.

Gyakran Ismételt Kérdések #

Referenciák és videós bemutatók #

• Virtuális gép az Virtual Machine Manager-ben, a tudásközpont exporttal foglalkozó cikke.
• Felhőszinkronizálási segítség, beleértve a szinkronizálás irányát és a feladatbeállításokat.
• Google Drive tárhely- és feltöltési korlátai, a napi 750 GB-os feltöltési korláttal.
• Synology VMM tanulmány, a virtuális gépek adatvédelmi rétegeiről.
• Feladatütemező a DSM-ben, az átnevezési parancsfájl ütemezett feladatként történő futtatásához.

Videók az ebben a láncban található eszközökről: Felhőszinkronizálás, valamint virtuális gépek exportálása és migrálása Synology NAS-on.

Szeretnél replikációt hozzáadni a hosztok közötti külső másolatodhoz? Szerezz be egy VMM Pro licenc, vagy olvassa el, hogyan működik a webhely többi része NAS tárhely 101 sorozatunk.