Backup di VMM su Google Drive: esportazione programmata, sincronizzazione cloud e un unico script di rinomina.

Un backup VMM che risiede solo sullo stesso NAS della macchina virtuale non è un vero backup. Se quel server si guasta, entrambe le copie andranno perse. Questo archivio viene eseguito come guest Virtual DSM in Synology Virtual Machine Manager e il nostro backup VMM off-site è creato utilizzando due strumenti gratuiti inclusi in DSM: l'esportazione pianificata in Virtual Machine Manager e la sincronizzazione cloud con Google Drive. La configurazione ha richiesto un pomeriggio. Scoprire perché avesse smesso di funzionare silenziosamente ha richiesto più tempo, ed è proprio per questo che esiste questo articolo di NAS Hosting 101. Di seguito è riportata la configurazione funzionante, l'unica anomalia del nome file che la compromette, il piccolo script che la risolve e i risultati di un'analisi delle nostre esportazioni.

Punto SynoPower Club: Ogni tecnico dell'assistenza ha una storia da raccontare sul cliente i cui backup sono rimasti intatti per un anno senza mai essere ripristinati. Non mi aspettavo di doverne scrivere una sulla nostra azienda. Il nostro processo di backup VMM appariva perfettamente funzionante nell'interfaccia, eppure un host aveva accumulato un terabyte di file esportati che non riusciva a eliminare, e l'altro non aveva prodotto un singolo file per tredici giorni. Nulla era nascosto. Era tutto in un registro che nessuno legge. La soluzione ha richiesto un'ora; la lezione è: verificate che i file esistano effettivamente dove pensate che siano, con una pianificazione precisa, come per qualsiasi altro processo.

Cosa serve per un backup VMM completo #

Virtual Machine Manager offre tre livelli di protezione, ognuno dei quali copre un diverso tipo di guasto. Un piano di backup VMM efficace ne utilizza più di uno.

Strato	Dove risiede la copia	Ciò contro cui protegge
Istantanee	Stesso volume dell'ospite	Un aggiornamento errato o un errore all'interno del sistema guest
Replicazione (VMM Pro)	Un altro NAS nel cluster	Un NAS si guasta, ma il ripristino è rapido sull'altro host.
Esportazione programmata + sincronizzazione cloud	Un account cloud esterno	Perdita dell'intero sito: incendio, furto, ransomware sulla LAN

Abbiamo già replicato sei ospiti su un host di standby, come descritto nel nostro articolo cluster di macchine virtuali Synology a tre nodi. La replica mantiene una copia all'interno dell'edificio. Il livello di esportazione è ciò che mantiene una copia all'esterno.

Come funziona l'esportazione pianificata di VMM #

Per un backup VMM, l'esportazione pianificata crea una copia completa di una macchina virtuale, dischi e configurazione, come singolo file OVA in una cartella condivisa. È possibile scegliere la cartella di destinazione, la modalità di esportazione, la frequenza (giornaliera, settimanale o mensile) e il numero di file più recenti da conservare. Le esportazioni vengono eseguite mentre la macchina virtuale è in esecuzione.

Due regole sono facili da dimenticare. Innanzitutto, l'esportazione è configurata e scritta sull'host dove si trova l'ospite magazzinaggio La configurazione dipende dall'host di archiviazione, non dal luogo in cui il sistema è in esecuzione. In un cluster, una macchina virtuale può essere in esecuzione su un NAS mentre i suoi dischi si trovano su un altro, e la configurazione Virtual Machine Manager disabilita l'opzione di esportazione pianificata sull'host sbagliato. In secondo luogo, la pianificazione utilizza l'orologio di quell'host di archiviazione.

La finestra di dialogo mostra anche lo stato di coerenza. Senza lo strumento Synology Guest Tool installato nella macchina virtuale, le esportazioni sono coerenti con l'arresto anomalo del sistema, ovvero nello stesso stato in cui si trova il sistema quando si scollega il cavo di alimentazione. Questo va bene per la maggior parte dei carichi di lavoro e l'installazione di Guest Tool aggiorna lo stato a coerenza con il file system.

Perché Cloud Sync ignora i file di backup di VMM #

Il passo successivo più ovvio è stato quello di indicare a Cloud Sync la cartella di esportazione e lasciare che caricasse tutto su Google Drive. Abbiamo fatto esattamente così, ma i file di backup di VMM non sono mai arrivati.

Il motivo risiede nel nome del file. Virtual Machine Manager assegna a ogni file esportato un timestamp che contiene i due punti:

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

Cloud Sync non caricava quei nomi su Google Drive, quindi ogni esportazione rimaneva locale. Il file è valido; il problema è il carattere. Poiché il formato del timestamp di esportazione non può essere modificato in Virtual Machine Manager, la correzione deve avvenire tra l'esportazione e il caricamento.

È interessante notare che solo le esportazioni programmate hanno il timestamp. Un'esportazione manuale dallo stesso menu viene salvata semplicemente come nome dell'ospite, ad esempio spc_4C8G.ova, e Cloud Sync lo carica senza problemi. Ecco perché un rapido test manuale può far sembrare che l'intera catena funzioni correttamente, mentre la pianificazione notturna non raggiunge mai il cloud.

Configurare un backup VMM su Google Drive in 4 passaggi #

Questa è la configurazione di backup VMM funzionante su ciascun host che ospita le macchine virtuali. Richiede Virtual Machine Manager, Cloud Sync e un account Google; non richiede VMM Pro.

Lo script di rinomina alla base del nostro backup VMM #

Lo script è l'unico elemento personalizzato della catena di backup di VMM e svolge due funzioni. Rinomina ogni esportazione completata, sostituendo i due punti con i trattini, e conserva nella cartella di esportazione solo le copie più recenti di ogni macchina virtuale. Agisce esclusivamente sui file che non sono stati modificati per quindici minuti, quindi non rinomina mai un'esportazione ancora in fase di scrittura.

#!/bin/bash # vm-export-cloud.sh - rende le esportazioni VMM caricabili tramite Cloud Sync. # # Esportazioni dei nomi VMM " -AAAA-MM-GG HH:MM:SS- .ova". Cloud Sync non caricherà i nomi contenenti ":", il che significa anche che non tocca mai un'esportazione che è ancora in fase di scrittura. Una volta terminata un'esportazione, la rinomina nel posto in cui ":" è sostituito da "-" in modo che Cloud Sync la rilevi, quindi mantiene solo le esportazioni rinominate più recenti per guest. (La conservazione di VMM non può più vedere i file rinominati, quindi la conservazione viene eseguita qui.) Utilizzo: vm-export-cloud.sh EXPORT_DIR KEEP [--apply] Senza --apply stampa solo ciò che farebbe. set -u DIR={1:?EXPORT_DIR}; KEEP={2:?KEEP}; APPLY={3:-} MIN_AGE_MIN=15 # un'esportazione completata è rimasta intatta per tutto questo tempo LOG="$(dirname "$(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 " (dry-run) $*"; fi; } [ -d "$DIR" ] || { say "ERRORE cartella di esportazione mancante: $DIR"; esci 1; } # 1. rinomina esportazioni terminate trova "$DIR" -maxdepth 1 -tipo f -nome '*:*.ova' -mmin +$MIN_AGE_MIN -print0 | mentre IFS= leggi -r -d '' f; fai se comando -v fuser >/dev/null 2>&1 && fuser -s "$f" 2>/dev/null; allora dì "salta (in uso): $(nome base "$f")"; continua fi nuovo="$DIR/$(nome base "$f" | tr ':' '-')" dì "rinomina: $(nome base "$f") -> $(nome base "$new")" esegui mv -n "$f" "$new" fatto # 2. mantieni le esportazioni rinominate più recenti per guest (il timestamp è nel nome) { trova "$DIR" -maxdepth 1 -type f -name '*.ova' ! -name '*:*' -printf '%f\n' [ "$APPLY" = "--apply" ] || trova "$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 say "elimina (oltre il più recente $KEEP): $old" run rm -f -- "$DIR/$old" done say "fatto: $(trova "$DIR" -maxdepth 1 -name '*.ova' | wc -l) esporta in $DIR, $(df -h "$DIR" | awk 'NR==2{print $4" free"}')""

Eseguilo prima senza l'ultimo argomento. In questa modalità, stamperà solo ciò che verrebbe rinominato ed eliminato. Una volta che l'output sembra corretto, pianificalo con l'argomento aggiuntivo che lo fa agire. Il nostro processo di Utilità di pianificazione viene eseguito ogni ora come root con un comando simile a questo, un processo per ogni cartella di esportazione:

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

Un utile effetto collaterale della regola dei due punti: Cloud Sync non può caricare un'esportazione finché lo script non l'ha rinominata, e lo script rinomina solo i file completati. Le esportazioni incomplete non raggiungono mai il cloud.

Perché lo script gestisce la conservazione dei backup di VMM #

Virtual Machine Manager ha una propria impostazione di conservazione, che funziona registrando ogni file esportato. Una volta che lo script rinomina un file, Virtual Machine Manager non lo riconosce più e non lo eliminerà mai. Pertanto, la gestione della conservazione viene affidata allo script, che conta le copie per ogni utente a partire dal timestamp presente nel nome del file.

Per quanto riguarda la sincronizzazione cloud, una casella di controllo determina cosa succede in Google Drive. La sua formulazione è facile da fraintendere: Non eliminare i file nella cartella di destinazione quando vengono eliminati nella cartella di origine.. Se la casella non è selezionata, Google Drive esegue il mirroring del NAS, mantenendo le stesse tre copie. Se la si seleziona, il cloud conserva ogni singolo file esportato, il che rappresenta la scelta più sicura contro i ransomware, ma il contenuto tende a crescere fino a quando non viene eliminato manualmente.

Cosa ha rivelato un audit sulle nostre esportazioni #

Prima di questa configurazione, il nostro backup VMM era in esecuzione su entrambi gli host di produzione da circa un mese. Il controllo dei file anziché della dashboard ha rivelato tre errori distinti.

• La conservazione dei dati è stata interrotta silenziosamente su un host. Il piccolo database utilizzato da Virtual Machine Manager per tenere traccia delle esportazioni non poteva essere creato nella cartella di esportazione, quindi ogni esecuzione registrava un errore e nessuna vecchia esportazione veniva mai eliminata. Un host ha accumulato un terabyte di file OVA e ha raggiunto la capacità massima di 97%.
• Il cliente più grande ha smesso di esportare. L'esportazione di 84 GB non rientrava più nello spazio disponibile, quindi l'operazione è fallita per tre giorni consecutivi senza che noi ne ricevessimo alcun avviso.
• Tre programmi che non portano da nessuna parte. Una modifica alle impostazioni ha lasciato tre pianificazioni di esportazione con una destinazione vuota. Da quel giorno in poi, hanno registrato un nome di condivisione non valido ogni minuto, per oltre 20.000 volte, e non hanno esportato nulla, inclusa la pianificazione per questo archivio.

Nessuno di questi problemi si è manifestato come un errore di backup di VMM durante il normale utilizzo. Le macchine virtuali erano in esecuzione, il negozio accettava ordini e la replica manteneva una copia sull'host di standby. Il livello di esportazione, l'unica copia esterna, si era semplicemente arrestato. Ora controlliamo le cartelle di esportazione e l'elenco di caricamento di Cloud Sync dopo ogni modifica alla pianificazione.

Pianificazione della larghezza di banda e dello spazio di archiviazione per un backup VMM #

Ogni backup esportato da VMM è una copia completa, non incrementale, quindi è importante dimensionarli prima di scegliere una pianificazione. I nostri clienti hanno dimensioni che variano da un piccolo sito web di 5 GB a un sito web di un partner di 84 GB, e l'esportazione di questo negozio è di circa 7 GB. Considerando tutti i clienti, una pianificazione giornaliera carica ben oltre 100 GB al giorno.

Google Drive consente a ciascun utente di caricare 750 GB in 24 ore, con file fino a 5 TB, quindi il limite raramente rappresenta un problema. I tempi di caricamento e lo spazio di archiviazione cloud lo sono. Mantenere tre copie di ogni guest nel cloud richiede il triplo dello spazio giornaliero disponibile su Drive, e ancora di più se il cloud conserva ogni copia. Per guest di grandi dimensioni e con modifiche lente, un'esportazione settimanale è spesso sufficiente, soprattutto quando la replica copre già il ripristino quotidiano.

Perché creiamo i backup con gli strumenti Synology #

In questa catena di backup VMM, ogni componente è incluso in DSM. Virtual Machine Manager esporta le macchine virtuali, Cloud Sync le carica, Utilità di pianificazione esegue lo script e le stesse unità NAS archiviano i file ed eseguono il backup. Non è necessario acquistare una licenza per ogni macchina virtuale né gestire un server di backup separato.

I pezzi per cui paghiamo sono quelli che aggiungono protezione tra gli host: un Licenza VMM Pro per la replica sul server di standby e Licenze Virtual DSM per gli ospiti DSM aggiuntivi. Se stai decidendo quale edizione ti serve, il nostro Confronto tra Virtual Machine Manager e VMM Pro lo copre.

Limiti e avvertenze relativi al backup di VMM #

Un'esportazione è una copia completa in un determinato momento. Senza Guest Tool, la coerenza è garantita anche in caso di arresto anomalo, quindi i database all'interno della macchina virtuale si ripristinano come farebbero dopo un'interruzione di corrente. Eseguite almeno una prova di ripristino della vostra macchina virtuale più importante.

Il ripristino di un backup VMM dal cloud implica prima il download dell'intero file. Un'esportazione di 84 GB richiede ore con una tipica connessione di rete aziendale, quindi la copia nel cloud è adatta solo in caso di emergenza, non per gli errori quotidiani. Gli snapshot e la replica gestiscono questi ultimi molto più velocemente.

Cloud Sync può crittografare i file prima del caricamento e consigliamo di attivarlo per gli utenti guest che ospitano dati dei clienti. Conservate la password di crittografia in un luogo indipendente dal NAS che state proteggendo.

Infine, lo script di rinomina dipende dal formato del nome di esportazione. Se un futuro aggiornamento di Virtual Machine Manager lo modifica, lo script smetterà di abbinare i file. La modalità di prova è il modo più rapido per verificare che lo script riconosca ancora le esportazioni dopo un aggiornamento.

Domande frequenti #

Riferimenti e video dimostrativi #

• Macchina virtuale in Virtual Machine Manager, l'articolo del centro di conoscenza che tratta dell'esportazione.
• Guida alla sincronizzazione cloud, incluse la direzione di sincronizzazione e le impostazioni delle attività.
• Limiti di archiviazione e caricamento di Google Drive, con un limite di caricamento giornaliero di 750 GB.
• Documento tecnico Synology VMM, sui livelli di protezione dei dati per le macchine virtuali.
• Utilità di pianificazione delle attività in DSM, per eseguire lo script di rinomina come attività pianificata.

Video sugli strumenti di questa serie: Cloud Sync, esportazione e migrazione di macchine virtuali su un NAS Synology.

Vuoi aggiungere la replica tra host oltre alla tua copia off-site? Ottieni un Licenza VMM Pro, oppure leggi come funziona il resto di questo sito in la nostra serie NAS Hosting 101.