Bereid de nieuwe server eerst voor en test deze, kopieer gegevens met een door de applicatie ondersteunde consistentiemethode, definieer een cutover-venster en behoud de oude omgeving. Rollback moet rekening houden met schrijfacties die op de nieuwe server zijn geaccepteerd, niet alleen met een DNS-wijziging.
Inventariseer de service voordat u de machine verplaatst
Een migratie omvat meer dan de applicatiebestanden. Maak een lijst van databases, uploads, geplande taken, queue-workers, certificaten, domeinen, secrets en uitgaande integraties. Registreer softwareversies en de operationele aannames die van belang zijn, zoals bestandsrechten en opslagpaden. Een nieuwe dedicated server kan een vergeten afhankelijkheid blootleggen die jaren eerder stilletjes op de oude omgeving was geïnstalleerd.
Wijs een eigenaar aan voor de cutover-beslissing en definieer hoe succes eruitziet. Neem gebruikersgerichte controles, gegevensconsistentie en de mogelijkheid om toegang te herstellen op. Bevestig dat de nieuwe configuratie is geleverd en bruikbaar is voordat u een migratiedatum aankondigt. Een orderbevestiging of een vermelde hardwarespecificatie is niet hetzelfde als een werkende bestemming die klaar is om productiegegevens te ontvangen.
Bouw de bestemming als een afzonderlijke omgeving
Installeer de vereiste stack, stel beheer in en configureer de beoogde firewall. Houd secrets privé en stel servicerechten bewust in. Verifieer het verwachte hostname- en certificaatgedrag van de applicatie voordat openbaar verkeer wordt verplaatst. De virtual-hostdocumentatie van Apache illustreert waarom hostname-routering een afzonderlijke configuratiebeslissing is ten opzichte van het adres van de server. Een werkende standaardpagina bewijst niet dat de juiste applicatiehost is geconfigureerd.
Gebruik een representatieve herstelde dataset voor de repetitie, met uitgaande e-mail, betalingen en geplande taken uitgeschakeld of omgeleid naar veilige testsystemen. Dit voorkomt dat de testomgeving op echte gebruikers inwerkt. Test inloggen, uploads, achtergrondtaken en herstel. Registreer de procedure en de duur ervan, zodat het werkelijke venster is gebaseerd op een waargenomen proces in plaats van optimisme.
Kies een consistente gegevensgrens
Gebruik een back-up- of replicatiemethode die door de database en applicatie wordt ondersteund. PostgreSQL onderscheidt SQL-dumps, bestandssysteemback-ups en continue archivering, elk met eigen aannames. De dumprichtlijnen merken op dat databasedumps intern consistent kunnen zijn, terwijl clusterbrede rollen en andere details afzonderlijk moeten worden behandeld. Lees de vereisten voor het exacte systeem dat u gebruikt in plaats van willekeurig open databestanden te kopiëren.
Plan hoe de database zich verhoudt tot uploads en queuestatus. Als een record verwijst naar een bestand dat op een ander moment is gekopieerd, kan de herstelde applicatie onvolledig zijn, zelfs wanneer beide kopieën afzonderlijk zijn geslaagd. Bepaal of u schrijfacties kort moet pauzeren, een geteste replicatieopstelling moet gebruiken of een applicatiespecifieke export moet uitvoeren. Houd die consistentiebeslissing expliciet in het draaiboek.
| Fase | Vereist bewijs | Beslissing |
|---|---|---|
| Repetitie | Applicatie en herstelde gegevens doorstaan controles | Bestemming kan voor cutover in aanmerking komen |
| Laatste synchronisatie | Gedefinieerd consistent herstelpunt | Ga alleen verder met begrepen resterende wijzigingen |
| Verkeersomschakeling | Correcte routering en certificaatgedrag | Monitor beide bestemmingen |
| Rollback | Locatie van alle nieuw geaccepteerde schrijfacties | Reconcilieer gegevens voordat verkeer terugkeert |
Bereid verkeersroutering voor zonder directe wijzigingen te beloven
DNS time-to-live bepaalt hoe lang records in de cache mogen blijven, zoals uitgelegd in de DNS-documentatie van Cloudflare. Controleer de TTL vroeg als DNS deel uitmaakt van de migratie, en laat bestaande gecachte records verlopen onder hun eerdere instelling. Het wijzigen van de waarde op het moment van cutover kan niet met terugwerkende kracht elk gecacht antwoord verkorten. Verschillende clients kunnen tijdens de overgang verschillende bestemmingen bereiken.
Houd de oude omgeving beschikbaar terwijl routeringswijzigingen zich stabiliseren, met een bewust beleid voor de vraag of deze nog schrijfacties mag accepteren. Vermijd het draaien van dubbele queue-consumers of geplande taken, tenzij de applicatie daarvoor is ontworpen. Monitor verzoeken aan beide zijden en bevestig de beoogde hostname, het TLS-certificaat en de applicatieversie vanaf onafhankelijke clients.
Definieer rollback nadat schrijfacties beginnen
Voordat het nieuwe systeem wijzigingen accepteert, kan het terugdraaien van verkeer relatief eenvoudig zijn. Daarna kan een DNS-omkering alleen werk verloren laten gaan of twee tegenstrijdige geschiedenissen creëren. Definieer hoe nieuw aangemaakte records en uploads behouden of gereconcilieerd worden. Als de applicatie ze niet veilig kan samenvoegen, kan een gecontroleerde onderhoudsperiode de voorkeur verdienen boven een geïmproviseerde terugkeer naar de oude kopie.
Stel de voorwaarden vast waaronder de migratie moet worden gepauzeerd, en houd de beslissingsverantwoordelijke bereikbaar. Bewaar logs en nuttig bewijs volgens de bewaarregels van het project. Verwijder de oude machine of de onafhankelijke herstelkopie niet alleen omdat de startpagina één keer is geladen. De bewaarperiode moet aansluiten bij de overeengekomen verificatie- en rollbackbehoeften.
Sluit de migratie af met operationele controles
Verifieer na de cutover back-ups, waarschuwingen, certificaatvernieuwing, geplande taken en toegangsherstel. Bevestig dat de gemonitorde host de nieuwe bestemming is en dat er geen testintegraties in productie achterblijven. Beoordeel applicatiefouten en gebruikersgerichte tijden onder normaal verkeer. Werk de inventaris en het draaiboek bij, zodat de volgende beheerder niet hoeft af te leiden wat er is veranderd.
De dedicated families van SwissOctet bieden verschillende fysieke configuraties, maar migratiewerk en beheerde ondersteuning moeten voor de gekozen service worden bevestigd. Gebruik de catalogus om geschikte resources te selecteren en bouw vervolgens een geteste verhuizing rond de gegevens van uw applicatie. Een migratie is voltooid wanneer de service en het herstelproces op de bestemming werken, niet alleen wanneer bestanden zijn overgedragen.
Uw praktische checklist.
- Inventariseer gegevens, taken, secrets en integraties.
- Verifieer de geleverde bestemming voordat u gaat plannen.
- Oefen met veilige externe integraties.
- Definieer consistentie van database en uploads.
- Plan de routeringsovergang en voorkom dubbele taken.
- Specificeer rollback voor nieuwe schrijfacties.
- Verifieer back-ups en monitoring na de cutover.
De details die ertoe doen.
Kan ik migreren door de applicatiemap te kopiëren?+
Alleen als daarmee alles wordt vastgelegd wat de service nodig heeft en de consistentie behouden blijft. Databases, uploads, taken, secrets en configuratie vereisen meestal afzonderlijke aandacht.
Maakt het verlagen van de DNS-TTL de cutover direct?+
Nee. Eerder gecachte antwoorden kunnen blijven bestaan tot hun eerdere levensduur afloopt, en clients kunnen op verschillende momenten bijwerken.
Is rollback gewoon DNS naar de oude server wijzen?+
Niet nadat de nieuwe server schrijfacties accepteert. U moet rekening houden met die records en bestanden voordat verkeer terugkeert.
Ga naar de bron.
Deze referenties ondersteunen de technische concepten in deze gids. Volg de actuele documentatie voordat u een productiesysteem wijzigt.
- PostgreSQL: Back-up en herstel www.postgresql.org
- PostgreSQL: Consistentie en herstel van SQL-dumps www.postgresql.org
- Apache: Documentatie over virtual hosts httpd.apache.org
- Cloudflare DNS: Time to Live developers.cloudflare.com
Redactionele begeleiding door SwissOctet. Voorbeelden zijn illustratief. Dienstspecificaties, beschikbare opties en contractuele voorwaarden moeten afzonderlijk worden geverifieerd.