VMM-Backup zu Google Drive: Geplanter Export, Cloud-Synchronisierung und One-Rename-Skript

Ein VMM-Backup, das nur auf demselben NAS wie die virtuelle Maschine gespeichert ist, ist eigentlich kein richtiges Backup. Fällt dieses NAS aus, sind beide Kopien verloren. Dieser Speicher läuft 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ötzlich nicht mehr funktionierte, dauerte länger, 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 Überprüfung unserer eigenen Exporte.

SynoPower Club-Punkt: Jeder Support-Techniker kennt Geschichten von Kunden, deren Backups ein Jahr lang einwandfrei liefen und nichts wiederherstellten. Ich hätte nie gedacht, dass wir so etwas mal über unsere eigene Firma schreiben würden. Unser VMM-Backup-Job sah in der Benutzeroberfläche tadellos aus, doch auf einem Host hatte sich ein Terabyte an Exporten angehäuft, das er nie löschen 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: Überprüfen Sie regelmäßig, ob die Dateien tatsächlich dort vorhanden sind, wo Sie sie vermuten – wie bei jedem anderen Job auch.

Was eine vollständige VMM-Sicherung benötigt #

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

Schicht	Wo sich die Kopie befindet	Wovor es schützt
Schnappschüsse	Gleiche Lautstärke wie beim Gast	Ein fehlerhaftes Update oder ein Fehler im Gastsystem
Replikation (VMM Pro)	Ein weiteres NAS im Cluster	Ein NAS-System fällt aus, die Wiederherstellung erfolgt jedoch schnell auf dem anderen Host.
Geplanter Export + Cloud-Synchronisierung	Ein Cloud-Konto außerhalb des Standorts	Totalausfall des Standorts: Feuer, Diebstahl, Ransomware im LAN

Wir replizieren bereits sechs Gäste auf einem Standby-Host, wie in unserem Bericht über die Drei-Knoten-Synology-VM-Cluster. Die Replikation speichert eine Kopie innerhalb des Gebäudes. Die Exportschicht speichert eine Kopie außerhalb des Gebäudes.

So funktioniert der geplante Export in VMM #

Bei einer VMM-Sicherung wird durch den geplanten Export eine vollständige Kopie des Gastsystems, der Festplatten und der Konfiguration als einzelne OVA-Datei in einem freigegebenen Ordner gespeichert. Sie wählen den Zielordner, den Exportmodus, das Exportintervall (täglich, wöchentlich oder monatlich) und die Anzahl der zu speichernden Dateien. Der Export erfolgt, während das Gastsystem ausgeführt wird.

Zwei Regeln werden leicht übersehen. Erstens wird der Export auf dem Host konfiguriert und geschrieben, auf dem sich der Gast befindet. Lagerung Es kommt auf den Speicherort an, nicht darauf, wo er ausgeführt wird. In einem Cluster kann ein Gastsystem auf einem NAS laufen, während sich seine Festplatten auf einem anderen befinden. In diesem Fall ist die Option für den geplanten Export auf dem falschen Host deaktiviert. Außerdem verwendet der Zeitplan die Uhr des Speicherhosts.

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ür die meisten Workloads ist das ausreichend; die Installation des Guest Tools verbessert den Status auf Dateisystemkonsistenz.

Warum Cloud Sync VMM-Sicherungsdateien überspringt #

Der nächste logische Schritt wäre 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.

Der Grund liegt im Dateinamen. Virtual Machine Manager vergibt für jeden Export einen Zeitstempel, der Doppelpunkte enthält:

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

Cloud Sync lud diese Dateinamen nicht in unser Google Drive hoch, daher blieben alle Exporte lokal. Die Datei selbst ist gültig; das Problem liegt an dem Zeichen. Da das Format des Export-Zeitstempels in Virtual Machine Manager nicht geändert werden kann, muss die Korrektur zwischen Export und Upload erfolgen.

Interessanterweise enthalten nur geplante Exporte einen Zeitstempel. Ein manueller Export aus demselben Menü wird einfach unter dem Namen des Gastes gespeichert, z. B. spc_4C8G.ova, Cloud Sync lädt die Daten problemlos hoch. Deshalb kann ein kurzer manueller Test den Eindruck erwecken, die gesamte Kette sei in Ordnung, obwohl der nächtliche Zeitplan die Cloud nie erreicht.

Einrichten einer VMM-Sicherung auf Google Drive in 4 Schritten #

Dies ist die funktionierende VMM-Backup-Konfiguration auf jedem Host, der Gastsysteme speichert. Sie benötigt Virtual Machine Manager, Cloud Sync und ein Google-Konto; VMM Pro wird dafür nicht benötigt.

Das Umbenennungsskript hinter unserem VMM-Backup #

Das Skript ist das einzige benutzerdefinierte Element der VMM-Backup-Kette und erfüllt 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 ändert nur Dateien, die seit 15 Minuten unverändert sind, sodass ein Export, der noch geschrieben wird, niemals umbenannt wird.

#!/bin/bash # vm-export-cloud.sh - VMM-Exporte für Cloud Sync hochladbar machen. # # VMM-Namen für Exporte " -YYYY-MM-DD HH:MM:SS- Cloud Sync lädt 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ält 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ührt 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"}')""

Führen Sie den Befehl zunächst ohne das letzte Argument aus. In diesem Modus werden nur die Elemente ausgegeben, die umbenannt und gelöscht würden. Sobald die Ausgabe korrekt aussieht, planen Sie den Vorgang mit dem zusätzlichen Argument, das die Ausführung auslöst. Unser Task-Scheduler-Job wird stündlich als Root mit einem Befehl wie diesem ausgeführt, ein Job pro Exportordner:

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

Ein nützlicher 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ändige Exporte erreichen die Cloud daher nie.

Warum das Skript die Aufbewahrung von VMM-Backups verwaltet #

Virtual Machine Manager verfügt über eine eigene Aufbewahrungseinstellung und protokolliert jeden erstellten Export. Sobald das Skript eine Datei umbenennt, erkennt Virtual Machine Manager diese nicht mehr und löscht sie auch nicht. Die Aufbewahrung wird daher vom Skript selbst gesteuert, das die Kopien pro Gast anhand des Zeitstempels im Dateinamen zählt.

Bei der Cloud-Synchronisierung legt ein einziges Kontrollkästchen fest, was in Google Drive geschieht. Die Formulierung ist leicht misszuverstehen: Dateien im Zielordner dürfen nicht gelöscht werden, wenn sie im Quellordner gelöscht wurden.. Wenn Sie die Option deaktiviert lassen, spiegelt Google Drive das NAS und behält dieselben drei Kopien bei. Aktivieren Sie sie, speichert die Cloud alle jemals hochgeladenen Exporte. Dies ist zwar sicherer gegen Ransomware, wächst aber mit der Zeit, bis Sie die Daten manuell löschen.

Was eine Prüfung unserer eigenen Exporte ergab #

Vor dieser Konfiguration lief unsere VMM-Sicherung etwa einen Monat lang auf beiden Produktionshosts. Die Überprüfung der Dateien anstelle des Dashboards ergab drei separate Fehler.

• Die Datenspeicherung wurde auf einem Host stillschweigend unterbrochen. Die kleine Datenbank, die Virtual Machine Manager zur Exportverfolgung verwendet, konnte im Exportordner nicht erstellt werden. Daher wurde bei jedem Lauf ein Fehler protokolliert und kein alter Export gelöscht. Auf einem Host sammelten sich ein Terabyte an OVA-Dateien an, und der Speicherplatz war mit 97% voll.
• Der größte Gast stellte die Exporte ein. Der 84 GB große Export passte nicht mehr in den verbleibenden Speicherplatz, sodass er drei Tage hintereinander ohne jegliche Warnung fehlschlug.
• Drei Zeitpläne, die ins Leere führen. Durch eine Einstellungsänderung blieben drei Exportpläne ohne Zielverzeichnis. Seitdem wurde jede Minute, insgesamt über 20.000 Mal, ein ungültiger Freigabename protokolliert, und es wurden keine Daten exportiert, auch nicht der Plan für diesen Shop.

Im Normalbetrieb traten keine VMM-Backup-Fehler auf. Die Gastsysteme liefen, der Shop nahm Bestellungen entgegen und die Replikation hielt eine Kopie auf dem Standby-Host aufrecht. Lediglich die Exportschicht, die einzige externe Kopie, war ausgefallen. Wir überprüfen nun nach jeder Zeitplanänderung die Exportordner und die Cloud-Sync-Uploadliste.

Bandbreiten- und Speicherplanung für ein VMM-Backup #

Jeder VMM-Backup-Export ist eine vollständige Kopie, keine inkrementelle. Legen Sie daher die Größe der Backups fest, bevor Sie einen Zeitplan auswählen. Unsere Kunden haben unterschiedliche Datenmengen, von kleinen Websites mit 5 GB bis hin zu Partner-Websites mit 84 GB. Der Export dieses Shops selbst umfasst etwa 7 GB. Bei allen Kunden werden mit einem täglichen Zeitplan deutlich über 100 GB pro Tag hochgeladen.

Google Drive erlaubt jedem Nutzer das Hochladen von 750 GB innerhalb von 24 Stunden, wobei Dateien bis zu 5 TB groß sein können. Das Limit ist daher selten das Problem. Vielmehr sind es die Uploadzeit und der verfügbare Cloud-Speicher. Um drei Kopien jedes Gastsystems in der Cloud zu speichern, wird das Dreifache des täglich verfügbaren Drive-Speicherplatzes benötigt – und noch mehr, wenn jede Kopie in der Cloud gespeichert wird. Bei großen, sich nur langsam ändernden Gastsystemen reicht oft ein wöchentlicher Export aus, insbesondere wenn die Replikation bereits die tägliche Wiederherstellung abdeckt.

Warum wir Backups mit Synology-Tools erstellen #

Alle Komponenten dieser VMM-Backup-Kette werden mit DSM ausgeliefert. Virtual Machine Manager exportiert die virtuellen Maschinen, Cloud Sync lädt sie hoch, der Taskplaner führt das Skript aus, und dieselben NAS-Geräte speichern unsere Dateien und betreiben den Speicher. Es ist kein Backup-Agent pro virtueller Maschine lizenzierbar und kein separater Backup-Server zu warten.

Die Komponenten, für die wir bezahlen, sind diejenigen, die den Schutz zwischen den Hosts verbessern: a VMM Pro-Lizenz zur Replikation auf den Standby-Server und Virtual DSM-Lizenzen für die zusätzlichen DSM-Gäste. Wenn Sie sich entscheiden müssen, welche Edition Sie benötigen, unsere Vergleich von Virtual Machine Manager und VMM Pro deckt es ab.

VMM-Backup-Grenzen und Einschränkungen #

Ein Export ist eine vollständige Kopie zu einem bestimmten Zeitpunkt. Ohne das Gast-Tool ist er absturzsicher, sodass sich Datenbanken innerhalb des Gastsystems wie nach einem Stromausfall wiederherstellen lassen. Testen Sie die Wiederherstellung Ihres wichtigsten Gastsystems mindestens einmal.

Das Wiederherstellen eines VMM-Backups aus der Cloud erfordert den vorherigen Download der gesamten Datei. Ein 84 GB großer Export dauert über eine typische Büroverbindung Stunden. Daher ist die Cloud-Kopie eher für Notfälle als für alltägliche Fehler gedacht. Snapshots und Replikation bewältigen solche Fälle deutlich schneller.

Cloud Sync kann Dateien vor dem Hochladen verschlüsseln. Wir empfehlen, diese Funktion für Gäste zu aktivieren, die Kundendaten speichern. Bewahren Sie das Verschlüsselungspasswort an einem Ort auf, der nicht mit dem zu schützenden NAS-System verbunden ist.

Schließlich hängt das Umbenennungsskript vom Exportnamensformat ab. Sollte ein zukünftiges Virtual Machine Manager-Update dieses Format ändern, kann das Skript die Dateien nicht mehr zuordnen. Der Testlauf ist der schnellste Weg, um zu überprüfen, ob Ihre Exporte nach einem Update weiterhin erkannt werden.

Häufig gestellte Fragen #

Referenzen und Video-Anleitungen #

• Virtuelle Maschine in Virtual Machine Manager, der Wissenszentrumsartikel zum Thema Export.
• Hilfe zur Cloud-Synchronisierung, einschließlich Synchronisierungsrichtung und Aufgabeneinstellungen.
• Speicher- und Uploadbeschränkungen bei Google Drive, mit dem täglichen Uploadlimit von 750 GB.
• Synology VMM Whitepaper, über Datenschutzebenen für virtuelle Maschinen.
• Aufgabenplaner in DSM, um das Umbenennungsskript als geplante Aufgabe auszuführen.

Videos zu den Tools in dieser Kette: Cloud Sync sowie Exportieren und Migrieren von virtuellen Maschinen auf einem Synology NAS.

Möchten Sie zusätzlich zu Ihrer externen Kopie eine Replikation zwischen Hosts einrichten? Holen Sie sich einen VMM Pro-Lizenz, Oder lesen Sie, wie der Rest dieser Website funktioniert. unsere NAS-Hosting-101-Reihe.