{"id":21498,"date":"2026-09-27T22:09:37","date_gmt":"2026-09-27T14:09:37","guid":{"rendered":"https:\/\/synopower.club\/?post_type=docs&p=21498"},"modified":"2026-09-27T22:09:43","modified_gmt":"2026-09-27T14:09:43","password":"","slug":"vmm-backup-google-drive-cloud-sync","status":"publish","type":"docs","link":"https:\/\/synopower.club\/it\/docs\/vmm-backup-google-drive-cloud-sync\/","title":{"rendered":"Backup di VMM su Google Drive: esportazione programmata, sincronizzazione cloud e un unico script di rinomina."},"content":{"rendered":"

Un backup VMM che risiede solo sullo stesso NAS della macchina virtuale non \u00e8 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 \u00e8 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\u00e9 avesse smesso di funzionare silenziosamente ha richiesto pi\u00f9 tempo, ed \u00e8 proprio per questo che esiste questo articolo di NAS Hosting 101. Di seguito \u00e8 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.<\/p>\n\n\n\n

\n

Punto SynoPower Club:<\/strong> 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 \u00e8: verificate che i file esistano effettivamente dove pensate che siano, con una pianificazione precisa, come per qualsiasi altro processo.<\/p>\n<\/blockquote>\n\n\n\n

Cosa serve per un backup VMM completo<\/h2>\n\n\n\n

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\u00f9 di uno.<\/p>\n\n\n\n

Strato<\/th>Dove risiede la copia<\/th>Ci\u00f2 contro cui protegge<\/th><\/tr><\/thead>
Istantanee<\/td>Stesso volume dell'ospite<\/td>Un aggiornamento errato o un errore all'interno del sistema guest<\/td><\/tr>
Replicazione (VMM Pro)<\/td>Un altro NAS nel cluster<\/td>Un NAS si guasta, ma il ripristino \u00e8 rapido sull'altro host.<\/td><\/tr>
Esportazione programmata + sincronizzazione cloud<\/td>Un account cloud esterno<\/td>Perdita dell'intero sito: incendio, furto, ransomware sulla LAN<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Abbiamo gi\u00e0 replicato sei ospiti su un host di standby, come descritto nel nostro articolo cluster di macchine virtuali Synology a tre nodi<\/a>. La replica mantiene una copia all'interno dell'edificio. Il livello di esportazione \u00e8 ci\u00f2 che mantiene una copia all'esterno.<\/p>\n\n\n\n

Come funziona l'esportazione pianificata di VMM<\/h2>\n\n\n\n

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. \u00c8 possibile scegliere la cartella di destinazione, la modalit\u00e0 di esportazione, la frequenza (giornaliera, settimanale o mensile) e il numero di file pi\u00f9 recenti da conservare. Le esportazioni vengono eseguite mentre la macchina virtuale \u00e8 in esecuzione.<\/p>\n\n\n\n

Due regole sono facili da dimenticare. Innanzitutto, l'esportazione \u00e8 configurata e scritta sull'host dove si trova l'ospite magazzinaggio<\/strong> La configurazione dipende dall'host di archiviazione, non dal luogo in cui il sistema \u00e8 in esecuzione. In un cluster, una macchina virtuale pu\u00f2 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.<\/p>\n\n\n\n

\"Impostazioni
Le nostre impostazioni di esportazione programmata: una cartella condivisa come destinazione, ogni giorno alle 08:00, conservando i tre file pi\u00f9 recenti.<\/figcaption><\/figure>\n\n\n\n

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.<\/p>\n\n\n\n

Perch\u00e9 Cloud Sync ignora i file di backup di VMM<\/h2>\n\n\n\n

Il passo successivo pi\u00f9 ovvio \u00e8 stato quello di indicare a Cloud Sync la cartella di esportazione e lasciare che caricasse tutto su Google Drive. Abbiamo fatto esattamente cos\u00ec, ma i file di backup di VMM non sono mai arrivati.<\/p>\n\n\n\n

Il motivo risiede nel nome del file. Virtual Machine Manager assegna a ogni file esportato un timestamp che contiene i due punti:<\/p>\n\n\n\n

exp_web-2026-09-25 10:29:51-6f713905-cee2-4647-94d5-a5ce6fbdc585.ova<\/code><\/pre>\n\n\n\n
Cloud Sync non caricava quei nomi su Google Drive, quindi ogni esportazione rimaneva locale. Il file \u00e8 valido; il problema \u00e8 il carattere. Poich\u00e9 il formato del timestamp di esportazione non pu\u00f2 essere modificato in Virtual Machine Manager, la correzione deve avvenire tra l'esportazione e il caricamento.<\/p>\n\n\n\n
\u00c8 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<\/code>, e Cloud Sync lo carica senza problemi. Ecco perch\u00e9 un rapido test manuale pu\u00f2 far sembrare che l'intera catena funzioni correttamente, mentre la pianificazione notturna non raggiunge mai il cloud.<\/p>\n\n\n\n
Configurare un backup VMM su Google Drive in 4 passaggi<\/h2>\n\n\n\n
Questa \u00e8 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.<\/p>\n\n\n
\n
\n\n<\/div>\n\n
\n
\n
Pianifica l'esportazione<\/h3>\n
Sul server host che ospita la macchina virtuale, apri Virtual Machine Manager, seleziona la macchina virtuale, scegli Azione, Esporta, Pianifica, seleziona una cartella condivisa come destinazione e imposta l'ora. Lascia invariato il numero di copie che desideri conservare localmente.<\/p>\n<\/div>\n<\/div>\n
\n
Crea l'attivit\u00e0 di sincronizzazione cloud<\/h3>\n
In Cloud Sync, collega Google Drive e sincronizza la cartella condivisa esportata con una cartella di Drive. Imposta la direzione per caricare le modifiche locali e seleziona l'opzione per non rimuovere i file nella destinazione quando vengono rimossi nell'origine, se desideri che il cloud conservi le copie precedenti.<\/p>\n<\/div>\n<\/div>\n
\n
Aggiungi lo script di rinomina<\/h3>\n
Salva lo script di questo articolo sul NAS e crea un'attivit\u00e0 in Utilit\u00e0 di pianificazione che lo esegua come root ogni ora. Lo script rinomina le esportazioni completate senza i due punti e conserva le copie pi\u00f9 recenti per ogni macchina virtuale.<\/p>\n<\/div>\n<\/div>\n
\n
Verifica il primo caricamento<\/h3>\n
Dopo la successiva esportazione, verifica che il file rinominato appaia nella cartella di esportazione, che Cloud Sync lo segnali come caricato e che la dimensione del file in Google Drive corrisponda a quella originale.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n\n\n\n\n\n\n
\"Impostazioni
Il nostro compito di sincronizzazione cloud: caricare solo le modifiche locali, con l'opzione selezionata in modo che Google Drive mantenga le esportazioni anche dopo che il NAS le ha eliminate.<\/figcaption><\/figure>\n\n\n\n
Lo script di rinomina alla base del nostro backup VMM<\/h2>\n\n\n\n
Lo script \u00e8 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\u00f9 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.<\/p>\n\n\n\n
#!\/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\u00e0 i nomi contenenti ":", il che significa anche che non tocca mai un'esportazione che \u00e8 ancora in fase di scrittura. Una volta terminata un'esportazione, la rinomina nel posto in cui ":" \u00e8 sostituito da "-" in modo che Cloud Sync la rilevi, quindi mantiene solo le esportazioni rinominate pi\u00f9 recenti per guest. (La conservazione di VMM non pu\u00f2 pi\u00f9 vedere i file rinominati, quindi la conservazione viene eseguita qui.) Utilizzo: vm-export-cloud.sh EXPORT_DIR KEEP [--apply] Senza --apply stampa solo ci\u00f2 che farebbe. set -u DIR={1:?EXPORT_DIR}; KEEP={2:?KEEP}; APPLY={3:-} MIN_AGE_MIN=15 # un'esportazione completata \u00e8 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\u00ec "salta (in uso): $(nome base "$f")"; continua fi nuovo="$DIR\/$(nome base "$f" | tr ':' '-')" d\u00ec "rinomina: $(nome base "$f") -> $(nome base "$new")" esegui mv -n "$f" "$new" fatto # 2. mantieni le esportazioni rinominate pi\u00f9 recenti per guest (il timestamp \u00e8 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\u00f9 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"}')"\"<\/code><\/pre>\n\n\n\n
Eseguilo prima senza l'ultimo argomento. In questa modalit\u00e0, stamper\u00e0 solo ci\u00f2 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\u00e0 di pianificazione viene eseguito ogni ora come root con un comando simile a questo, un processo per ogni cartella di esportazione:<\/p>\n\n\n\n
bash \/volume1\/@vm-export-cloud\/vm-export-cloud.sh "\/volume3\/VM_BK_Export" 3 --apply<\/code><\/pre>\n\n\n\n
Un utile effetto collaterale della regola dei due punti: Cloud Sync non pu\u00f2 caricare un'esportazione finch\u00e9 lo script non l'ha rinominata, e lo script rinomina solo i file completati. Le esportazioni incomplete non raggiungono mai il cloud.<\/p>\n\n\n\n
Perch\u00e9 lo script gestisce la conservazione dei backup di VMM<\/h2>\n\n\n\n
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\u00f9 e non lo eliminer\u00e0 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.<\/p>\n\n\n\n
Per quanto riguarda la sincronizzazione cloud, una casella di controllo determina cosa succede in Google Drive. La sua formulazione \u00e8 facile da fraintendere: Non eliminare i file nella cartella di destinazione quando vengono eliminati nella cartella di origine.<\/strong>. Se la casella non \u00e8 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\u00f9 sicura contro i ransomware, ma il contenuto tende a crescere fino a quando non viene eliminato manualmente.<\/p>\n\n\n\n
Cosa ha rivelato un audit sulle nostre esportazioni<\/h2>\n\n\n\n
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\u00e9 della dashboard ha rivelato tre errori distinti.<\/p>\n\n\n\n