Serverite avariitaaste testi näide
Avaldatud 31. oktoobril 2026
Varukoopia, mida pole kunagi taastatud, ei ole veel taasteplaan. See on lihtsalt lootusrikas fail, mis asub kusagil mujal. See avariitaaste testi näide näitab, kuidas väike majutustiim, agentuur või serveriomanik saab testida realistlikku tõrget, muutmata tavapärast õppust tootmiskeskkonna intsidendiks.
Eesmärk on lihtne: tõestada, et suudate taastada teenused, mida inimesed tegelikult kasutavad, ettevõttele sobiva aja jooksul. See tähendab veebisaite, andmebaase, DNS-kirjeid, e-posti, kui seda majutatakse samas serveris, ning juurdepääsu, mida on vaja pärast taastamist kõige haldamiseks.
Mida peaks avariitaaste test tõestama
Kasulik test teeb enamat kui kinnitab, et varundustöö on lõpule jõudnud. See annab vastused praktilistele küsimustele: kas leiate õige varukoopia? Kas suudate selle puhtasse serverisse taastada? Kas veebisait laaditakse õigesti? Kas andmebaas on piisavalt ajakohane? Kas volitatud tiimiliige saab sisse logida ja juhtimise üle võtta?
Siin muutuvad oluliseks kaks taaste-eesmärki. Taastepunkti eesmärk ehk RPO määrab, kui palju andmeid võite endale lubada kaotada. Kui varukoopiaid tehakse igal ööl, võite kaotada kuni ühe päeva muudatused. Taasteaja eesmärk ehk RTO määrab, kui kaua võib teenus kättesaamatu olla. Isiklik portfoolio võib taluda mitmetunnist katkestust. Veebipood, mis võtab tellimusi vastu, tõenäoliselt ei saa seda endale lubada.
Määrake need eesmärgid enne õppust. Vastasel juhul võib taastamine näida edukas lihtsalt seetõttu, et see lõpuks õnnestus, isegi kui see võttis kuus tundi, ehkki ettevõte vajas teenust tagasi ühe tunni jooksul.
Avariitaaste testi näide: rikkis veebiserver
Kujutage ette agentuuri, mis majutab ühes Linuxi serveris 25 kliendi veebisaiti. Serverist tehakse iga päev täielik varukoopia, andmebaasidest varukoopiad iga nelja tunni järel ning varukoopiaid hoitakse tootmisserverist eraldi. Ühel esmaspäeva hommikul muudab kettarike serveri kättesaamatuks.
Testi jaoks ärge tootmiskeskkonda välja lülitage. Looge kontrollitud simulatsioon eraldi taasteserveris või isoleeritud virtuaalmasinas. Valige esimese õppuse jaoks kõigi 25 asemel üks tüüpiline veebisait. Valige sait, millel on andmebaas, meediafailide üleslaadimine, SSL, ajastatud ülesanded ja päris administraatori sisselogimine. Lihtne staatiline leht on liiga väike proovikivi, et palju tõestada.
Testistsenaariumi võib kirja panna järgmiselt:
Intsident: tootmisserver on kettarikke tõttu jäädavalt kättesaamatu.
Taaste-eesmärk: taastada valitud veebisait ja selle andmebaas asendusserverisse 90 minuti jooksul, kaotamata rohkem kui nelja tunni andmeid.
Edukriteeriumid: veebisait avaneb ajutise hostinime või hosts-faili testi kaudu, lehed laaditakse HTTPS-i kaudu, administraatorialale saab sisse logida, värske sisu on olemas, üleslaaditud failid kuvatakse, vormid töötavad õigesti, ajastatud ülesanded käivituvad ja serverilogides pole kriitilisi rakendusvigu.
See on sihipärane test, kuid toob esile asjaolud, mis tavaliselt viivitusi põhjustavad: puuduvad juurdepääsuandmed, mittetäielikud varukoopiad, DNS-iga seotud eeldused, versioonide ühildumatus ja ebaselge vastutus.
Enne testi tehke taastamise käik selgeks
Taastamistest ei tohiks sõltuda sellest, kas keegi mäletab kahe aasta tagust käskude kogu. Pange kirja, kus varukoopiaid hoitakse, kuidas neile ligi pääseb, kes saab DNS-i muudatused heaks kiita ja millised teenused tuleb esimesena taastada.
Veenduge, et teie varukoopiate salvestuskoht asub tootmisserverist eraldi. Ainult veebisaitidega samal kettal hoitavad varukoopiad on kasulikud kogemata kustutatud failide taastamiseks, kuid serveri kaotuse korral pole neist suurt abi. Kontrollige ka, et taastamiseks vajalikud juurdepääsuandmed oleksid kättesaadavad ka siis, kui server ei tööta. See hõlmab juurdepääsu varukoopiate salvestuskohale, domeeniregistraatorile ja DNS-i teenusepakkujale, SSH-võtmeid, litsentsiandmeid ning kõiki vajalikke rakenduse saladusi.
Kui kasutate serveri halduspaneeli, dokumenteerige nii klõpsud kui ka tehnilised sätted. See pole otsetee. Nii saab taastamise muuta korratavaks selle inimese jaoks, kes intsidendi ajal saadaval on. FASTPANEL aitab hoida veebisaite, andmebaase, varukoopiaid ja serveri sätteid ühes hallatavas kohas, kuid test vajab siiski selget vastutajat ja tõendusmaterjali.
Korraldage õppus ohutus järjekorras
Käivitage taimer, kui tiim saab simuleeritud intsidendi teate. Pange kirja kellaaeg, iga toimingu tegija ja kõik otsused, mis takistavad edasiliikumist. Need märkmed on osa testi tulemusest, mitte lihtsalt asjaajamine asjaajamise pärast.
Esmalt seadistage taastekeskkond. Kasutage võimaluse korral võimalikult sarnaseid operatsioonisüsteemi ja nõutavate käituskeskkondade versioone. Täielik koopia pole alati vajalik, kuid operatsioonisüsteemi, PHP versiooni, andmebaasi versiooni ja veebiserveri konfiguratsiooni samaaegne muutmine raskendab tõrkeotsingut. Kui taastekeskkond erineb, dokumenteerige need erinevused.
Seejärel laadige valitud varukoopia alla ja kontrollige selle kuupäeva. Taastage veebisaidi failid ja andmebaas ning lisage seejärel rakenduse konfiguratsiooniväärtused, mida on ühenduse loomiseks vaja. Ärge eeldage, et konfiguratsioonifailid sisaldavad kõike vajalikku. Paljud rakendused sõltuvad keskkonnamuutujatest, API-võtmetest, e-posti sätetest, cron-töödest või õigustest, mis asuvad väljaspool veebisaidi kataloogi.
Tehke taastatud sait kättesaadavaks ajutise URL-i, testdomeeni või kohaliku hosts-faili kirje kaudu. Ärge suunake avalikku DNS-i taasteserverisse enne, kui teate, et sait töötab. Kontrollige avalehte, mitut sisemist lehte, pilte, vorme, kontole sisselogimist ja haldusala. WordPressi saidi puhul kontrollige ka püsiviiteid, pluginaid, üleslaaditud faile ja ajastatud avaldamist.
Seejärel kontrollige saidiga seotud teenuseid. Veenduge, et SSL-sertifikaadi saab paigaldada või uuendada, väljaminev e-post on seadistatud ootuspäraselt, ajastatud ülesanded on olemas ning andmebaasi kasutajatel on ainult neile vajalikud õigused. Avalehe edukas laadimine on hea algus, mitte lõpp-punkt.
Testige ka tõrkesiirde otsust
Tehniline taastamine on vaid pool avariitaastest. Teine pool on otsustada, millal ja kuidas liiklus asendusserverisse suunatakse.
Selle õppuse käigus simuleerige DNS-i muudatust pärast seda, kui taastatud sait on kontrollid läbinud. Mõõtke, kui kaua võtab muudatuse ettevalmistamine ja sellest teavitamine, mitte ainult seda, kui kaua DNS-i levimine internetis aega võtab. DNS-i väiksemad TTL-väärtused võivad ooteaega lühendada, kuid need tuleks paika panna enne katkestust. TTL-i muutmine intsidendi ajal aitab harva kohe, sest lahendajad võivad vana väärtuse juba vahemällu salvestanud olla.
Kui teie lahendus kasutab koormusjaoturit, pöördpuhverserverit või pilvepõhist tõrkesiirdeteenust, testige ainult DNS-ile lootmise asemel seda mehhanismi. Õige lähenemisviis sõltub teie arhitektuurist. Mõne ettevõtte veebisaidiga üksikserveri saab DNS-i kaudu täiesti hästi taastada. Majutusteenuse pakkuja või suure tehingumahuga pood võib vajada kiiremat tõrkesiirdelahendust ja varukeskkonda, mis on kasutuselevõtuks valmis.
Pange kirja tulemused, mille põhjal saab tegutseda
Õppuse lõpus ärge kirjutage lihtsalt „taastamine õnnestus”. Pange kirja tegelik taastamisaeg, varukoopia vanus, ebaõnnestunud kontrollid ja vajalikud käsitsi tehtavad toimingud. Võrrelge neid näitajaid oma RTO ja RPO-ga.
Näiteks võib tiim taastada veebisaidi 52 minutiga, kuid avastada, et uusim andmebaasi varukoopia on kuus tundi vana. Serveri taastamine vastas 90-minutilisele RTO-le, kuid andmete taastamine ei vastanud neljatunnisele RPO-le. See on siiski väärtuslik tulemus, sest osutab konkreetsele parandusele: teha andmebaasist sagedamini varukoopiaid või võtta vajaduse korral kasutusele tehingutaseme kaitse.
Levinud probleemid on ebapiisav varukoopiate säilitamine, testimata juurdepääsuandmed, varukoopia, millest üleslaaditud failid puuduvad, ühildumatud tarkvaraversioonid ning DNS-i juurdepääs, mis on seotud ühe töötaja kontoga. Parandage esmalt kõige suurema riskiga probleem, määrake vastutaja ja seadke tähtaeg. Järeltegevuseta test on vaid sama probleemi peaproov.
Kui sageli peaksite teste tegema?
Enamiku väikeettevõtete jaoks on kord kvartalis tehtav taastamistest praktiline lähtekoht. Testige sagedamini pärast suuri muudatusi, näiteks serveri migreerimist, uue varundusteenuse pakkuja kasutuselevõttu, andmebaasi uuendamist, rakenduse ümberkujundamist või taristu haldaja vahetumist.
Vahetage testide ulatust. Ühel kvartalil taastage üks kriitiline veebisait ja andmebaas. Järgmisel testige kogu serveri uuesti ülesseadmist. Hiljem testige kontole juurdepääsu tõrget või kogemata kustutamise olukorda. Erinevad tõrked toovad esile erinevad nõrgad kohad ning kasuliku õppetunni saamiseks pole vaja iga kord võimalikult suurt kaost tekitada.
Parim avariitaasteplaan on selline, mille tiim suudab rahulikult ellu viia, kasutades juba käepärast teavet. Pange järgmine test kalendrisse enne, kui see õppus mälust kaob, ning muutke taastamine iga korraga veidi kiiremaks ja selgemaks.