# VPS-Migrationscheckliste: Backups, DNS, TLS und Rollback [VPS-Migrationscheckliste: Backups, DNS, TLS und Rollback]() Aktualisiert 2026-10-15 Eine praktische Migrationsabfolge für eine selbst gehostete Anwendung: Inventar, konsistente Backups, ein getestetes Ziel, kontrollierte Schreibvorgänge, DNS-Umstellung und ein Wiederherstellungspfad. Eine kontrollierte VPS-Migration inventarisiert Dienste und Daten, erstellt ein konsistentes Backup, prüft ein wiederhergestelltes Ziel, testet Hostnamen- und TLS-Routing, koordiniert abschließende Schreibvorgänge und DNS und bewahrt einen datenbewussten Rollback. Keine Checkliste allein garantiert Null-Ausfallzeit. ## Die Anwendung inventarisieren, bevor sie verschoben wird Listen Sie die Dienste, Versionen, Ports, geplanten Aufgaben, Datenbanken, hochgeladenen Dateien und die Konfiguration auf, die die Anwendung zum Funktionieren benötigt. Identifizieren Sie, wo Schreibvorgänge stattfinden und von welchen externen Diensten sie abhängt. Ein kopiertes Webverzeichnis ist keine vollständige Migration, wenn die Daten woanders liegen. Notieren Sie aktuelle DNS-Namen, aktive IPv4 und IPv6-Einträge, Methoden zur Zertifikatserneuerung und einen Wiederherstellungszugangspfad. Bewahren Sie Geheimnisse in Ihren privaten Bereitstellungswerkzeugen auf. Legen Sie keine Passwörter, privaten Schlüssel oder Datenbank-Dumps in ein öffentliches Dokumentstammverzeichnis oder eine gemeinsam genutzte Migrationscheckliste. ## Ein konsistentes Backup erstellen und beweisen, dass es wiederherstellt Verwenden Sie den datenbankgestützten Backup-Mechanismus, statt beliebige Dateien zu kopieren, während Schreibvorgänge weiterlaufen. Für SQLite erstellt das Online Backup API einen konsistenten Datenbank-Schnappschuss. Im WAL-Modus ist die WAL-Datei am persistenten Datenbankzustand beteiligt, sodass das Kopieren nur der Hauptdatenbankdatei festgeschriebene Änderungen auslassen kann. Ein konsistentes Datenbankbackup ist nicht automatisch konsistent mit separat gespeicherten Uploads, Warteschlangen oder Dateien. Koordinieren Sie deren Erfassung mit Ihrer Anwendung. Stellen Sie in einen separaten Testort wieder her und prüfen Sie Datensätze, Dateiverweise und Anwendungsverhalten, bevor Sie das Backup als nutzbar betrachten. ## Das Ziel vorbereiten, bevor DNS geändert wird Erstellen Sie die beabsichtigten Benutzer, Berechtigungen, Laufzeitversionen, Dienste und Anwendungsverzeichnisse auf dem neuen Server. Stellen Sie das Testbackup an seinen Ziel-Datenspeicherort wieder her, gegebenenfalls außerhalb des öffentlichen Webstammverzeichnisses. Prüfen Sie Eigentum und Zugriff mit dem Dienstkonto, das die Anwendung tatsächlich ausführen wird. Bewahren Sie unabhängige Sites auf einem gemeinsam genutzten Server. Verwenden Sie ein dediziertes Dokumentstammverzeichnis, einen virtuellen Host und eine Laufzeitumgebung, validieren Sie die Webserver-Konfiguration und bereiten Sie einen Rollback vor, der nur die von dieser Änderung betroffenen Dateien und Konfigurationen wiederherstellt. ## Den echten Hostnamen und das Zertifikat auf dem neuen Server testen Eine Browseranfrage an eine bloße IP-Adresse reproduziert kein hostnamenbasiertes Routing oder Zertifikatsvalidierung. curl --resolve ermöglicht einem Test, den beabsichtigten Hostnamen und eine gewählte Ziel-IP zu verwenden, während die normalen Hostnamen- und TLS-Prüfungen erhalten bleiben. Prüfen Sie auch den HTTP-Status und den erwarteten Anwendungsinhalt. Das Beispiel verwendet reine Dokumentationswerte; ersetzen Sie sie durch Ihre eigene verifizierte Domain und Ihr Ziel. Ein gültiges Zertifikat und ein zulässiger Netzwerkpfad müssen bereits existieren, damit dieser Test besteht. Deaktivieren Sie niemals die Zertifikatsprüfung, um die Migration als bereit zu bezeichnen. Eine DNS-basierte ACME-Validierung kann eine Domain validieren, ohne ihre Webserver-Adresse zu ändern; HTTP-basierte Validierung hat andere Erreichbarkeitsanforderungen. Testen Sie die Erneuerung getrennt von der Erstemission. ``` curl --fail-with-body --show-error --resolve example.com:443:203.0.113.10 https://example.com/ ``` ## Einen Schreibkontroll- und Abschlusssynchronisierungsplan wählen Planen Sie einen kurzen Wartungszeitraum oder einen anderen anwendungsgerechten Konsistenzmechanismus. Stoppen oder verlegen Sie die von Ihnen identifizierten Schreiber, erstellen Sie das abschließende konsistente Datenbankbackup, synchronisieren Sie die entsprechenden veränderlichen Dateien und prüfen Sie das Ergebnis. Warteschlangen-Worker, Webhooks und Cron-Aufgaben können schreiben, selbst wenn die öffentliche Schnittstelle ruhig erscheint. Führen Sie vor einer Dateisynchronisierung einen Probelauf durch. Fügen Sie keine Löschflags hinzu und kopieren Sie nicht ganze Systemverzeichnisse als Abkürzung. Halten Sie den alten Dienst wiederherstellbar, bis Sie die neue Anwendung geprüft und festgelegt haben, welcher Ort für Schreibvorgänge maßgeblich ist. ## DNS ändern, dann beide Adressfamilien beobachten Aktualisieren Sie die für den Dienst erforderlichen Einträge und berücksichtigen Sie bestehende Resolver-Caches. Prüfen Sie die autoritativen Antworten und mehrere normale Client-Pfade. Wenn ein veralteter AAAA-Eintrag aktiv bleibt, können IPv6-Clients weiterhin den alten Server erreichen, während IPv4-Clients den neuen erreichen. Testen Sie Anmeldung, Lesen, Schreiben, Uploads, Hintergrundjobs und externe Callbacks auf dem neuen Dienst. Vermeiden Sie es, während des Übergangs zwei unabhängige beschreibbare Kopien derselben Anwendung auszuführen. Behalten Sie eine klare Regel für den Umgang mit Datenverkehr, der noch das alte Ziel erreicht. ## Machen Sie den Rollback zu einer Datenentscheidung ebenso wie zu einer DNS-Entscheidung Definieren Sie die Fehlerbedingungen, die einen Rollback auslösen, und wer die Umstellung kontrolliert. Allein DNS zurückzusetzen reicht nicht aus, nachdem neue Schreibvorgänge das Ziel erreicht haben: Sie müssen diese Daten bewahren oder abgleichen, bevor Sie zu einer älteren Kopie zurückkehren. Bewahren Sie Quelle und Backups für einen angemessenen Wiederherstellungszeitraum auf. Entfernen Sie alten Zugang und stillgelegte Ressourcen erst, nachdem Ziel, Backups, Erneuerung und Überwachung geprüft wurden. Aufbewahrung und Löschung sollten der tatsächlichen Servicerichtlinie folgen, nicht einer allgemeinen festen Stundenzahl. ## Fragen, beantwortet ### Kann ich eine Live-SQLite-Datenbankdatei direkt kopieren? Gehen Sie nicht davon aus, dass das Kopieren einer Datei aus einer Live-Datenbank ein vollständiges, konsistentes Backup erzeugt. Verwenden Sie eine unterstützte Backup-Methode und berücksichtigen Sie den WAL-Zustand. Koordinieren Sie auch außerhalb der Datenbank gespeicherte Dateien. ### Verschiebt das Ändern eines DNS-Eintrags meine Anwendungsdaten? Nein. DNS lenkt die künftige Namensauflösung auf eine Adresse. Anwendungsdateien, Datenbanken, Geheimnisse und Hintergrunddienste erfordern einen separaten Migrations- und Prüfprozess. ### Kann ich mit dieser Checkliste Null-Ausfallzeit versprechen? Nein. Ausfallzeit und Konsistenz hängen von der Anwendung, dem Datenverkehr, den Daten und der Umstellungsmethode ab. Die Checkliste hilft Ihnen, einen kontrollierten Umzug vorzubereiten und zu testen; sie ist keine Null-Ausfallzeit-Garantie. ## Finden Sie den Leitfaden für Ihre nächste Entscheidung - [Das Ziel nach gemessenem Bedarf dimensionieren]() - [Gast- und Host-Kontrolle verstehen]() - [Ihre selbst gehostete Last planen]() - [Die VPS-Ressourcen erkunden]() ## Offizielle Referenzen - [SQLite Online Backup API]() - [SQLite Write-Ahead-Logging]() - [curl-Handbuch: Hostnamenauflösungs-Überschreibungen]() - [ACME Challenge-Typen]() - [rsync-Handbuch]()