# VPS migrációs ellenőrzőlista: biztonsági mentések, DNS, TLS és visszaállítás [VPS migrációs ellenőrzőlista: biztonsági mentések, DNS, TLS és visszaállítás]() Frissítve 2026-10-15 Gyakorlati migrációs sorrend egy saját üzemeltetésű alkalmazáshoz: leltár, konzisztens biztonsági mentések, tesztelt célhely, ellenőrzött írások, DNS átállás és egy helyreállítási útvonal. Egy ellenőrzött VPS migráció leltárba veszi a szolgáltatásokat és adatokat, konzisztens biztonsági mentést készít, ellenőrzi a visszaállított célhelyet, teszteli a gazdagépnév- és TLS útvonalválasztást, összehangolja a végső írásokat és a DNS-t, és adattudatos visszaállítást tart fenn. Egyetlen ellenőrzőlista sem garantál nulla leállást önmagában. ## Készíts leltárt az alkalmazásról, mielőtt áthelyezed Sorol fel minden szolgáltatást, verziót, portot, ütemezett feladatot, adatbázist, feltöltött fájlt és konfigurációt, amelyre az alkalmazásnak a működéshez szüksége van. Azonosítsd, hol történnek írások, és mely külső szolgáltatásoktól függ. Egy másolt webkönyvtár nem teljes migráció, ha az adatok máshol élnek. Jegyezd fel a jelenlegi DNS neveket, az aktív IPv4 és IPv6 rekordokat, a tanúsítvány-megújítási módszereket és egy helyreállítási hozzáférési útvonalat. A titkokat a privát telepítési eszközeidben tartsd. Ne tedd jelszavakat, privát kulcsokat vagy adatbázis-mentéseket nyilvános dokumentumgyökérbe vagy megosztott migrációs ellenőrzőlistába. ## Készíts konzisztens biztonsági mentést, és bizonyítsd, hogy visszaállítható Az adatbázis által támogatott biztonsági mentési mechanizmust használd, ahelyett hogy tetszőleges fájlokat másolnál, miközben az írások folytatódnak. A SQLite esetén az Online Backup API konzisztens adatbázis-pillanatképet készít. WAL módban a WAL fájl részt vesz az állandó adatbázis-állapotban, így csak a fő adatbázisfájl másolása kihagyhatja a jóváhagyott változtatásokat. Egy konzisztens adatbázis-biztonsági mentés nem automatikusan konzisztens a külön tárolt feltöltésekkel, sorokkal vagy fájlokkal. Hangold össze azok rögzítését az alkalmazásoddal. Állítsd vissza egy külön teszt-helyre, és ellenőrizd a rekordokat, fájlhivatkozásokat és az alkalmazás viselkedését, mielőtt a biztonsági mentést használhatónak tekintenéd. ## Készítsd elő a célhelyet a DNS megváltoztatása előtt Hozd létre a szándékolt felhasználókat, jogosultságokat, futtatókörnyezet-verziókat, szolgáltatásokat és alkalmazáskönyvtárakat az új szerveren. Állítsd vissza a teszt biztonsági mentést a cél adathelyére, adott esetben a nyilvános webgyökéren kívül. Ellenőrizd a tulajdonjogot és a hozzáférést azzal a szolgáltatásfiókkal, amely ténylegesen futtatni fogja az alkalmazást. Őrizd meg a nem kapcsolódó webhelyeket egy megosztott szerveren. Használj dedikált dokumentumgyökeret, virtuális gazdagépet és futtatókörnyezetet, érvényesítsd a webszerver-konfigurációt, és készíts elő egy visszaállítást, amely csak az ehhez a változtatáshoz tartozó fájlokat és konfigurációt állítja vissza. ## Teszteld a valódi gazdagépnevet és tanúsítványt az új szerveren Egy böngészőkérés egy csupasz IP-címre nem reprodukálja a gazdagépnév-alapú útvonalválasztást vagy a tanúsítvány-érvényesítést. A curl --resolve lehetővé teszi, hogy egy teszt a szándékolt gazdagépnevet és egy kiválasztott cél-IP-t használjon, miközben megtartja a normál gazdagépnév- és TLS ellenőrzéseket. Ellenőrizd a HTTP-állapotot és a várt alkalmazástartalmat is. A példa csak dokumentációs értékeket használ; cseréld ki őket a saját ellenőrzött domainnevedre és célhelyedre. A teszt sikerességéhez már léteznie kell egy érvényes tanúsítványnak és egy engedélyezett hálózati útvonalnak. Soha ne tiltsd le a tanúsítvány-ellenőrzést, hogy a migrációt késznek nyilvánítsd. A DNS-alapú ACME érvényesítés érvényesíthet egy domaint a webszerver címe nélkül; a HTTP-alapú érvényesítésnek más elérhetőségi követelményei vannak. A megújítást a kezdeti kiadástól külön teszteld. ``` curl --fail-with-body --show-error --resolve example.com:443:203.0.113.10 https://example.com/ ``` ## Válassz írás-ellenőrzési és végső szinkronizálási tervet Ütemezz be egy rövid karbantartási időszakot vagy egy másik, az alkalmazáshoz illő konzisztencia-mechanizmust. Állítsd le vagy irányítsd át az általad azonosított írókat, készítsd el a végső konzisztens adatbázis-biztonsági mentést, szinkronizáld a megfelelő változó fájlokat, és ellenőrizd az eredményt. A sorfeldolgozók, webhookok és cron-feladatok akkor is írhatnak, amikor a nyilvános felület csendesnek tűnik. Fájlszinkronizálás előtt végezz próbafuttatást. Ne adj hozzá törlési jelzőket, és ne másolj teljes rendszerkönyvtárakat gyors megoldásként. Tartsd a régi szolgáltatást helyreállíthatóan, amíg ellenőrizted az új alkalmazást, és megállapítottad, melyik hely az írások hiteles forrása. ## Változtasd meg a DNS, majd figyeld mindkét címcsaládot Frissítsd a szolgáltatáshoz szükséges rekordokat, és számolj a meglévő feloldó-gyorsítótárakkal. Ellenőrizd a hiteles válaszokat és több normál kliensútvonalat. Ha egy elavult AAAA rekord aktív marad, a IPv6 kliensek továbbra is elérhetik a régi szervert, míg a IPv4 kliensek az újat érik el. Teszteld a bejelentkezést, az olvasásokat, az írásokat, a feltöltéseket, a háttérfeladatokat és a külső visszahívásokat az új szolgáltatáson. Az átmenet során ne futtass két független, írható példányt ugyanabból az alkalmazásból. Tarts egyértelmű szabályt a régi célhelyre még eljutó forgalom kezelésére. ## A visszaállítás legyen adatdöntés is, ne csak DNS döntés Határozd meg azokat a hibafeltételeket, amelyek visszaállítást váltanak ki, és hogy ki irányítja az átállást. A DNS önmagában való visszaállítása nem elég, miután új írások érkeztek a célhelyre: meg kell őrizned vagy össze kell egyeztetned azokat az adatokat, mielőtt visszatérsz egy régebbi példányhoz. Tartsd meg a forrást és a biztonsági mentéseket egy megfelelő helyreállítási időszakra. A régi hozzáférést csak akkor távolítsd el, és az erőforrásokat csak akkor vond ki, miután a célhelyet, a biztonsági mentéseket, a megújítást és a megfigyelést ellenőrizted. A megőrzésnek és törlésnek a tényleges szolgáltatási irányelvet kell követnie, nem egy általános, rögzített óraszámot. ## Kérdések, megválaszolva ### Másolhatok közvetlenül egy élő SQLite adatbázisfájlt? Ne feltételezd, hogy egy fájl másolása egy élő adatbázisból teljes, konzisztens biztonsági mentést eredményez. Használj támogatott biztonsági mentési módszert, és számolj a WAL állapotával. Az adatbázison kívül tárolt fájlokat is hangold össze. ### Áthelyezi az alkalmazásadataimat egy DNS rekord megváltoztatása? Nem. A DNS a jövőbeli névfeloldást egy cím felé irányítja. Az alkalmazásfájlok, adatbázisok, titkok és háttérszolgáltatások külön migrációs és ellenőrzési folyamatot igényelnek. ### Ígérhetek nulla leállást ezzel az ellenőrzőlistával? Nem. A leállás és a konzisztencia az alkalmazástól, a forgalomtól, az adatoktól és az átállási módszertől függ. Az ellenőrzőlista segít előkészíteni és tesztelni egy ellenőrzött áthelyezést; ez nem nulla leállásra vonatkozó garancia. ## Találd meg az útmutatót a következő döntésedhez - [Méretezd a célhelyet mért igények alapján]() - [Értsd meg a vendég és a gazdagép irányítását]() - [Tervezd meg a saját üzemeltetésű munkaterhelésedet]() - [Fedezd fel a VPS erőforrásokat]() ## Hivatalos hivatkozások - [SQLite Online Backup API]() - [SQLite write-ahead naplózás]() - [curl kézikönyv: gazdagépnév-feloldás felülírása]() - [ACME kihívástípusok]() - [rsync kézikönyv]()