Liigu peamise sisu juurde

Migreeri cPaneli sait VPS-i ilma katkestuseta

· 5 min lugemine
Customer Care Engineer

Avaldatud 10. septembril 2026

Migreeri cPaneli sait VPS-i ilma katkestuseta

Et migreerida cPaneli sait VPS-i ilma ootamatu katkestuseta, käsitle DNS-i kui viimast ümberlülitust, mitte esimest ülesannet. Valmista sihtserver ette, kopeeri konto, testi seda uuel IP-aadressil, vähenda DNS-i TTL-i ning muuda kirjeid alles pärast seda, kui rakenduse, e-posti ja SSL-i kontrollid on läbitud. Sait püsib kättesaadav, samal ajal kui töö toimub taustal.

Väikeettevõtte saidi, agentuurikonto või aktiivsete tellimustega poe puhul on migreerimine vähem seotud failide liigutamisega ja rohkem teenuse käitumise säilitamisega. PHP versioonid, andmebaasiõigused, cron-tööd, e-posti marsruutimine, ümbersuunamised ja tulemüürireeglid peavad kõik jõudma kohale teadaolevalt toimivas olekus. Failid on tavaliselt lihtne osa. Väikesed seaded, mis nende ümber peidus on, on need, mis migreerimistele hallid juuksed toovad.

Enne cPaneli saidi migreerimist VPS-i

Alusta olemasoleva konto inventuurist. Pane kirja domeeninimed ja alamdomeenid, konto kettakasutus, PHP versioon ja laiendused, andmebaaside suurused, cron-tööd, e-posti kontod, edasisuunamised, automaatvastajad, DNS-kirjed, SSL-sertifikaadid ning kõik välised teenused, mis sõltuvad serveri IP-aadressist. E-kaubanduse ja SaaS-i töökoormuste puhul tuvasta lisaks maksetagasihelistused, API lubatud nimekirjad, tehinguliste e-kirjade teenusepakkujad ja taustatöölised.

Kontrolli, kas siht-VPS-il on piisavalt varu. Kettaruumi peab jätkuma lähtekonto, ajutise migratsiooniarhiivi, andmebaaside, varukoopiate ja tavapärase kasvu jaoks. RAM-i ja CPU nõuded sõltuvad liiklusest ja tarkvarapaketist. Lihtne esitlussait võib töötada mugavalt tagasihoidlikul VPS-il; WooCommerce, Magento, suur WordPressi multisite või suure koormusega rakendus vajab tavaliselt rohkem mälu ja andmebaasimahtu.

Sihtkeskkond peaks olema ette valmistatud enne, kui tootmisandmeid kopeerima hakatakse. Määra serveri hostinimi, paigalda ja uuenda cPanel ning WHM, kui see on sinu valitud juhtpaneel, seadista nimeserverid, kui VPS hakkab DNS-i majutama, ning luba tulemüüris ainult vajalikud pordid. Kinnita, et varukoopiad on seadistatud sõltumatult lähte-serverist. Ainult VPS-is hoitav varukoopia on kasulik, kuid see ei ole täielik taasteplaan, kui VPS-il endal tekib probleem.

Kui liigud jagatud cPaneli majutusest VPS-i, kontrolli, mida varem sinu eest hallati. Vana majutusteenuse pakkuja võis hallata rämpsposti filtreerimist, DNS-i, SSL-i automaatset uuendamist, pahavaraskannimist või serveriväliseid varukoopiaid. Hallatud VPS-i puhul saab need punktid koos sinuga üle vaadata ja korras hoida. Haldamata serveri puhul muutuvad need sinu töökorralduslikuks vastutuseks. Kumbki lähenemine ei ole vale, kuid oletused on kallid.

Vähenda DNS-i TTL-i enne ümberlülitamist

Umbes 24 kuni 48 tundi enne planeeritud muudatust vähenda asjakohaste DNS-kirjete TTL võimalusel 300 sekundile. See võimaldab uuendatud A-, AAAA- ja MX-kirjetel ümberlülituse ajal kiiremini levida. Ära vähenda seda viis minutit enne kolimist ja eelda, et internet muutub selle suhtes filosoofiliseks. Rekursiivsetel resolveritel võib vana väärtus juba vahemällu salvestatud olla.

Hoia praegusest DNS-tsoonist enne selle muutmist koopia alles. Kui pärast ümberlülitust ilmub midagi ootamatut, on teadaolevate kirjete taastamine kiirem kui nende mälu järgi uuesti koostamine.

Vali õige ülekandemeetod

WHM-i Transfer Tool on tavaliselt kõige puhtam meetod täielike cPaneli kontode liigutamiseks ühilduvate serverite vahel. See kannab ühe kontrollitud protsessi käigus üle kontoandmed, andmebaasid, e-posti, DNS-tsooni teabe ja paljud kontotaseme seaded. Kasuta võimaluse korral root- või edasimüüjataseme ligipääsu ning kontrolli, et lähte-server lubab vajalikku SSH-ühendust.

Täielik cPaneli varukoopia võib samuti hästi toimida, kui otsene serverist-serverisse ülekanne pole saadaval. Loo varukoopia, vii see turvaliselt uude VPS-i ja taasta see WHM-i kaudu. See lähenemine on käsitsimahukam ning varukoopia võib kajastada kindlat ajahetke, mitte viimaseid muudatusi, seega planeeri lõplik sünkroonimine hoolikalt.

Ebatavaliste seadistustega rakenduste puhul võib käsitsi migreerimine olla turvalisem. Kopeeri veebisaidi failid rsynci või muu turvalise ülekandemeetodiga, ekspordi ja impordi andmebaasid, loo kasutajad ja õigused uuesti ning ehita konto välised seadistused uuesti üles. See võtab kauem aega, kuid annab rohkem kontrolli siis, kui lähte-süsteemis on kohandatud Nginxi reeglid, mittestandardsed rajad, väline salvestusruum või rakendusetöölised.

Väldi ainult public_html kataloogi kopeerimist, kui sa pole kinnitanud, et midagi muud pole vaja säilitada. E-post, andmebaasid, peidetud failid, cron-määratlused, SSL-materjalid ja konfiguratsioonifailid asuvad sageli sellest kaustast väljaspool.

Testi VPS-i enne avalikke DNS-i muudatusi

Kui konto on taastatud, valideeri sait sihtkoha IP vastu ilma avalikku DNS-i muutmata. Kohalik hosts-faili kirje võimaldab sinu arvutil lahendada domeeni uuele VPS-ile, samal ajal kui kõik teised jõuavad endiselt vana serverini. See on õige aeg leida puuduolev PHP laiendus, katkine ümberkirjutusreegel või andmebaasikasutaja, kes ei tulnud kaasa.

Testi peamisi lehti, sisselogimisvoogu, kontaktivorme, kassaprotsessi, haldusala, piltide üleslaadimist ja ajastatud ülesandeid. Vaata selle käigus üle rakenduse logid ja veebiserveri vealogid. Kontrolli, et sait kasutab ettenähtud PHP versiooni ja et failide omandiõigused on õiged. Leht, mis laeb korra, ei ole veel täielik test. See peaks ka andmebaasi kirjutama, saatma vajalikud sõnumid ja käsitlema autentitud seansse tavapäraselt.

Kontrolli enne ümberlülitamist ka SSL-i. Kui sertifikaat väljastatakse uuesti pärast seda, kui DNS osutab VPS-ile, kinnita, et veebiserveri virtuaalhost on õige ning pordid 80 ja 443 on ligipääsetavad. Kui tood kaasa olemasoleva sertifikaadi, paigalda selle sertifikaadiahel ja võti turvaliselt. Brauserid on sertifikaadivigade suhtes üsna ausad, mõnikord suurema draamaga kui vaja.

Käsitle e-posti veebiliiklusest eraldi

E-post on VPS-i migratsiooni kõige sagedamini tähelepanuta jääv osa. Kui domeen kasutab välist e-posti, näiteks Google Workspace’i või Microsoft 365, säilita olemasolevad MX-, SPF-, DKIM- ja DMARC-kirjed. Ära asenda neid kogemata kohalike cPaneli e-posti kirjetega.

Kui e-posti majutatakse cPanelis, vii postkastid üle ja testi VPS-is kirjade saatmist ning vastuvõtmist. DNS-i ülemineku ajal võivad uued kirjad jõuda kummassegi serverisse. Hoia vana majutuskonto aktiivsena vähemalt 48 kuni 72 tundi pärast ümberlülitust ning tee lõplik e-posti ja failide sünkroonimine, kui lähte-keskkond jääb aktiivseks. Suure mahuga e-posti või ärikriitiliste postkastide puhul planeeri läbimõeldum e-posti ümberlülitus, selle asemel et käsitleda seda kõrvalmõttena.

Lülita hoolikalt ümber ja hoia vana server saadaval

Kui testimine on puhas, vii saidi dünaamilised osad lühikeseks ajaks hooldusrežiimi, kui rakendus seda võimaldab. Käivita lõplik andmebaasi eksport või konto sünkroonimine, et haarata tellimused, vormiesitused, kasutajamuudatused ja sisuuuendused, mis tehti pärast esialgset ülekannet. Taasta või sünkroniseeri need lõplikud andmed VPS-is, seejärel eemalda hooldusrežiim pärast seda, kui uus keskkond on valmis.

Uuenda A-kirje uuele IPv4-aadressile ja AAAA-kirje ainult siis, kui IPv6 on seadistatud ja testitud. Kui ka nimeserverid muutuvad, tee see muudatus teadlikult ja kinnita, et uus tsoon sisaldab kõiki vajalikke kirjeid. Nimeserverite muutmine ja DNS-i samaaegne uuesti ülesehitamine lisab liikuvaid osi. Mõnikord on see vajalik, kuid see ei ole just kõige elegantsem DNS-i olukord.

Jälgi uut serverit esimestel tundidel. Kontrolli veebi juurdepääsulogisid, PHP ja rakenduse vigu, CPU koormust, mälusurvet, kettakasutust, e-posti järjekorra olekut ja andmebaasi aktiivsust. Kinnita, et automaatsed varukoopiad käivituvad edukalt ja et monitooring jõuab uue VPS-ini. kodu.cloudis on siin hallatud toimingud ja FASTCARE monitoring kasulikud: teenus on jälle stabiilne, sest keegi jälgib serveri tegelikku käitumist, mitte ainult avalehte.

Ära lõpeta vana teenust kohe. Jäta see võrku, kuni DNS-i levik on stabiliseerunud, e-posti voog on kinnitatud, varukoopiad on kontrollitud ja võtmekasutajad on reaalset saiti testinud. Enamiku tavapäraste saitide puhul on 72 tundi mõistlik turvaaken. Hoia selle perioodi jooksul valmis tagasipöördumisplaan: säilita vanad DNS-i väärtused, väldi hävitavaid muudatusi lähte-keskkonnas ja tea, kes teeb otsuse, kui tagasipöördumine osutub vajalikuks.

Migratsioonijärgsed kontrollid, mis hoiavad ära hilisemad probleemid

Pärast kolimist vaata üle ajastatud varukoopiad, säilitusperioodid, taaste testimine, turvauuendused, tulemüüri käitumine ja ressursitrendid. Eemalda oma kohalikust hosts-failist vanad testikirjed. Uuenda kõiki väliseid lubatud nimekirju, monitooringu sihtmärke, webhooki lõpp-punkte ja dokumentatsiooni, mis viitavad vanale IP-aadressile.

VPS annab sulle ka võimaluse koristada ära pikalt kogunenud majutussegadus. Eemalda mitteaktiivsed e-posti kontod, vanad staging-koopiad, mahajäetud andmebaasid ning pluginad või laiendused, mida enam ei vajata. Tee seda pärast seda, kui migratsioon on stabiilne, mitte kriitilise ülekandeakna ajal. Rahulikke muudatusi on lihtsam tagasi pöörata.

Hea migratsioon jätab endast maha rohkem kui lihtsalt saidi, mis juhtumisi laeb. See jätab maha serveri, mida saad jälgida, taastada, uuendada ja usaldada, kui liiklus saabub ebamugaval tunnil. Ehita see töövaru migratsiooni sisse ja järgmine hooldusülesanne tundub palju vähem päästeoperatsioonina.

Andres Saar klienditoe insener