Varunduse taastamise juhtumiuuring: 6 tundi tagasi

Avaldatud 10. juulil 2026

Kell 02:14 UTC lõpetas veebipood tellimuste kirjutamise andmebaasi. Kella 02:19-ks teenindas sait endiselt vahemälustatud lehti, kuid ostuprotsess oli juba muutunud fiktsiooniks. See varunduse taastamise juhtumiuuring käsitleb, mis juhtus järgmisena väikese e-kaubanduse ettevõtte tootmis-VPS-is, mida me taastasime, mida me ei taastanud pimesi ja miks teenus oli enne päikesetõusu taas stabiilne.

Kliendil oli kasvava veebipoe jaoks üsna tavaline tarkvarapakk - Nginx, PHP-FPM, MariaDB, Redis ja juhtpaneel, mida kasutasid kaks mitte-süsteemiadministraatorist töötajat. Liiklust ei olnud tohutult, kuid ajastus oli valus. Müügikampaania oli tellimuste mahu üles viinud, andmebaasi kirjutamised olid tipptasemel ning failisüsteemi kihi salvestusprobleem hakkas rikkuma aktiivseid andmebaasitabeleid. Mitte dramaatiline Hollywoodi stiilis, kuid piisavalt tõsine, et iga minut luges.

Esimene töö ei olnud taastamine. Esimene töö oli peatada kahju levik. Panime rakenduse hooldusrežiimi, säilitasime ülevaatuseks ketta praeguse oleku ning kontrollisime, kas replikatsioon, tõmmised või loogilised tõmmised annavad meile puhtaima taastepunkti. See on olulisem, kui inimestele meeldib tunnistada. Kiire taastamine on hea. Kiire taastamine kahjustatud andmeteni on lihtsalt kiire pettumus.

Mis ebaõnnestus ja kuidas me seda teadsime

Logid rääkisid nüüd sama lugu. MariaDB hakkas raporteerima InnoDB lehekülje kontrollsumma vigu, millele järgnesid kirjutusmahukate tellimuste ja seansside tabelite kokkujooksmised. Hüperviisor ise oli terve. CPU, RAM-i ja võrgu käitumine püsis normaalne. See kitsendas sündmuse laiapõhjalisest platvormikatkestusest eemale ja külalistaseme salvestuse tervikluse suunas.

Kontrollisime enne varukoopiate puudutamist kolme asja. Esiteks, kas probleem piirdus väikese hulga tabelitega ja kas seda sai kohapeal parandada. Teiseks, kas hiljutised varukoopiad olid kehtivad ja ühendatavad. Kolmandaks, kas pärast viimast teadaolevalt head varukoopiat lõpetatud tehinguid sai rekonstrueerida rakenduse logidest, e-posti kinnitustest või makselüüsi kirjetest.

See kolmas kontroll jäetakse sageli vahele. Nii ei tohiks teha. Varukoopia taastamine ei ole kogu taastamine. Ettevõtteid huvitavad puuduvad tellimused, kliendiandmed ja arvete olek, mitte ainult see, kas MySQL uuesti käivitub.

Taastetee, mille valisime

See varunduse taastamise juhtumiuuring on kasulik, sest ilmne valik ei olnud parim valik. Meil oli kolm võimalikku teed.

Täielik VM-i tõmmise tagasipööramine oleks klikkide arvu mõttes olnud kiireim, kuid see oleks ka kõrvale heitnud mitu tundi õiguspäraseid sisumuudatusi, pluginate uuendusi ja kliendikontode muudatusi. Tabelite kohapealne parandamine kandis liiga suurt riski, sest rike oli juba puudutanud põhilisi tehinguandmeid. Parem tee oli taastamine failitasemel ja andmebaasitasemel värskesse instantsi, millele järgnes valikuline andmete kooskõlastamine.

Seega lõime kõigepealt puhta taastekeskkonna. Sama VPS-i suurus, sama OS-i perekond, sama paneeli versioon, sama PHP haru. Paralleelsesse instantsi ümberehitamine annab hingamisruumi. See kaitseb ka algset süsteemi kohtuekspertiisi ülevaatuseks, mis on kasulik juhul, kui klient peab mõistma algpõhjust või kontrollima, et probleemi ei põhjustanud rakenduse käitumine.

Tõime viimase eduka automaatse varukoopia ajast 23:00 UTC. Seejärel testisime seda enne ümberlülitust. See kõlab elementaarselt, kuid paljud meeskonnad avastavad varukoopiate probleemid alles kõige halvimal võimalikul tunnil. Arhiiv ühendus korrektselt, kontrollsummad klappisid, andmebaasi import lõpetati vigadeta ja rakendus käivitus isoleeritult. Hea. Rahulikkus algab sealt.

Teenuse taastamine ilma uusi probleeme tekitamata

Taastamisel oli neli etappi. Esiteks taristu. Ehitasime veebipinu uuesti üles, rakendasime juba heaks kiidetud süsteemiuuendused ja sobitasime käitusversioonid, et rakendus ei ebaõnnestuks ootamatu sõltuvuste mittevastavuse tõttu.

Teiseks andmed. Andmebaasi taastamine lõpetati 11 minutiga. Veebifailid taastati vähem kui 4 minutiga. Meediaressursid olid terved, mis säästis klienti katkistest tootekujutistest ja vihastest brauserikastidest. Redist ei taastatud varukoopiast, sest vahemäluandmed on olemuselt asendatavad. Aegunud vahemälu tagasi toomine värskesse keskkonda on üks neist väikestest vigadest, mis hiljem suure segaduse tekitavad.

Kolmandaks valideerimine. Kontrollisime rakenduse sisselogimist, ostuprotsessi voogu, administraatori kirjutamisi, cron'i täitmist, SSL-i kehtivust, väljaminevat posti ja makselüüsi tagasikutse käitumist. Võrdlesime ka tellimuste, klientide ja kataloogitabelite kirjete arvu eelmise nädala oodatavate kasvukõveratega. Numbrid ei pea olema täiuslik poeesia, kuid need ei tohiks tunduda kummalised.

Neljandaks kooskõlastamine. Ajavahemikus 23:00 UTC kuni 02:14 UTC oli töödeldud käputäis edukaid makseid. Neid kirjeid taastatud andmebaasis ei olnud, sest need toimusid pärast varukoopia punkti. Taastasime need makseteenuse pakkuja kinnituste, e-posti tellimusteavituste ja veebiligipääsulogide põhjal. See on koht, kus kogenud operaator säästab ettevõttele palju valu. Tehniliselt edukas taastamine, mis kaotab tasutud tellimused, ei ole tegelikult edu.

Kell 03:41 UTC oli rakendus kliendi sisemiseks ülevaatuseks kättesaadav. Kell 04:06 UTC suunasid DNS ja servaruutimine tootmisliikluse tagasi taastatud instantsi. Kokku oli kliendile nähtav ostuprotsessi häire veidi alla kahe tunni, samal ajal kui lugemisjuurdepääs suuremale osale saidist püsis suure osa intsidendi ajast saadaval.

Mis tegi taastamise kiireks

See ei olnud õnn ega ka üks maagiline varundusnupp. Kiirus tuli ettevalmistusest ja sellest, et intsidendi ajal vähendati otsuste hulka.

Kliendil olid juba automaatsed ajastatud varukoopiad koos säilitamisega, jälgitud serveri käitumine ja toe tee, mis ei kadunud piletivaikusesse. See muutis öö kulgu. Me ei arutanud, kas varukoopia on olemas. Valisime kõige turvalisema taastepunkti ja valideerisime selle.

Oluline oli ka keskkonna järjepidevus. Kuna majutuspinu oli standardiseeritud, ei kulutanud me 45 närvilist minutit avastamisele, et taastatud rakendus vajas vana PHP laiendust või puuduvat süsteemiteeki. Inimesed alahindavad sageli seda, kui palju taastamisaega konfiguratsiooni triiv ära põletab.

Oli ka üks vähem nähtav võit - eraldada see, mis on olekuandmetega, sellest, mis on asendatav. Andmebaasi sisu, üles laaditud meedia, konfiguratsiooni ja SSL-varasid käsitleti hoolikalt. Vahemälu, ajutised failid ja genereeritud seansid ehitati puhtalt uuesti üles. See hoiab taastamise saledana ja väldib vana müra kaasa kandmist uude käivitusse.

Mida see varunduse taastamise juhtumiuuring õpetab

Peamine õppetund ei ole lihtsalt see, et varunda oma serverit. Enamik ettevõtteid teab seda lauset juba. Raskem õppetund on kujundada taastamine ümber ärifunktsiooni, mitte ainult taristuobjektide.

VM-i tõmmis on kasulik, kuid see võib olla liiga jäme. Andmebaasi tõmmis on kasulik, kuid mitte piisav, kui üles laaditud failid on eraldi. Juhtpaneeli varukoopia on mugav, kuid mugavust tuleks siiski testida. Õige varundusstrateegia sõltub sellest, kuidas rakendus käitub, kui sageli andmed muutuvad ja milline kaotuse hulk on tegelikult vastuvõetav.

E-kaubanduse saidi puhul taluvad tootepildid tavaliselt veidi vanemaid taastepunkte kui tellimuskirjed. SaaS-rakenduse puhul võib kliendiandmebaasi olek olla olulisem kui kohaliku failisüsteemi sisu. Mitut kliendisaiti ühes serveris majutava digitaalagentuuri jaoks muutub isoleerimine kriitiliseks, sest üks lärmakas sait ei tohiks muuta taastamist kogu riiuli peavaluks.

Ka testimine väärib rohkem lugupidamist. Varukoopiad on lubadused, kuni need on taastatud. Pärast taastamist saavad neist tõendid. Erinevus on kulukas.

Mis muutus pärast intsidenti

Me ei käsitlenud taastamist finišijoonena. Pärast teenuse stabiliseerimist vaatasime üle salvestuskäitumise, failisüsteemi tervise, andmebaasi tervikluse kontrollid ja varunduspoliitika ajastuse. Vahetu tehniline põhjus viitas kirjutussurve all tekkinud külalistaseme ketta ebajärjekindlusele, kuid laiem küsimus oli, kuidas järgmine kord mõjuraadiust vähendada.

Andmebaasikihi varundussagedust kohandati, et kampaaniate ajal lühendada taastepunkti kokkupuudet. I/O ooteaja ja andmebaasivigade mustrite häirelävesid karmistati. Klient liikus ka ühe taastamise mõtteviisilt kihilise mõtteviisi juurde - automaatsed varukoopiad, kontrollitud taastamisrutiinid ja selgem käsitlus tehingute kooskõlastamiseks.

See on koht, kus hallatud operatiivtugi tasub end ära. Mitte sellepärast, et intsidente kunagi ei juhtu, vaid sellepärast, et kui need juhtuvad, teab keegi juba, kuhu esmalt vaadata ja mida parandamise ajal mitte katki teha. See väike erinevus on sageli kogu erinevus.

Kui käitate tulu teenivaid töökoormusi, ei ole kasulik küsimus see, kas teil on varukoopiad. Kasulik küsimus on, kas suudate kell 2 öösel taastada õiged andmed õigesse kohta, need kiiresti kontrollida ja arvestada sellega, mis juhtus pärast varukoopia tegemist. Kui vastus on ebakindel, vajab süsteem endiselt tähelepanu. Parem sellele vastata vaiksel pärastlõunal kui ostuprotsessi tõrke ajal.

Andres Saar klienditoe insener