{"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\/de\/docs\/vmm-backup-google-drive-cloud-sync\/","title":{"rendered":"VMM-Backup zu Google Drive: Geplanter Export, Cloud-Synchronisierung und One-Rename-Skript"},"content":{"rendered":"

Ein VMM-Backup, das nur auf demselben NAS wie die virtuelle Maschine gespeichert ist, ist eigentlich kein richtiges Backup. F\u00e4llt dieses NAS aus, sind beide Kopien verloren. Dieser Speicher l\u00e4uft als Virtual DSM-Gast in Synology und Virtual Machine Manager, und unser externes VMM-Backup basiert auf zwei kostenlosen Tools, die mit DSM mitgeliefert werden: dem geplanten Export in Virtual Machine Manager und der Cloud-Synchronisierung mit Google Drive. Die Einrichtung dauerte einen Nachmittag. Die Fehlersuche, warum es pl\u00f6tzlich nicht mehr funktionierte, dauerte l\u00e4nger, und genau deshalb gibt es diesen Artikel zum Thema NAS-Hosting. Im Folgenden finden Sie die funktionierende Konfiguration, die eine Dateinamen-Besonderheit, die Probleme verursacht, das kleine Skript zur Behebung des Problems und die Ergebnisse einer \u00dcberpr\u00fcfung unserer eigenen Exporte.<\/p>\n\n\n\n

\n

SynoPower Club-Punkt:<\/strong> Jeder Support-Techniker kennt Geschichten von Kunden, deren Backups ein Jahr lang einwandfrei liefen und nichts wiederherstellten. Ich h\u00e4tte nie gedacht, dass wir so etwas mal \u00fcber unsere eigene Firma schreiben w\u00fcrden. Unser VMM-Backup-Job sah in der Benutzeroberfl\u00e4che tadellos aus, doch auf einem Host hatte sich ein Terabyte an Exporten angeh\u00e4uft, das er nie l\u00f6schen konnte, und der andere hatte dreizehn Tage lang keine einzige Datei erstellt. Nichts war versteckt. Alles stand in einem Log, das niemand liest. Die Behebung des Problems dauerte eine Stunde; die Lehre daraus: \u00dcberpr\u00fcfen Sie regelm\u00e4\u00dfig, ob die Dateien tats\u00e4chlich dort vorhanden sind, wo Sie sie vermuten \u2013 wie bei jedem anderen Job auch.<\/p>\n<\/blockquote>\n\n\n\n

Was eine vollst\u00e4ndige VMM-Sicherung ben\u00f6tigt<\/h2>\n\n\n\n

Virtual Machine Manager bietet Ihnen drei Schutzebenen, wobei jede einen anderen Fehlertyp abdeckt. Ein solider VMM-Backup-Plan verwendet mehr als eine solche Ebene.<\/p>\n\n\n\n

Schicht<\/th>Wo sich die Kopie befindet<\/th>Wovor es sch\u00fctzt<\/th><\/tr><\/thead>
Schnappsch\u00fcsse<\/td>Gleiche Lautst\u00e4rke wie beim Gast<\/td>Ein fehlerhaftes Update oder ein Fehler im Gastsystem<\/td><\/tr>
Replikation (VMM Pro)<\/td>Ein weiteres NAS im Cluster<\/td>Ein NAS-System f\u00e4llt aus, die Wiederherstellung erfolgt jedoch schnell auf dem anderen Host.<\/td><\/tr>
Geplanter Export + Cloud-Synchronisierung<\/td>Ein Cloud-Konto au\u00dferhalb des Standorts<\/td>Totalausfall des Standorts: Feuer, Diebstahl, Ransomware im LAN<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Wir replizieren bereits sechs G\u00e4ste auf einem Standby-Host, wie in unserem Bericht \u00fcber die Drei-Knoten-Synology-VM-Cluster<\/a>. Die Replikation speichert eine Kopie innerhalb des Geb\u00e4udes. Die Exportschicht speichert eine Kopie au\u00dferhalb des Geb\u00e4udes.<\/p>\n\n\n\n

So funktioniert der geplante Export in VMM<\/h2>\n\n\n\n

Bei einer VMM-Sicherung wird durch den geplanten Export eine vollst\u00e4ndige Kopie des Gastsystems, der Festplatten und der Konfiguration als einzelne OVA-Datei in einem freigegebenen Ordner gespeichert. Sie w\u00e4hlen den Zielordner, den Exportmodus, das Exportintervall (t\u00e4glich, w\u00f6chentlich oder monatlich) und die Anzahl der zu speichernden Dateien. Der Export erfolgt, w\u00e4hrend das Gastsystem ausgef\u00fchrt wird.<\/p>\n\n\n\n

Zwei Regeln werden leicht \u00fcbersehen. Erstens wird der Export auf dem Host konfiguriert und geschrieben, auf dem sich der Gast befindet. Lagerung<\/strong> Es kommt auf den Speicherort an, nicht darauf, wo er ausgef\u00fchrt wird. In einem Cluster kann ein Gastsystem auf einem NAS laufen, w\u00e4hrend sich seine Festplatten auf einem anderen befinden. In diesem Fall ist die Option f\u00fcr den geplanten Export auf dem falschen Host deaktiviert. Au\u00dferdem verwendet der Zeitplan die Uhr des Speicherhosts.<\/p>\n\n\n\n

\"VMM-Backup-Einstellungen
Unsere geplanten Exporteinstellungen: ein freigegebener Ordner als Ziel, t\u00e4glich um 08:00 Uhr, wobei die drei neuesten Dateien beibehalten werden.<\/figcaption><\/figure>\n\n\n\n

Der Dialog zeigt auch den konsistenten Status an. Ohne das Synology Guest Tool im Gastsystem sind Exporte absturzkonsistent, also identisch mit dem Zustand nach dem Ziehen des Netzsteckers. F\u00fcr die meisten Workloads ist das ausreichend; die Installation des Guest Tools verbessert den Status auf Dateisystemkonsistenz.<\/p>\n\n\n\n

Warum Cloud Sync VMM-Sicherungsdateien \u00fcberspringt<\/h2>\n\n\n\n

Der n\u00e4chste logische Schritt w\u00e4re gewesen, Cloud Sync auf den Exportordner zu verweisen und alles zu Google Drive hochladen zu lassen. Genau das haben wir getan, aber die VMM-Sicherungsdateien sind nie angekommen.<\/p>\n\n\n\n

Der Grund liegt im Dateinamen. Virtual Machine Manager vergibt f\u00fcr jeden Export einen Zeitstempel, der Doppelpunkte enth\u00e4lt:<\/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 lud diese Dateinamen nicht in unser Google Drive hoch, daher blieben alle Exporte lokal. Die Datei selbst ist g\u00fcltig; das Problem liegt an dem Zeichen. Da das Format des Export-Zeitstempels in Virtual Machine Manager nicht ge\u00e4ndert werden kann, muss die Korrektur zwischen Export und Upload erfolgen.<\/p>\n\n\n\n
Interessanterweise enthalten nur geplante Exporte einen Zeitstempel. Ein manueller Export aus demselben Men\u00fc wird einfach unter dem Namen des Gastes gespeichert, z. B. spc_4C8G.ova<\/code>, Cloud Sync l\u00e4dt die Daten problemlos hoch. Deshalb kann ein kurzer manueller Test den Eindruck erwecken, die gesamte Kette sei in Ordnung, obwohl der n\u00e4chtliche Zeitplan die Cloud nie erreicht.<\/p>\n\n\n\n
Einrichten einer VMM-Sicherung auf Google Drive in 4 Schritten<\/h2>\n\n\n\n
Dies ist die funktionierende VMM-Backup-Konfiguration auf jedem Host, der Gastsysteme speichert. Sie ben\u00f6tigt Virtual Machine Manager, Cloud Sync und ein Google-Konto; VMM Pro wird daf\u00fcr nicht ben\u00f6tigt.<\/p>\n\n\n
\n
\n\n<\/div>\n\n
\n
\n
Planen Sie den Export<\/h3>\n
\u00d6ffnen Sie auf dem Host, auf dem der Gast gespeichert ist, Virtual Machine Manager, w\u00e4hlen Sie den Gast aus, klicken Sie auf \u201eAktion\u201c, \u201eExportieren\u201c, \u201eGeplant\u201c, w\u00e4hlen Sie einen freigegebenen Ordner als Ziel und legen Sie die Zeit fest. Belassen Sie die Aufbewahrungseinstellung bei der Anzahl der Kopien, die Sie lokal speichern m\u00f6chten.<\/p>\n<\/div>\n<\/div>\n
\n
Erstellen Sie die Cloud-Synchronisierungsaufgabe<\/h3>\n
Verbinden Sie in Cloud Sync Google Drive und synchronisieren Sie den freigegebenen Exportordner mit einem Drive-Ordner. Legen Sie fest, dass lokale \u00c4nderungen hochgeladen werden sollen, und aktivieren Sie die Option, Dateien im Zielverzeichnis nicht zu l\u00f6schen, wenn sie im Quellverzeichnis gel\u00f6scht werden, falls \u00e4ltere Kopien in der Cloud erhalten bleiben sollen.<\/p>\n<\/div>\n<\/div>\n
\n
F\u00fcge das Umbenennungsskript hinzu.<\/h3>\n
Speichern Sie das Skript aus diesem Artikel auf dem NAS und erstellen Sie einen Taskplaner-Auftrag, der es st\u00fcndlich als Root ausf\u00fchrt. Es benennt abgeschlossene Exporte ohne Doppelpunkte um und beh\u00e4lt die jeweils neueste Kopie pro Gastsystem bei.<\/p>\n<\/div>\n<\/div>\n
\n
\u00dcberpr\u00fcfen Sie den ersten Upload.<\/h3>\n
Pr\u00fcfen Sie nach dem n\u00e4chsten Export, ob die umbenannte Datei im Exportordner angezeigt wird, ob Cloud Sync sie als hochgeladen meldet und ob die Dateigr\u00f6\u00dfe in Google Drive mit dem Original \u00fcbereinstimmt.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n\n\n\n\n\n\n
\"Cloud-Synchronisierungsaufgabeneinstellungen
Unsere Cloud-Synchronisierungsaufgabe: Nur lokale \u00c4nderungen hochladen, wobei die Option aktiviert ist, damit Google Drive die Exporte beh\u00e4lt, nachdem das NAS sie gel\u00f6scht hat.<\/figcaption><\/figure>\n\n\n\n
Das Umbenennungsskript hinter unserem VMM-Backup<\/h2>\n\n\n\n
Das Skript ist das einzige benutzerdefinierte Element der VMM-Backup-Kette und erf\u00fcllt zwei Funktionen: Es benennt jeden abgeschlossenen Export um, indem es Doppelpunkte durch Bindestriche ersetzt, und speichert im Exportordner nur die jeweils neueste Kopie jedes Gastsystems. Es \u00e4ndert nur Dateien, die seit 15 Minuten unver\u00e4ndert sind, sodass ein Export, der noch geschrieben wird, niemals umbenannt wird.<\/p>\n\n\n\n
#!\/bin\/bash # vm-export-cloud.sh - VMM-Exporte f\u00fcr Cloud Sync hochladbar machen. # # VMM-Namen f\u00fcr Exporte " -YYYY-MM-DD HH:MM:SS- Cloud Sync l\u00e4dt keine Dateien mit der Endung .ova hoch, die ein "":"" enthalten. Das bedeutet auch, dass Exporte, die noch geschrieben werden, nicht bearbeitet werden. Sobald ein Export abgeschlossen ist, wird er direkt umbenannt, wobei "":"" durch "-" ersetzt wird. Cloud Sync erkennt die neue Datei und beh\u00e4lt nur die jeweils neueste umbenannte Exportdatei pro Gast. (Die Aufbewahrungsfunktion von VMM kann umbenannte Dateien nicht mehr erkennen, daher erfolgt die Aufbewahrung hier.) Verwendung: vm-export-cloud.sh EXPORT_DIR KEEP [--apply] Ohne die Option --apply wird nur die eigentliche Aktion ausgegeben. set -u DIR={1:?EXPORT_DIR}; KEEP={2:?KEEP}; APPLY={3:-} MIN_AGE_MIN=15 # Ein abgeschlossener Export ist so lange unber\u00fchrt 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 "ERROR export folder missing: $DIR"; exit 1; } # 1. Umbenennen abgeschlossene Exporte finden "$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. keep the latest KEEP umbenannte Exporte pro Gast (Zeitstempel ist im Namen) { 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 say "delete (beyond latest $KEEP): $old" run rm -f -- "$DIR\/$old" done say "done: $(find "$DIR" -maxdepth 1 -name '*.ova' | wc -l) exports in $DIR, $(df -h "$DIR" | awk 'NR==2{print $4" free"}')"\"<\/code><\/pre>\n\n\n\n
F\u00fchren Sie den Befehl zun\u00e4chst ohne das letzte Argument aus. In diesem Modus werden nur die Elemente ausgegeben, die umbenannt und gel\u00f6scht w\u00fcrden. Sobald die Ausgabe korrekt aussieht, planen Sie den Vorgang mit dem zus\u00e4tzlichen Argument, das die Ausf\u00fchrung ausl\u00f6st. Unser Task-Scheduler-Job wird st\u00fcndlich als Root mit einem Befehl wie diesem ausgef\u00fchrt, ein Job pro Exportordner:<\/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
Ein n\u00fctzlicher Nebeneffekt der Doppelpunktregel: Cloud Sync kann einen Export erst hochladen, nachdem das Skript ihn umbenannt hat, und das Skript benennt nur fertige Dateien um. Unvollst\u00e4ndige Exporte erreichen die Cloud daher nie.<\/p>\n\n\n\n
Warum das Skript die Aufbewahrung von VMM-Backups verwaltet<\/h2>\n\n\n\n
Virtual Machine Manager verf\u00fcgt \u00fcber eine eigene Aufbewahrungseinstellung und protokolliert jeden erstellten Export. Sobald das Skript eine Datei umbenennt, erkennt Virtual Machine Manager diese nicht mehr und l\u00f6scht sie auch nicht. Die Aufbewahrung wird daher vom Skript selbst gesteuert, das die Kopien pro Gast anhand des Zeitstempels im Dateinamen z\u00e4hlt.<\/p>\n\n\n\n
Bei der Cloud-Synchronisierung legt ein einziges Kontrollk\u00e4stchen fest, was in Google Drive geschieht. Die Formulierung ist leicht misszuverstehen: Dateien im Zielordner d\u00fcrfen nicht gel\u00f6scht werden, wenn sie im Quellordner gel\u00f6scht wurden.<\/strong>. Wenn Sie die Option deaktiviert lassen, spiegelt Google Drive das NAS und beh\u00e4lt dieselben drei Kopien bei. Aktivieren Sie sie, speichert die Cloud alle jemals hochgeladenen Exporte. Dies ist zwar sicherer gegen Ransomware, w\u00e4chst aber mit der Zeit, bis Sie die Daten manuell l\u00f6schen.<\/p>\n\n\n\n
Was eine Pr\u00fcfung unserer eigenen Exporte ergab<\/h2>\n\n\n\n
Vor dieser Konfiguration lief unsere VMM-Sicherung etwa einen Monat lang auf beiden Produktionshosts. Die \u00dcberpr\u00fcfung der Dateien anstelle des Dashboards ergab drei separate Fehler.<\/p>\n\n\n\n