Droplet-Umzug abgrenzen: DigitalOcean zu Hetzner migrieren. Termin vereinbaren.
Ein Droplet wird in diesem Leitfaden als neuer Linux-Anwendungsserver bei Hetzner aufgebaut. Danach folgen Dateien, Datenbank und eine kontrollierte Umschaltung. Der entscheidende Unterschied zum Umzug innerhalb von DigitalOcean: Backups und Snapshots können aktuell nicht heruntergeladen werden. Ein Snapshot ist deshalb hier kein direkt übertragbares Importpaket.
Stand: Oktober 2026. Die folgenden Schritte sind unsere Empfehlungen für eine administrierbare Linux-Anwendung mit definierten Datenpfaden. Sie sind keine Zusage einer bestimmten Migrationsdauer.
Inhaltsverzeichnis
- Snapshot und Datenumzug unterscheiden
- Droplet und externe Dienste inventarisieren
- Zielserver und Zugriff vorbereiten
- Dateien mit rsync übertragen
- Datenbank und finalen Datenstand übernehmen
- Cutover mit Abnahme und Rückweg planen
- Unser Vorgehen bei WZ-IT
- Weiterführende Guides
Snapshot und Datenumzug unterscheiden
Ein Droplet-Snapshot speichert einen Datenträgerstand bei DigitalOcean. Je nach laufenden Diensten empfiehlt die Dokumentation das Herunterfahren für einen konsistenten Stand. Ein Live-Snapshot ist deshalb keine allgemeine Garantie für konsistente Datenbanken.
Unsere Empfehlung: einen geeigneten Wiederherstellungspunkt an der Quelle behalten und den Transferweg davon getrennt planen. Der neue Server muss aus überprüfbaren Konfigurationen und Daten startfähig werden. Wer stattdessen ein vollständiges Systemabbild übertragen will, braucht ein gesondertes Verfahren mit Boot-, Treiber- und Netzwerkprüfung; das ist nicht der hier beschriebene Ablauf.
| Zweck | Vorgesehenes Mittel | Ersetzt nicht |
|---|---|---|
| Quellsystem wiederherstellen | Geeignete Sicherung bei DigitalOcean | Migration nach Hetzner |
| Anwendungsdateien übertragen | Gezielt ausgewählte Pfade über SSH | Datenbank-Backup |
| Datenbank übernehmen | Engine-spezifischer Export und Restore | Rollen- und Anwendungstests |
| Betrieb umschalten | Vereinbartes Runbook | Abnahme und Rückweg |
Droplet und externe Dienste inventarisieren
Halten Sie vor dem Aufbau fest, welche Daten im Droplet liegen und welche außerhalb. Unser vorgeschlagenes Inventar enthält Betriebssystem, Architektur, Laufzeiten, Dienste, Mountpoints, Benutzer, Uploads, Geheimnisse, DNS, Zertifikate und externe Schnittstellen.
Für jeden persistenten Pfad braucht es eine Antwort auf drei Fragen: Wer schreibt hinein? Welcher Stand soll übernommen werden? Wer prüft das Ergebnis? Ein unklarer Datenpfad ist ein offener Punkt für die Umschaltung.
Prüfen Sie zusätzliche Volumes, Managed Databases, Spaces, Load Balancer und externe Dienste ausdrücklich als eigene Positionen. Der Transfer eines lokalen Upload-Verzeichnisses erfasst sie nicht. Für Objektspeicher beschreibt der Spaces-zu-Hetzner-Leitfaden einen getrennten Weg. Dieser Artikel behandelt den Serverumzug und ersetzt keinen Object-Storage-Transfer.
Notieren Sie außerdem Jobs und eingehende Webhooks. Unsere Empfehlung ist, schreibende Nebenwege zusammen mit dem Webzugriff zu erfassen. Sonst bleibt offen, wer den finalen Datenstand während des Wechsels noch verändern kann.
Zielserver und Zugriff vorbereiten
Wir empfehlen eine neue Zielinstallation mit bewusst gewähltem Betriebssystem, Architektur und Anwendungsstand. Ein Preisvergleich allein ist keine Kompatibilitätsprüfung. Der DigitalOcean-vs.-Hetzner-Vergleich behandelt Paketpreise und Betriebsumfang separat.
Legen Sie Laufzeit, Pakete, Dienstkonten, persistente Verzeichnisse und Wiederanlauf fest. Vor der ersten Datenkopie sollten SSH-Zugriff, ausreichender Speicher und die Wiederherstellungsmöglichkeit geklärt sein. Zugriffe werden auf die benötigten Verbindungen begrenzt.
Die Hetzner-Anleitung zur Datenmigration beschreibt Backup und Übertragung auf einen neuen Server. Unser Ablauf übernimmt daraus die Trennung von Datenumzug und vollständigem Partitionsumzug. Wir empfehlen, Konfigurationen bewusst zu übertragen und das Zielsystem nicht durch eine pauschale Kopie des gesamten Quell-Dateisystems zu ersetzen.
Dateien mit rsync übertragen
Das folgende Beispiel überträgt nur den Inhalt von /srv/app/uploads/. Konto, Zieladresse und Pfade sind Platzhalter für Ihre Umgebung. Starten Sie mit einer Prüfung der Ausgabe:
rsync -av --dry-run -e ssh /srv/app/uploads/ migration@TARGET_IP:/srv/app/uploads/
Erst nach Kontrolle von Richtung und Zielpfad wird --dry-run entfernt. Nach dem rsync-Handbuch simuliert die Option den Lauf; Archivmodus allein deckt nicht alle Metadaten ab. Planen Sie erforderliche Eigentümer, ACLs und erweiterte Attribute anhand der Anwendung. Das Beispiel enthält bewusst keinen Löschabgleich und keine vollständige Systemkopie.
Unsere Empfehlung für die Prüfung: Dateibestand mit der vereinbarten Referenz vergleichen, Rechte kontrollieren und repräsentative Dateien mit der Anwendung lesen. Wiederholen Sie den Abgleich nach dem Schreibstopp. Ein abgeschlossener Kopierprozess allein weist die fachliche Richtigkeit nicht nach.
Wenn Container eingesetzt werden, trennen Sie die reproduzierbare Bereitstellung von persistenten Anwendungsdaten. Erfassen Sie jeden benötigten Datenpfad im Inventar; ein Deployment-Manifest allein ist in diesem Ablauf kein Ersatz für eine gesicherte Datenbasis.
Datenbank und finalen Datenstand übernehmen
Für Datenbanken wählen Sie ein zur Engine passendes Backup- und Wiederherstellungsverfahren. Bei PostgreSQL ist pg_dump ein konsistenter Einzel-Datenbank-Dump; benötigte Rollen und zusätzliche Datenbanken sind gesondert zu berücksichtigen. Für MySQL oder andere Engines ist das jeweilige Verfahren separat festzulegen.
Wir empfehlen zunächst eine Wiederherstellungsprobe im isolierten Ziel. Prüfen Sie nicht nur, ob der Import beendet wurde, sondern auch Rollen, Berechtigungen, Erweiterungen und fachliche Abfragen. Das Ergebnis gehört ins Migrationsprotokoll.
Für den letzten Stand sieht dieses Runbook einen vereinbarten Schreibstopp vor. Stoppen Sie die zuvor erfassten schreibenden Zugriffe, Jobs und Importe. Übertragen Sie dann den finalen Datenbankstand und gleichen Sie veränderliche Dateien erneut ab. Geben Sie Schreibzugriffe im Ziel erst nach der vereinbarten Prüfung frei.
Wenn ein Schreibstopp für die Anwendung nicht vertretbar ist, muss zunächst ein anderer Transfer- und Replikationsweg geplant werden. Der hier gezeigte rsync-Befehl macht aus diesem Verfahren keine Migration ohne Unterbrechung.
Cutover mit Abnahme und Rückweg planen
Unsere empfohlene Abnahme betrachtet die Anwendung unter ihrem vorgesehenen Hostnamen: Anmeldung, Rollen, Upload und Download, schreibende Vorgänge, E-Mail-Versand und externe Integrationen. Prüfen Sie zusätzlich Start nach Neustart, Sicherung und Überwachung entsprechend dem vereinbarten Betriebsumfang.
DNS-Umschaltung und Domainverwaltung bleiben getrennte Arbeitspunkte. Stellen Sie sicher, dass die Zuständigen die erforderlichen Einträge ändern können. Halten Sie außerdem fest, wann Hintergrundjobs im Ziel aktiviert und an der Quelle deaktiviert werden.
Ein Rückwechsel muss auch neue Zieldaten behandeln. Definieren Sie Abbruchkriterien, den führenden Datenbestand und die Zuständigkeit für dessen Übernahme. Ein DNS-Rückwechsel ohne diese Entscheidung ist kein vollständiger Rückweg.
Quelle, Snapshots und weitere Ressourcen werden erst nach Abnahme und geklärter Aufbewahrung abgebaut. Für die Kostenbetrachtung empfehlen wir, neben Zielressourcen auch Datenübertragung, Parallelbetrieb, Sicherung und Betreuung aufzunehmen. Daraus folgt keine pauschale Aussage, dass jeder Droplet-Umzug Geld spart.
Unser Vorgehen bei WZ-IT
Die DigitalOcean-zu-Hetzner-Migration ist das Zielangebot für diesen Leitfaden. Der Cloud-Exit-Check hilft, wenn Zielarchitektur und Umfang noch offen sind. Hetzner-Expertise ergänzt den Plattformkontext.
Für eine Anfrage eignen sich Droplet-Liste, Datenpfade, Datenbanktyp, Datenmenge und externe Abhängigkeiten. Migration, Abnahme und anschließende Betriebszuständigkeiten werden anhand dieser Ausgangslage abgegrenzt.
Weiterführende Guides
- DigitalOcean Spaces zu Hetzner Object Storage
- DigitalOcean vs. Hetzner: Kosten und Betriebsumfang
- OVH zu Hetzner: Netzwerk und Umzug
- Migrationsübersicht
Droplet-Migration planen: Bestand und Übertragungsweg klären. Termin vereinbaren.
