Kuidas migreerida veebisaidi server ilma katkestuseta
Avaldatud 15. juulil 2026
Alustage migreerimist täieliku taastatava varukoopia ja kirjaliku ümberlülitusplaaniga. See on kõige turvalisem vastus küsimusele, kuidas migreerida veebisaidi serveritaristut nii, et tavapärane kolimine ei muutuks katkestuseks. Teie uus server peaks olema valmis ehitatud, turvatud ja testitud enne, kui DNS suunab külastajaid selle poole. Vana server jääb võrku seni, kuni uus keskkond on läbinud päris kontrollid.
Serveri migreerimine on enamat kui veebisaidi failide kopeerimine. Teenuse osaks võivad olla veebisait, andmebaas, ajastatud ülesanded, e-posti marsruutimine, SSL-sertifikaadid, rakenduse käitusaeg, vahemälu käitumine, DNS-kirjed ja tulemüüri reeglid. Ühe väikese sõltuvuse kahe silma vahele jätmisel võib sait avalehel näida korras, samal ajal kui ostukorvi e-kirjad, vormid või taustatööd vaikselt ebaõnnestuvad. Mitte just eriti glamuurne tõrge, aga siiski kulukas.
Kaardistage praegune server enne selle kolimist
Alustage inventuuriga selle kohta, mis tegelikult töötab. Ärge tuginege ainult sellele, mida majutuse juhtpaneel näitab. Kontrollige dokumendijuurt, rakenduse versiooni, andmebaasimootorit ja selle versiooni, PHP või Node.js-i sätteid, cron-töid, järjekorra töötlejaid, salvestusteid, ümbersuunamisi, keskkonnamuutujaid ja väljuva e-posti konfiguratsiooni.
Äriveebisaidi puhul tehke kindlaks ka kõik, mis jääb peadomeenist väljapoole. See võib hõlmata alamdomeene, testkeskkonna saite, API lõpp-punkte, maksete tagasikutseid, objektisalvestust, kolmanda osapoole e-posti teenusepakkujaid, analüütikaskripte ja kinnitamiseks kasutatavaid DNS-kirjeid. Kui server saadab kirju otse, märkige üles selle saatmise IP, pöörd-DNS-i seadistus, SPF-, DKIM- ja DMARC-kirjed. E-post on sageli viimane asi, mida märgatakse, ja esimene asi, mille üle kliendid kaebavad.
Dokumenteerige ka praeguse serveri ressursikasutus. Vaadake üle CPU koormus, mälukasutus, kettaruum, andmebaasi suurus, liiklusmustrid ja vealogid. See ütleb teile, kas uus VPS või pühendatud server on õigesti mõõdistatud. Migreerimine on hea hetk jätta selja taha liiga väike ketas, aegunud PHP versioon või server, mis on püsinud töös peamiselt tänu optimismile.
Valmistage uus keskkond esmalt ette
Seadistage sihtserver enne tootmisandmete kopeerimist. Rakendage operatsioonisüsteemi uuendused, looge piiratud haldusjuurdepääs, konfigureerige tulemüür ja paigaldage ainult need teenused, mida sait vajab. Kasutage võimaluse korral ainult parooliga juurdepääsu asemel SSH-võtmeid. Keelake mittevajalikud teenused ja veenduge, et automaatsed turvauuendused vastavad teie tegevuspoliitikale.
Viige see hoolikalt vastavusse rakenduse nõuetega. Sait, mis liigub PHP 7.4-lt PHP 8.3-le või MySQL-ilt uuemale MariaDB väljalaskele, võib vajada koodimuudatusi, enne kui see käitub õigesti. Sama kehtib veebiserveri konfiguratsiooni kohta. Apache'i rewrite-reeglid, Nginx-i asukohad, failiõigused ja PHP laiendused ei kandu alati üks ühele üle.
Seadistage seire enne ümberlülitust, mitte pärast intsidenti. Jälgige saadavust, reageerimisaega, CPU-d, mälu, kettakasutust, SSL-i aegumist ja olulisi teenuseporte. Tausttöötlusega rakenduste puhul jälgige ka järjekorra sügavust ja nurjunud töid. Kui hallatud taristu ja seire on paigas, räägivad logid nüüd sama lugu, selle asemel et jätta teid oletama pärast seda, kui külastajad probleemist teatavad.
Varundage taastamiseks, mitte ainult meelerahu jaoks
Looge vahetult enne migreerimisakent värske varukoopia. See peaks hõlmama veebisaidi faile, andmebaase, konfiguratsioonifaile, kasutajate üles laaditud faile ja kõiki veebijuurest väljaspool talletatud rakenduse saladusi. Veenduge, et varukoopiat saab taastada eraldi asukohta. Varukoopia, mida pole kunagi testitud, on lootusrikas arhiiv, mitte taasteplaan.
Andmebaaside puhul kasutage järjepidevat eksporti. Suured või aktiivsed andmebaasid võivad vajada erilist käsitlemist, et vältida andmete kopeerimist nende muutumise ajal. Olenevalt andmebaasist ja rakendusest võite kasutada hooldusakent, kirjutuskaitstud režiimi, replikatsiooni või viimast inkrementaalset sünkroonimist. E-kaubanduse poed, broneerimissüsteemid, SaaS-tooted ja liikmesaidid vajavad erilist hoolt, sest tellimused ja kontomuudatused võivad saabuda iga minut.
Hoidke algne server kolimise ajal muutmata. Ärge tühistage seda ega kustutage andmeid kohe, kui failid ilmuvad sihtkohta. Vana keskkonna säilitamine annab teile puhta tagasipöördumise tee, kui pärast ümberlülitust ilmneb mõni varjatud sõltuvus.
Kandke failid ja andmebaasid üle etappide kaupa
Kopeerige esialgne andmestik, kuni olemasolev sait jääb aktiivseks. Turvalised failiedastusvahendid, näiteks rsync üle SSH, on kasulikud, sest need saavad hilisema lõpliku läbimise ajal sünkroonida ainult muutunud faile. Andmebaaside puhul importige esialgne tõmmis uude serverisse, seejärel testige rakendust selle vastu ajutise hostinime või kohaliku hosts-faili ülekirjutusega.
Vältige ainult esilehe testimist. Logige sisse administraatorina ja tavakasutajana. Saatke kontaktivorm, lähtestage parool, laadige üles fail, tehke vajaduse korral testost, vaadake üle tehingulised e-kirjad ja kinnitage, et ajastatud ülesanded töötavad. Kontrollige testimise ajal rakenduse logisid ja veebiserveri vealoge. Edukast HTTP 200 vastusest ei piisa tõendiks, et teenus on terve.
Kui muudate samal ajal ka serveri arhitektuuri, eraldage muudatused võimaluse korral üksteisest. Näiteks uuele VPS-ile kolimine on piisavalt suur töö ka ilma selleta, et samal õhtul veel andmebaasi ümber kujundada, vahemälu kihti asendada ja rakendusraamistikku uuendada. Eraldi projektid muudavad tõrgete diagnoosimise ja tagasipööramise lihtsamaks.
Vähendage DNS-i TTL-i enne ümberlülitust
DNS on koht, kus tehniliselt edukas migreerimine võib külastajatele segaseks muutuda. Vähendage asjakohaste A-, AAAA-, CNAME- ja e-postiga seotud kirjete TTL-i 24 kuni 48 tundi enne kavandatud ümberlülitust. Madalam TTL julgustab lahendajaid kirjeid kiiremini värskendama, kui suunate domeeni uude serverisse.
See ei taga, et iga lahendaja uuendab end kohe. Mõned võrgud vahemällustavad kauem, kui küsitud, ja kasutajatel võib olla kohalik DNS-i vahemälu. Planeerige üleminekuperiood, mille jooksul võib väike osa liiklusest siiski jõuda vana serverini. Kui sait võtab vastu muutuvaid andmeid, vajate selle kattuvuse jaoks strateegiat. Hooldusrežiim lõpliku sünkroonimise ajal on sageli turvalisem kui uute tellimuste vastuvõtmine kahes eraldi serveris.
Ärge muutke nimeservereid, välja arvatud juhul, kui on põhjus kolida ka DNS-hostingut. Autoritatiivsete nimeserverite muutmine lisab veel ühe levimiskihi ja rohkem kirjeid, mida kontrollida. Hoidke migreerimine nii igav kui võimalik. Igav taristu on tavaliselt terve taristu.
Tehke lõplik sünkroonimine ja lülitage liiklus ümber
Kokkulepitud ümberlülitusajal pange rakendus hooldusrežiimi, kui see kirjutab kliendiandmeid. Peatage vana serveri järjekorra töötlejad ja ajastatud ülesanded, et need ei saaks sama ülesannet kaks korda töödelda. Käivitage lõplik failide sünkroonimine ning andmebaasi eksport/import, seejärel uuendage sihtkoha konfiguratsioon tootmisandmebaasi mandaatide, rakenduse võtmete ja õigete URL-idega.
Lubage rakendus uues serveris ja uuendage DNS selle IP-aadressile. Kinnitage, et SSL-sertifikaat on paigaldatud ja HTTP suunab õigesti HTTPS-ile. Kui saidi ees asub koormusjaotur, CDN või puhverserver, uuendage selle päritolukonfiguratsiooni ja veenduge, et see tunneb ära uue serveri tervisekontrollid.
Jälgige levimise ajal mõlemat serverit. Uus server peaks näitama saabuvaid päringuid, samal ajal kui vana server peaks saama järjest vähem liiklust. Vaadake üle 404-, 500- ja õiguste vead ning ka rakendusespetsiifilised häired. Hoidke ressursikasutusel silm peal, sest uus server võib päris liikluse all käituda teisiti kui testimisel.
Valideerige teenus pärast migreerimist
Kui liiklus jõuab uude keskkonda, tehke keskendunud tootmiskontroll. Kinnitage, et põhilehed laadivad, kasutajad saavad autentida, vormid toimivad, makse- või broneerimisvood töötavad, juhtpaneelid kuvavad jooksvaid andmeid ja üles laaditud failid on kättesaadavad. Võimaluse korral testige rohkem kui ühest võrgust, sest teie enda arvutil võib DNS endiselt vahemälus olla.
Kontrollige ajastatud tegevust järgmise mitme tunni jooksul. Cron-tööd, varukoopiad, uuendamised, aruanded, järjekorra töötlejad ja webhooki vastuvõtjad paljastavad migreerimisprobleeme sageli pärast seda, kui esialgne valideerimine on läbitud. Vaadake üle ka e-posti logid ja kohaletoimetamisaruanded. Kui sait kasutab kaug-SMTP teenust, kinnitage, et uue serveri IP või hostinimi on volitatud.
Jätke vana server kättesaadavaks vähemalt 48 kuni 72 tunniks, keerukate rakenduste või aeglaste DNS-keskkondade puhul kauemaks. Selle aja jooksul säilitage varukoopiad mõlemalt poolelt ja ärge tehke asjassepuutumatuid konfiguratsioonimuudatusi. Kui seire on puhas, liiklus stabiilne ja tagasipöördumise aken möödas, võtke vana server turvaliselt kasutusest maha.
Teadke, millal kasutada hallatud abi
Lihtne esindussait saab tavaliselt kolitud hoolika ettevalmistuse ja lühikese hooldusaknaga. Suure liiklusega pood, paljude kliendisaitidega agentuuriportfell, SaaS-platvorm või kohandatud teenustega server väärib rohkem kontrollitud plaani. Andmebaasi replikatsioon, etapiviisilised väljalasked, liikluse äravool ja aktiivne seire vähendavad riski, kuid vajavad ka kogenud käsi.
kodu.cloud saab aidata migreerimise operatiivse poolega alates sihtserveri ettevalmistamisest ja varundamisest kuni seire ja valideerimiseni. Eesmärk ei ole muuta protsessi müstiliseks. Eesmärk on tagada, et keegi jälgib taristut samal ajal, kui teie hoiate äri liikumas.
Hea migreerimine lõpeb vaikselt: külastajad kasutavad saiti, ajastatud tööd käivad, varukoopiad valmivad ja keegi ei pea saatma ärevat kõigile suunatud sõnumit. Hoidke alles plaan, varukoopia ja vana server, kuni tõendid näitavad, et teenus on taas rahulik.
Andres Saar klienditoe insener