VMWARE → STACKIT · BACKUP-CHECKLISTE
Backup-, Snapshot- und Restore-Planung von VMware nach STACKIT
VMware-Snapshots wandern nicht mit, und ein Backup, das auf der alten Plattform funktionierte, ist auf der neuen nicht automatisch eines. Diese Checkliste führt durch Bestandsaufnahme, Design, Aufbau, Daten, Cutover und Nachbereitung und nennt zu jedem Punkt die Datei eines StackToIT-Laufs oder das Blatt Ihres RVTools-Exports, in der die Antwort steht. Die Demo ist ein Export mit acht Maschinen und vier Snapshots.
Was der Lauf über Snapshots weiß und was nicht
Ein RVTools-Export mit acht Maschinen, für diese Seite geschrieben und am 4. November 2026 von StackToIT bewertet, mit den Blättern vSnapshot und vMemory. Links das Blatt vSnapshot, rechts die Snapshot-Befunde in assessment.json (Befund-Kennungen ausgelassen).
VM,Name,Description,Date / time,Filename,Size MiB (vmsn),Size MiB (total),Quiesced,State,VM UUID
db-pg01,before-upgrade-15,Before PostgreSQL 15 minor upgrade,2026-06-02 21:14:00,[ds-core-01] db-pg01/db-pg01-Snapshot1.vmsn,33000,48200,False,poweredOn,8004-eeee-0001
db-pg01,pre-reindex,Before reindex,2026-09-18 22:03:00,[ds-core-01] db-pg01/db-pg01-Snapshot2.vmsn,33000,131400,True,poweredOn,8004-eeee-0001
file01,Backup-test,Restore test,2026-10-30 08:20:00,[ds-core-01] file01/file01-Snapshot1.vmsn,8200,9100,True,poweredOn,8004-eeee-0005
test-clone07,VM Snapshot 3/12/2026,,2026-03-12 11:00:00,[ds-core-01] test-clone07/test-clone07-Snapshot1.vmsn,4100,22500,False,poweredOff,8004-eeee-0008[
{
"id": "vm.db-pg01",
"findings": [
{
"severity": "info",
"message": "The VM has snapshots; consolidate them before export — only the current state is migrated."
}
]
},
{
"id": "vm.file01",
"findings": [
{
"severity": "info",
"message": "The VM has snapshots; consolidate them before export — only the current state is migrated."
}
]
},
{
"id": "vm.test-clone07",
"findings": [
{
"severity": "info",
"message": "The VM has snapshots; consolidate them before export — only the current state is migrated."
}
]
}
]Anzahl je Maschine
Der Lauf fand 4 Snapshots auf 3 der 8 Maschinen und vermerkt bei jeder der drei einen Hinweis: vor dem Export konsolidieren, migriert wird nur der aktuelle Stand.
Alter, Größe und Quiesce stehen nicht im Hinweis
Der Hinweis ist derselbe für einen Snapshot von 5 und einen von 237 Tagen. Datum, Gesamtgröße und Quiesce-Status stehen im Blatt. Lesen Sie es selbst.
Gegen die Empfehlung des Herstellers
Broadcom rät, einen einzelnen Snapshot nicht länger als 72 Stunden zu behalten. Am 4. November 2026 sind die vier Snapshots 155, 47, 5 und 237 Tage alt, und der größte meldet insgesamt 131400 MiB.
Der Backup-Umfang ist die Menge der Volumes im Entwurf
Aus demselben Lauf. Links die beiden Platten von db-pg01, rechts Server und Volume, die die Engine dafür entworfen hat. Der Entwurf enthält keine Backup- oder Snapshot-Ressource.
VM,Disk,Capacity MiB,Raw,Disk Mode,Sharing mode,Thin,Controller,Shared Bus,VM UUID
db-pg01,Hard disk 1,102400,False,persistent,sharingNone,True,SCSI controller 0,noSharing,8004-eeee-0001
db-pg01,Hard disk 2,614400,False,persistent,sharingNone,True,SCSI controller 1,noSharing,8004-eeee-0001resource "stackit_server" "vm_db_pg01" {
project_id = var.project_id
name = "db-pg01"
machine_type = var.vm_db_pg01_machine_type
availability_zone = var.availability_zone
boot_volume = {
source_type = "image"
source_id = var.vm_db_pg01_image_id
size = 100
}
network_interfaces = [stackit_network_interface.vm_db_pg01_nic1.network_interface_id]
}
resource "stackit_volume" "vm_db_pg01_disk2" {
project_id = var.project_id
name = "db-pg01-disk2"
availability_zone = var.availability_zone
size = 600
performance_class = var.vmware_volume_performance_class
}Zwei Volumes zu schützen
Das Boot-Volume mit 100 GiB und das Daten-Volume mit 600 GiB. STACKIT sichert je Volume; beide gehören also in den Zeitplan.
Backups ergänzen Sie selbst
Keine der vier Terraform-Dateien definiert ein Backup. Laut der STACKIT-Seite zu Server Backup Management lässt sich der Dienst auch über die STACKIT CLI und den Terraform-Provider nutzen.
Eine Performance-Klasse
Das Volume liest var.vmware_volume_performance_class, gemeinsam für alle Daten-Volumes. STACKIT hält fest, dass die Dauer von Backup und Restore von Volume-Größe und Performance-Klasse abhängt.
Vier Schutzmechanismen, die ähnlich klingen
| Mechanismus | Was die Dokumentation sagt | Folge für den Plan |
|---|---|---|
| VMware-Snapshot | Broadcom: ein Änderungsprotokoll über den Basisplatten, kein Backup. Nicht länger als 72 Stunden behalten und eine laufende Konsolidierung nicht abbrechen. | Vor dem Export konsolidieren. Den Rückfallpunkt auf der Quellseite planen. |
| STACKIT-Volume-Snapshot | Liegt im selben Primärspeicher wie das Volume, nicht direkt zurückspielbar, höchstens 6 je Volume. | Gut als kurzlebiger Rückfallpunkt. Es ist keine zweite Kopie der Daten. |
| STACKIT-Volume-Backup | Liegt auf einem getrennten Backup-Speichersystem und lässt sich direkt zurückspielen. STACKIT empfiehlt, den Server vorher auszuschalten, sonst ist das Backup absturzkonsistent. | Die Kopie, die gegen den Verlust des Volumes schützt. Entscheiden Sie, wann ein ruhiges Zeitfenster nötig ist. |
| Server Backup Management | Automatisierte, absturzkonsistente Backups mit eigenen Zeitplänen und frei wählbarer Aufbewahrung. Ein Volume-Backup lässt sich in ein neues Volume zurückspielen, um einzelne Dateien zu holen. | Der naheliegende Ort für zeitgesteuerte Backups ganzer Server. Datenbanken brauchen weiterhin ein eigenes Backup. |
Aussagen zu STACKIT geben den Stand November 2026 wieder und folgen der Server-Einführung, den Seiten zu Server Backup Management und der Server-FAQ in den Quellen. Die Server-Einführung vermerkt außerdem, dass die Funktion für Backups und Snapshots noch in das Portal integriert wird, und nennt höchstens 6 Snapshots pro Volume; die IaaS-API-Anleitung zeigt den Weg über die API. Prüfen Sie Grenzwerte erneut, bevor Sie sich darauf verlassen.
1 · Bestandsaufnahme
Beide Blätter sind im Export
vSnapshot und vMemory. Ohne sie warnt der Lauf, dass Snapshots und Speicherreservierung jeder VM unbekannt sind – das heißt nicht, dass es keine gibt. Suchen Sie die Warnung in engineering/architect-report.md.
Jede Maschine mit Snapshot ist aufgeführt
Der Snapshot-Hinweis in assessment.json nennt die Einheiten. Hier: db-pg01 mit zwei, file01 und test-clone07 mit je einem. Jede erhält einen Verantwortlichen und ein Ja oder Nein.
Alter, Größe und Quiesce-Kennzeichen sind aus dem Blatt gelesen
RVTools_tabvSnapshot.csv enthält Datum, Größen und Quiesce-Status. Der Lauf zählt die Snapshots und summiert ihre Größen in den Einheitsdaten von assessment.json (db-pg01: 2 Snapshots, 179600 MiB); seine Hinweise erwähnen sie aber nicht.
Der heutige Schutz ist je Maschine notiert
Werkzeug, Zeitplan, Aufbewahrung und letzter erfolgreicher Restore-Test. RVTools enthält das nicht. Den RPO und die tolerierte Ausfallzeit übernimmt der Lauf nur aus einer Anwendungsdatei, die Sie bereitstellen.
2 · Design
Jede Snapshot-Nutzung hat einen Nachfolger
Rückfall vor Änderungen, Testkopien, Backup aus Gewohnheit. Entscheiden Sie je Nutzung: STACKIT-Volume-Snapshot, Volume-Backup oder nichts.
Das Backup-Werkzeug ist gewählt
Server Backup Management, Ihre vorhandene Backup-Software oder datenbanknahes Backup. STACKIT sagt, dass Datenbanken auf einem Server separat gesichert werden sollten.
Zeitplan und Aufbewahrung je Stufe
Schreiben Sie sie gegen den RPO jeder Anwendung. Server Backup Management erlaubt eigene Zeitpläne und eine frei wählbare Aufbewahrung.
Der Umfang entspricht den Volumes im Entwurf
Vergleichen Sie terraform/compute.tf mit Ihrem Backup-Umfang: jedes Boot-Volume und jedes Daten-Volume, bei db-pg01 zwei.
Ein Restore-Zeitziel existiert
STACKIT hält fest, dass die Restore-Dauer von Volume-Größe, Performance-Typ des Volumes und Last des Backup-Systems abhängt. Dimensionieren Sie die Performance-Klasse entsprechend.
3 · Aufbau
Backup-Definitionen liegen neben der Infrastruktur
Der Entwurf enthält keine. Ergänzen Sie sie in Ihrem eigenen Terraform oder in Skripten und prüfen Sie sie wie jede andere Änderung.
Performance-Klasse und Größen der Volumes sind bestätigt
Die Klasse ist eine Variable; die Größen stammen aus der aufgerundeten Quellkapazität. Beide erscheinen als Einstellungen, die bei Ihnen bleiben.
Die Snapshot-Entscheidung ist festgehalten
Jede Maschine mit Snapshots, hier db-pg01, file01 und test-clone07, hat in review/decisions.yaml einen offenen Eintrag, der die Snapshot-Einstellung aufführt. Tragen Sie Entscheidung und Begründung ein und führen Sie den Lauf erneut aus.
4 · Daten
Snapshots sind vor dem Export konsolidiert
Es wandert nur der aktuelle Stand. Broadcom warnt davor, eine Konsolidierung abzubrechen, und weist darauf hin, dass über Backup-Software erzeugte Snapshots im Snapshot Manager fehlen können; prüfen Sie daher auch auf der Kommandozeile.
Datenbanken haben eine Kopie auf Anwendungsebene
Für db-pg01 ein Dump oder das datenbankeigene Backup neben der Volume-Kopie. Ein absturzkonsistentes Volume-Backup ist eine Rückfallebene, nicht der Plan.
Ein letztes Quell-Backup existiert und bleibt erhalten
Erstellen Sie es vor der letzten Kopie und behalten Sie es, bis ein Restore auf STACKIT nachgewiesen ist.
5 · Cutover
Wo nötig, ist ein ruhiges Zeitfenster vereinbart
STACKIT empfiehlt, den Server mit dem Volume vor einem Volume-Backup auszuschalten, sonst ist das Ergebnis absturzkonsistent. Entscheiden Sie je Anwendung.
Das erste STACKIT-Backup läuft direkt nach dem Cutover
Prüfen Sie, dass sein Status available erreicht, wie es die IaaS-API-Anleitung beschreibt.
Quellmaschine und ihre Backups bleiben
Behalten Sie beide, bis die neuen Backups den benötigten Zeitraum abdecken. Legen Sie sie per Entscheidung still, nicht aus Gewohnheit.
6 · Nachbereitung
Ein Restore wurde durchgeführt und gemessen
Legen Sie aus einem Snapshot oder Backup ein neues Volume an, hängen Sie es an einen Server und prüfen Sie die Daten. Die IaaS-API-Anleitung nennt die Schritte.
Die Aufbewahrung verhält sich wie entworfen
Backups werden gelöscht, wenn ihre Aufbewahrung endet. Prüfen Sie, dass die älteste behaltene Kopie die geplante ist.
Alte Snapshots, Backups und Betriebshandbücher sind stillgelegt
Entfernen Sie VMware-Snapshots und alte Backup-Jobs per Entscheidung und stellen Sie das Restore-Handbuch auf die STACKIT-Schritte um.
Fragen zu Backups und Snapshots
Wandern VMware-Snapshots nach STACKIT?
Nein. Der Lauf hält fest, dass nur der aktuelle Stand migriert wird; konsolidieren Sie Snapshots daher vor dem Export. Behandeln Sie einen Snapshot als Rückfallhilfe auf der Quelle, nicht als mitzunehmende Daten.
Richtet StackToIT Backups auf STACKIT ein?
Nein. Der Entwurf in diesem Lauf enthält Netzwerke, Schnittstellen, Server und Volumes, aber keine Backup-Ressource. Die Snapshot-Einstellung führt er als eine auf, die Sie prüfen, und hält Ihre Antwort in der Entscheidungsdatei fest.
Kann ich einen STACKIT-Snapshot direkt zurückspielen?
Die Server-Einführung sagt, dass Snapshots nicht direkt zurückgespielt werden können, wohl aber für einen neuen Server oder neue Volumes genutzt werden. Backups lassen sich direkt zurückspielen.
Sind STACKIT-Backups anwendungskonsistent?
Die Seiten zu Server Backup Management beschreiben sie als absturzkonsistent und erwähnen kein Quiescing auf Anwendungsebene. Sichern Sie Datenbanken mit deren eigenen Werkzeugen.
Was hat die Speicherreservierung damit zu tun?
Für Backups nichts; sie steht aber im selben Blatt vMemory, das Sie dem Export hinzufügen. Der Lauf bittet Sie zu prüfen, dass der gewählte Maschinentyp die Reservierung hält, zum Beispiel 32768 bei db-pg01.
Quellen
Ihr nächster Schritt: STACKIT.
Erzählen Sie uns von Ihrer Umgebung. Wir zeigen Ihnen, was StackToIT dafür liefert: Zielarchitektur, Terraform-Artefakte und einen strukturierten Migrationsplan.