# VPS-migratiechecklist: back-ups, DNS, TLS en rollback [VPS-migratiechecklist: back-ups, DNS, TLS en rollback]() Bijgewerkt 2026-10-15 Een praktische migratiereeks voor een zelfgehoste applicatie: inventaris, consistente back-ups, een geteste bestemming, gecontroleerde writes, DNS cutover en een hersteltraject. Een gecontroleerde VPS-migratie inventariseert services en gegevens, maakt een consistente back-up, verifieert een herstelde bestemming, test hostnaam- en TLS routering, coördineert definitieve writes en DNS en behoudt een databewuste rollback. Geen enkele checklist garandeert op zichzelf zero downtime. ## Inventariseer de applicatie voordat u deze verplaatst Maak een lijst van de services, versies, poorten, geplande taken, databases, geüploade bestanden en configuratie die nodig zijn om de applicatie te laten werken. Identificeer waar writes plaatsvinden en van welke externe services deze afhankelijk is. Een gekopieerde webdirectory is geen volledige migratie wanneer de gegevens elders staan. Noteer huidige DNS namen, actieve IPv4 en IPv6 records, methoden voor certificaatvernieuwing en een hersteltoegangspad. Bewaar geheimen in uw privé-deploymenttooling. Zet wachtwoorden, privésleutels of databasedumps niet in een openbare document root of een gedeelde migratiechecklist. ## Maak een consistente back-up en bewijs dat deze herstelt Gebruik het door de database ondersteunde back-upmechanisme in plaats van willekeurige bestanden te kopiëren terwijl writes doorgaan. Voor SQLite maakt de Online Backup API een consistente databasesnapshot. In WAL modus maakt het WAL bestand deel uit van de persistente databasestatus, dus het kopiëren van alleen het hoofddatabasebestand kan vastgelegde wijzigingen weglaten. Een consistente databaseback-up is niet automatisch consistent met afzonderlijk opgeslagen uploads, queues of bestanden. Stem het vastleggen ervan af met uw applicatie. Herstel naar een afzonderlijke testlocatie en verifieer records, bestandsverwijzingen en applicatiegedrag voordat u de back-up als bruikbaar beschouwt. ## Bereid de bestemming voor voordat u DNS wijzigt Maak de beoogde gebruikers, machtigingen, runtime-versies, services en applicatiemappen aan op de nieuwe server. Herstel de testback-up naar de bestemmingsdatalocatie, waar passend buiten de openbare webroot. Controleer eigendom en toegang met het serviceaccount dat de applicatie daadwerkelijk zal draaien. Behoud niet-gerelateerde sites op een gedeelde server. Gebruik een toegewijde document root, virtual host en runtime, valideer de webserverconfiguratie en bereid een rollback voor die alleen de bestanden en configuratie herstelt die eigendom zijn van deze wijziging. ## Test de echte hostnaam en het certificaat op de nieuwe server Een browserverzoek naar een kaal IP-adres reproduceert geen hostnaamgebaseerde routering of certificaatvalidatie. Met curl --resolve kan een test de beoogde hostnaam en een gekozen bestemmings-IP gebruiken terwijl normale hostnaam- en TLS controles behouden blijven. Controleer ook de HTTP-status en de verwachte applicatie-inhoud. Het voorbeeld gebruikt alleen-documentatiewaarden; vervang ze door uw eigen geverifieerde domein en bestemming. Een geldig certificaat en een toegestaan netwerkpad moeten al bestaan wil die test slagen. Schakel certificaatverificatie nooit uit om de migratie gereed te noemen. DNS-gebaseerde ACME validatie kan een domein valideren zonder het webserveradres te wijzigen; op HTTP gebaseerde validatie heeft andere bereikbaarheidsvereisten. Test vernieuwing afzonderlijk van de initiële uitgifte. ``` curl --fail-with-body --show-error --resolve example.com:443:203.0.113.10 https://example.com/ ``` ## Kies een plan voor writecontrole en eindsynchronisatie Plan een korte onderhoudsperiode of een ander voor de applicatie passend consistentiemechanisme. Stop of omleid de writers die u heeft geïdentificeerd, maak de definitieve consistente databaseback-up, synchroniseer de bijbehorende veranderlijke bestanden en verifieer het resultaat. Queueworkers, webhooks en cron-taken kunnen schrijven zelfs wanneer de openbare interface rustig lijkt. Gebruik een dry run voordat u bestanden synchroniseert. Voeg geen verwijderingsflags toe en kopieer niet hele systeemmappen als snelkoppeling. Houd de oude service herstelbaar totdat u de nieuwe applicatie heeft gecontroleerd en heeft vastgesteld welke locatie gezaghebbend is voor writes. ## Wijzig DNS en observeer vervolgens beide adresfamilies Werk de records bij die nodig zijn voor de service en houd rekening met bestaande resolver-caches. Controleer de gezaghebbende antwoorden en verschillende normale clientpaden. Als een verouderd AAAA record actief blijft, kunnen IPv6 clients de oude server blijven bereiken terwijl IPv4 clients de nieuwe bereiken. Test aanmelden, lezen, schrijven, uploads, achtergrondtaken en externe callbacks op de nieuwe service. Vermijd het draaien van twee onafhankelijke beschrijfbare kopieën van dezelfde applicatie tijdens de overgang. Houd een duidelijke regel voor het omgaan met verkeer dat de oude bestemming nog bereikt. ## Maak rollback zowel een databeslissing als een DNS beslissing Definieer de faalcondities die een rollback activeren en wie de cutover beheert. Alleen DNS terugdraaien is niet genoeg nadat nieuwe writes de bestemming hebben bereikt: u moet die gegevens behouden of verzoenen voordat u terugkeert naar een oudere kopie. Bewaar de bron en back-ups gedurende een passende herstelperiode. Verwijder oude toegang en decomissioneer resources pas nadat de bestemming, back-ups, vernieuwing en monitoring zijn gecontroleerd. Retentie en verwijdering moeten het werkelijke servicebeleid volgen, niet een generiek vast aantal uren. ## Vragen, beantwoord ### Kan ik een live SQLite databasebestand rechtstreeks kopiëren? Ga er niet van uit dat het kopiëren van één bestand uit een live database een volledige, consistente back-up oplevert. Gebruik een ondersteunde back-upmethode en houd rekening met WAL status. Stem ook bestanden af die buiten de database worden opgeslagen. ### Verplaatst het wijzigen van een DNS record mijn applicatiegegevens? Nee. DNS stuurt toekomstige naamresolutie naar een adres. Applicatiebestanden, databases, geheimen en achtergrondservices vereisen een afzonderlijk migratie- en verificatieproces. ### Kan ik met deze checklist zero downtime beloven? Nee. Downtime en consistentie hangen af van de applicatie, het verkeer, de gegevens en de cutovermethode. De checklist helpt u een gecontroleerde verhuizing voor te bereiden en te testen; het is geen zero-downtimegarantie. ## Vind de gids voor uw volgende beslissing - [Bepaal de bestemming op basis van gemeten behoeften]() - [Begrijp gast- en hostcontrole]() - [Plan uw zelfgehoste workload]() - [Verken de VPS-resources]() ## Officiële referenties - [SQLite Online Backup API]() - [SQLite write-ahead logging]() - [curl-handleiding: overschrijvingen van hostnaamresolutie]() - [ACME challenge-types]() - [rsync-handleiding]()