Toimiv veebisaitide varukoopiate säilitamispoliitika
Avaldatud 14. augustil 2026
Veebisaitide varukoopiate säilitamispoliitika peaks andma teile mitu hiljutist taastepunkti, mõned vanemad taastamisvõimalused ja vähemalt ühe koopia väljaspool serverit, kus sait töötab. Kui pistikprogrammi uuendus rikub kassaprotsessi kell 10:15, vajate puhast versiooni kell 10:00, mitte eelmise teisipäeva varukoopiat ja lootusrikast näoilmet.
Õige ajakava sõltub sellest, kui sageli teie andmed muutuvad, kui palju seisak maksab ja kui kiiresti teie meeskond suudab tuvastada, millal probleem algas. Staatilist ettevõtte saiti ja hõivatud WooCommerce'i poodi ei tohiks kaitsta ühtemoodi. Teenus võib olla võrgus, kuid kui eilse päeva tellimused, vormide esitused või kliendimuudatused puuduvad, ei ole kõik veel täielikult korras.
Mida veebisaidi varukoopiate säilitamispoliitika peab hõlmama
Säilitamine ei ole lihtsalt alles hoitavate varukoopiate arv. See on reeglite kogum, mis otsustab, millised varukoopiad jäävad kättesaadavaks, kus neid hoitakse, kui kaua need seal püsivad ja millal need kustutatakse.
Kasulik poliitika arvestab kolme eraldi taastamisvajadusega. Esiteks vajate kiiret operatiivset taastamist hiljutiste vigade jaoks: halb juurutus, kustutatud failid, nurjunud uuendus või juhuslik konfiguratsioonimuudatus. Teiseks vajate ajaloolist taastamist, kui probleem on nädalaid vaikselt püsinud, näiteks kompromiteeritud administraatorijuurdepääs või nakatunud kood. Kolmandaks võib olla vaja säilitada andmeid äriliste, lepinguliste või regulatiivsete põhjuste tõttu.
Need eesmärgid võivad olla vastuolus. Iga varukoopia igaveseks alleshoidmine tekitab salvestuskulu, aeglasemaid varundustöid ja segase taastamisloendi. Liiga vähese alleshoidmine säästab ruumi täpselt seni, kuni vajalik varukoopia on juba aegunud. Mõistlik lahendus on astmeline säilitamine, mitte üks pikk rida ühesuguseid igapäevaseid varukoopiaid.
Alustage taastamiseesmärkidest, mitte salvestusmahust
Enne säilitusperioodide määramist määratlege kaks praktilist sihti: taastepunkti eesmärk ja taastamisaja eesmärk.
Teie taastepunkti eesmärk, mida sageli nimetatakse RPO-ks, vastab küsimusele, kui palju hiljutisi andmeid saate endale lubada kaotada. E-kaubanduse pood, mis töötleb tellimusi kogu päeva jooksul, võib vajada tunniseid andmebaasi varukoopiaid või tehinguteadlikke varukoopiaid. Brošüüriveebisait, mida uuendatakse kaks korda kuus, võib leppida igapäevase varukoopiaga, eeldusel et kriitilisi kontaktvormi andmeid hallatakse mujal.
Teie taastamisaja eesmärk ehk RTO vastab küsimusele, kui kiiresti tuleb sait taastada. Hiljutist varukoopiat, mida hoitakse kohapeal või lähedal asuvas varukoopiate salvestuskohas, saab tavaliselt taastada kiiremini kui külmarhiivi. Ainult kohalikest koopiatest siiski ei piisa. Serveri rike, lunavararünnak, ekslik kettaoperatsioon või konto taseme kompromiteerimine võib mõjutada korraga nii saiti kui ka selle kohalikke varukoopiaid.
Enamiku äriliste veebisaitide puhul määratlege need sihid lihtsas keeles. Näiteks: „Me ei saa kaotada rohkem kui ühe tunni tellimusi ja e-pood tuleb taastada kahe tunni jooksul.” See on palju kasulikum kui öelda „teeme varukoopiaid iga päev” ja avastada hiljem, et iga päev tähendab üks kord 24 tunni jooksul.
Kontrollige, mis tegelikult muutub
Veebisaidi failid ja andmebaasi andmed ei muutu sama kiirusega. WordPressi tuumfailid võivad kuude kaupa puutumata püsida, samal ajal kui andmebaas võtab kogu päeva vastu tellimusi, kommentaare, broneeringuid, liikmelisuse muudatusi ja vormikirjeid.
Täielik varukoopia peaks sisaldama rakenduse faile, andmebaase, konfiguratsioonifaile, üles laaditud meediat, asjakohasel juhul SSL-iga seotud konfiguratsiooni, ajastatud ülesannete definitsioone ning kõiki kohandatud rakenduse andmeid, mida hoitakse väljaspool veebijuurt. Kui andmebaasi varukoopia õnnestub, kuid üleslaadimiskataloog jäetakse välja, võib taastatud sait küll toimida, kuid tootekujutised või kliendidokumendid kaovad vaikselt.
Suurema rakenduse puhul dokumenteerige ka sõltuvused. Objektsalvestus, meiliteenused, maksesüsteemid, välised andmebaasid ja DNS-kirjed ei pruugi kuuluda serveri varukoopia sisse. Need kuuluvad siiski taastamisplaani.
Praktiline säilitusgraafik enamiku veebisaitide jaoks
Levinud lähtekoht on hoida sagedasi varukoopiaid lühikest aega ja harvemaid varukoopiaid kauem. See annab kasulikke taastamisvalikuid, ilma et salvestuskasutus kasvaks nagu mahajäetud garaaž.
Tüüpilise väikeettevõtte saidi, agentuuri hallatava saidi või turundussaidi puhul hoidke igapäevaseid varukoopiaid 14 kuni 30 päeva, iganädalasi varukoopiaid 8 kuni 12 nädalat ja igakuiseid varukoopiaid 6 kuni 12 kuud. Tehke lisavarukoopia enne suuremaid muudatusi, näiteks CMS-i uuendust, ümberkujunduse avaldamist, migratsiooni, pistikprogrammi väljavahetamist või serveri konfiguratsioonitöid.
Poodide, SaaS-i töölauavaadete, liikmesaitide, broneerimisplatvormide ja muude andmebaasimahukate teenuste puhul lisage sagedasem andmebaasi kaitse. Sobivad võivad olla tunnised andmebaasi varukoopiad, mida hoitakse alles 24 kuni 72 tundi, seejärel igapäevased varukoopiad 30 päeva, iganädalased varukoopiad 12 nädalat ja igakuised varukoopiad 12 kuud. Täpne intervall sõltub tehingute mahust ja sellest, kas rakendus suudab aktiivseid andmeid järjepidevalt varundada.
Agentuurid peaksid kaaluma kliendispetsiifilisi poliitikaid, selle asemel et rakendada ühte ajakava igale kontole. Restorani menüü sait ei vaja sama säilitamist kui kliendiportaal, mis käsitleb üles laaditud dokumente. Rühmitage saidid riski ja ärimõju järgi ning tehke poliitika kliendilepingus või teenuse ulatuses nähtavaks.
Hoidke muudatuseelseid taastepunkte eraldi
Automatiseeritud ajakavad ei asenda teadlikult tehtud varukoopiaid enne riskantset tööd. Looge märgistatud taastepunkt enne uuendusi, migratsioone, andmebaasi hooldust, mallimuudatusi või serveritaseme kohandusi.
Hoidke muudatuseelseid varukoopiaid alles vähemalt seitse kuni neliteist päeva pärast töö valmimist. Mõned probleemid ilmnevad alles pärast arveldustsüklit, taustatööd või integratsiooni käivitumist. Kui muudatus on kinnitatud stabiilsena, võib tavapärane säilitamine üle võtta.
Järgige 3-2-1 põhimõtet realistliku töökorraldusega
Klassikaline 3-2-1 mudel on endiselt praktiline: hoidke andmetest kolme koopiat, kahel erineval salvestustüübil, kusjuures üks koopia asub väljaspool asukohta. Veebisaidi käitamise puhul tähendab see sageli tootmisandmeid, varukoopiat majutuskeskkonnas ja krüpteeritud koopiat sõltumatus väljaspoolses salvestuses.
Võtmesõna on sõltumatu. Samas virtuaalserveris hoitav varukoopia on mugav, kuid see ei kaitse serveritaseme rikke eest. Samas majutuskontos hoitav varukoopia võib samuti olla ohustatud, kui ründaja saab konto mandaadid kätte või tehakse ulatuslik kustutustoiming.
Väljaspoolsed koopiad peaksid olema krüpteeritud nii edastamisel kui ka puhkeolekus. Juurdepääs peaks võimaluse korral kasutama eraldi mandaate, ideaaljuhul mitmefaktorilise autentimise ja piiratud õigustega. Varukoopiate kustutamise õigused väärivad erilist tähelepanu. Kui lunavara või kompromiteeritud administraator saab ühe seansiga kustutada tootmisandmed ja kõik taastepunktid, näeb säilitusgraafik paberil suurepärane välja, kuid on praktikas abitu.
kodu.cloudis võivad hallatud varundus- ja seirelahendused vähendada rutiinset tööd, kuid vastutus taastamisnõuete eest peab siiski olema selgelt määratletud. Teie teenusepakkuja võib süsteemi hallata; teie ettevõte peaks otsustama, kui suurt andmekadu ja seisakut ta saab aktsepteerida.
Muutke säilitamine turvaintsidentidest teadlikuks
Lühike säilitusaken võib olla ohtlik, kui pahavara avastatakse hilja. Sait võib olla kompromiteeritud mitu nädalat, enne kui kahtlased ümbersuunamised, rämpspostitegevus või volitamata administraatorikontod nähtavaks muutuvad. Kui iga varukoopia kirjutatakse seitsme päeva järel üle, võivad alles jääda ainult nakatunud koopiad.
Seepärast on iganädalased ja igakuised taastepunktid olulised. Kõrgema riskiga keskkondade puhul kaaluge määratud perioodiks muutumatuid või kirjutuskaitsega varukoopiaid. Muutumatus ei tee varukoopiat võluväel õigeks, kuid võib takistada ründajal seda pärast kompromiteerimist muutmast või kustutamast.
Pidage logisid varundamise õnnestumise, nurjumise, kustutamise ja taastamise tegevuse kohta. Hoiatused peaksid jõudma inimeseni, kes saab tegutseda, mitte postkasti, millest on saanud väike digitaalne muuseum. Seire peaks kontrollima ka salvestusmahtu, varunduse kestust ja ebatavalisi muutusi varukoopia suuruses. Äkitselt väga väike varukoopia võib viidata välja jäetud andmebaasile või nurjunud failikogumisele; äkitselt väga suur varukoopia võib viidata logidele, vahemälufailidele või soovimatutele andmetele, mis satuvad varukomplekti.
Testige taastamisi enne, kui neid vajate
Varukoopia on taastamisvahend alles pärast seda, kui see on edukalt taastatud. Varundustöö olek kinnitab, et andmed kopeeriti. See ei tõenda, et arhiiv on täielik, loetav, praeguse keskkonnaga ühilduv või ajasurve all kasutatav.
Testige taastamist vähemalt kord kvartalis tavapärase ärilise veebisaidi puhul ja sagedamini tulukriitiliste rakenduste puhul. Taastage see test- või isoleeritud keskkonda, kus see ei saa tootmist üle kirjutada. Kinnitage, et rakendus käivitub, andmebaas ühendub, meediafailid laadivad, vormid töötavad, ajastatud ülesanded on olemas ja kriitilised kasutajatoimingud käituvad tavapäraselt.
Märkige üles, kui kaua taastamine võttis ja milliseid käsitsi samme see nõudis. Kui taastamine sõltub sellest, et üks arendaja mäletab andmebaasi parooli, DNS-i järjestust ja viie aasta tagust shellikäsku, siis see ei ole plaan. See on folkloorne artefakt.
Dokumenteerige erandid ja vaadake poliitika üle
Teie säilitamispoliitika peaks mahtuma ühele lehele ja vastama mõnele otsesele küsimusele: mida varundatakse, kui sageli, kus koopiaid hoitakse, kui kaua iga koopiat säilitatakse, kes saab taastamist taotleda ja kuidas taastamise testimist dokumenteeritakse. Nimetage ka süsteemid, mida ei kaasata, et keegi ei eeldaks, et varukoopia katab kolmanda osapoole teenuse, millele see ligi ei pääse.
Vaadake poliitika üle pärast suurt saidimuudatust, uut vastavusnõuet, liikluse kasvu või taastamisintsidenti. Sagedasemad varukoopiad võivad muutuda vajalikuks, kui veebipood kasvab. Teisest küljest võib madala muutusmääraga saidi puhul mitme aasta igapäevaste varukoopiate hoidmine olla kulu ilma kasuliku kaitseta.
Seadistage säilitamispoliitika selle hetke järgi, mil seda kõige rohkem vajate: kiirustav reedesel päeval tehtud juurutus, pahatahtlik pistikprogrammi uuendus või valel tunnil tabanud kettaprobleem. Selged taastepunktid, sõltumatu koopia ja testitud protsess annavad teie meeskonnale midagi paremat kui enesekindlus. Need annavad teile toimiva järgmise sammu.
Andres Saar klienditoe insener