Vietnēm paredzēta dublējumu glabāšanas politika, kas darbojas
Publicēts 2026. gada 14. augustā
Vietņu dublējumu glabāšanas politikai vajadzētu nodrošināt vairākus nesenus atjaunošanas punktus, dažas vecākas atkopšanas iespējas un vismaz vienu kopiju ārpus servera, kurā darbojas vietne. Ja spraudņa atjauninājums 10:15 no rīta sabojā norēķinu procesu, jums ir vajadzīga tīra versija no 10:00, nevis pagājušās otrdienas dublējums un cerīga sejas izteiksme.
Pareizais grafiks ir atkarīgs no tā, cik bieži mainās jūsu dati, cik izmaksā dīkstāve un cik ātri jūsu komanda var noteikt, kad problēma sākās. Statiska uzņēmuma vietne un aizņemts WooCommerce veikals nebūtu jāaizsargā vienādi. Pakalpojums var būt tiešsaistē, bet, ja trūkst vakardienas pasūtījumu, veidlapu iesniegumu vai klientu izmaiņu, viss vēl nav pilnībā mierīgi.
Kas jāaptver vietnes dublējumu glabāšanas politikai
Glabāšana nav vienkārši jūsu saglabāto dublējumu skaits. Tas ir noteikumu kopums, kas nosaka, kuras dublējuma kopijas paliek pieejamas, kur tās tiek glabātas, cik ilgi tās tur paliek un kad tās tiek dzēstas.
Noderīga politika ņem vērā trīs atsevišķas atkopšanas vajadzības. Pirmkārt, jums ir vajadzīga ātra operatīvā atkopšana nesenām kļūdām: neveiksmīgai izvietošanai, dzēstiem failiem, neizdevušamies atjauninājumam vai nejaušai konfigurācijas maiņai. Otrkārt, jums ir vajadzīga vēsturiskā atkopšana, kad problēma nedēļām ilgi ir klusi pastāvējusi, piemēram, kompromitēta administratora piekļuve vai inficēts kods. Treškārt, jums var būt vajadzīgi ieraksti, kas tiek glabāti uzņēmējdarbības, līgumisku vai regulatīvu iemeslu dēļ.
Šie mērķi var nonākt pretrunā. Visu dublējumu glabāšana mūžīgi rada glabātuves izmaksas, lēnākus dublēšanas darbus un mulsinošu atjaunošanas sarakstu. Pārāk maza apjoma glabāšana taupa vietu tieši līdz brīdim, kad vienīgais jums vajadzīgais dublējums jau ir beidzies. Saprātīgā atbilde ir daudzpakāpju glabāšana, nevis viena gara vienādu ikdienas dublējumu rinda.
Sāciet ar atkopšanas mērķiem, nevis glabātuves apjoma skaitli
Pirms glabāšanas periodu noteikšanas definējiet divus praktiskus mērķus: atkopšanas punkta mērķi un atkopšanas laika mērķi.
Jūsu atkopšanas punkta mērķis, ko bieži sauc par RPO, nosaka, cik daudz nesenu datu zaudējumu jūs varat atļauties. E-komercijas veikalam, kas visas dienas garumā apstrādā pasūtījumus, var būt nepieciešami ikstundas datubāzes dublējumi vai darījumiem pielāgoti dublējumi. Brošūras tipa vietne, kas tiek atjaunināta divreiz mēnesī, var pieņemt ikdienas dublējumu, ja kritiskie kontaktu veidlapu dati tiek apstrādāti citur.
Jūsu atkopšanas laika mērķis jeb RTO nosaka, cik ātri vietne ir jāatjauno. Nesen izveidotu dublējumu, kas glabāts lokāli vai tuvējā dublējumu glabātuvē, parasti var atjaunot ātrāk nekā aukstu arhīvu. Taču ar lokālajām kopijām vien nepietiek. Servera kļūme, izspiedējvīrusa incidents, kļūdaina diska darbība vai konta līmeņa kompromitēšana var vienlaikus ietekmēt vietni un tās lokālos dublējumus.
Lielākajai daļai uzņēmumu vietņu šos mērķus definējiet vienkāršā valodā. Piemēram: “Mēs nevaram zaudēt vairāk par vienu stundu pasūtījumu, un veikala skatam jābūt atjaunotam divu stundu laikā.” Tas ir daudz noderīgāk nekā teikt “mēs veicam dublējumus katru dienu” un vēlāk atklāt, ka “katru dienu” nozīmē reizi 24 stundās.
Pārbaudiet, kas patiesībā mainās
Vietnes faili un datubāzes dati nemainās vienādā tempā. WordPress pamatfaili var palikt neskarti mēnešiem ilgi, kamēr datubāze visas dienas garumā saņem pasūtījumus, komentārus, rezervācijas, dalības izmaiņas un veidlapu ierakstus.
Pilnam dublējumam jāietver lietotnes faili, datubāzes, konfigurācijas faili, augšupielādētie multivides faili, ar SSL saistītā konfigurācija, ja tā ir būtiska, plānoto uzdevumu definīcijas un jebkādi pielāgoti lietotnes dati, kas glabājas ārpus tīmekļa saknes. Ja datubāzes dublējums izdodas, bet augšupielāžu direktorija ir izslēgta, atjaunotā vietne var darboties, kamēr produktu attēli vai klientu dokumenti nemanāmi pazūd.
Lielākai lietotnei dokumentējiet arī atkarības. Objektu glabātuve, pasta pakalpojumi, maksājumu sistēmas, ārējās datubāzes un DNS ieraksti var neietilpt servera dublējumā. Tie joprojām ir daļa no atkopšanas plāna.
Praktisks glabāšanas grafiks lielākajai daļai vietņu
Bieži sastopams sākuma punkts ir biežus dublējumus glabāt īsu laiku, bet retākus dublējumus — ilgāk. Tas sniedz noderīgas atjaunošanas izvēles, neļaujot glabātuves izmantojumam augt kā pamestai garāžai.
Tipiskai maza uzņēmuma vietnei, aģentūras pārvaldītai vietnei vai mārketinga vietnei glabājiet ikdienas dublējumus 14 līdz 30 dienas, iknedēļas dublējumus 8 līdz 12 nedēļas un ikmēneša dublējumus 6 līdz 12 mēnešus. Veiciet papildu dublējumu pirms lielām izmaiņām, piemēram, CMS jaunināšanas, pārveides palaišanas, migrācijas, spraudņa nomaiņas vai servera konfigurācijas darbiem.
Veikaliem, SaaS paneļiem, dalības vietnēm, rezervēšanas platformām un citiem pakalpojumiem ar lielu datubāzes slodzi pievienojiet biežāku datubāzes aizsardzību. Var būt piemēroti ikstundas datubāzes dublējumi, kas tiek glabāti 24 līdz 72 stundas, pēc tam ikdienas dublējumi 30 dienas, iknedēļas dublējumi 12 nedēļas un ikmēneša dublējumi 12 mēnešus. Precīzs intervāls ir atkarīgs no darījumu apjoma un no tā, vai lietotne var konsekventi dublēt aktīvos datus.
Aģentūrām vajadzētu apsvērt klientiem specifiskas politikas, nevis piemērot vienu grafiku katram kontam. Restorāna ēdienkartes vietnei nav vajadzīga tāda pati glabāšana kā klientu portālam, kurā tiek apstrādāti augšupielādēti dokumenti. Grupējiet vietnes pēc riska un ietekmes uz uzņēmējdarbību, pēc tam padariet politiku redzamu klienta līgumā vai pakalpojuma tvērumā.
Glabājiet pirmsizmaiņu atjaunošanas punktus atsevišķi
Automatizēti grafiki neaizstāj apzināti veidotus dublējumus pirms riskantiem darbiem. Izveidojiet marķētu atjaunošanas punktu pirms atjauninājumiem, migrācijām, datubāzes uzturēšanas, veidņu izmaiņām vai servera līmeņa pielāgojumiem.
Glabājiet pirmsizmaiņu dublējumus vismaz septiņas līdz četrpadsmit dienas pēc darba pabeigšanas. Dažas problēmas parādās tikai pēc norēķinu cikla, fona darba vai integrācijas izpildes. Kad ir apstiprināts, ka izmaiņas ir stabilas, var pārņemt parastā glabāšana.
Ievērojiet 3-2-1 principu ar reālistisku darbību modeli
Klasiskais 3-2-1 modelis joprojām ir praktisks: glabājiet trīs datu kopijas divos dažādos glabāšanas veidos, no kurām viena kopija atrodas ārpus vietas. Vietņu darbībā tas bieži nozīmē produkcijas datus, dublējuma kopiju hostinga vidē un šifrētu kopiju neatkarīgā ārējā glabātuvē.
Atslēgas vārds ir “neatkarīga”. Dublējums, kas glabājas tajā pašā virtuālajā serverī, ir ērts, taču tas nav aizsardzība pret servera līmeņa kļūmi. Dublējums, kas glabājas tajā pašā hostinga kontā, arī var būt apdraudēts, ja uzbrucējs iegūst konta akreditācijas datus vai tiek veikta plaša dzēšanas darbība.
Ārpusvietas kopijām jābūt šifrētām pārsūtīšanas laikā un glabāšanas laikā. Piekļuvei, kur iespējams, jāizmanto atsevišķi akreditācijas dati, ideālā gadījumā ar daudzfaktoru autentifikāciju un ierobežotām atļaujām. Dublējumu dzēšanas atļaujas ir pelnījušas īpašu uzmanību. Ja izspiedējvīruss vai kompromitēts administrators vienas sesijas laikā var izdzēst produkcijas datus un katru atkopšanas punktu, glabāšanas grafiks uz papīra izskatīsies lieliski, bet praksē būs bezpalīdzīgs.
Uzņēmumā kodu.cloud pārvaldīti dublēšanas un uzraudzības risinājumi var samazināt ikdienas darbu, taču atbildībai par atkopšanas prasībām joprojām jābūt skaidri noteiktai. Jūsu pakalpojumu sniedzējs var uzturēt sistēmu; jūsu uzņēmumam jāizlemj, cik lielus datu zudumus un dīkstāvi tas var pieņemt.
Padariet glabāšanu informētu par drošības incidentiem
Īss glabāšanas periods var būt bīstams, ja ļaunprogrammatūra tiek atklāta vēlu. Vietne var būt kompromitēta vairākas nedēļas, pirms kļūst redzamas aizdomīgas pāradresācijas, surogātpasta aktivitāte vai neatļauti administratora konti. Ja katrs dublējums tiek pārrakstīts pēc septiņām dienām, jums var palikt tikai inficētas kopijas.
Tāpēc iknedēļas un ikmēneša atjaunošanas punkti ir svarīgi. Augstāka riska vidēm apsveriet nemainīgas vai pret rakstīšanu aizsargātas dublējuma kopijas uz noteiktu periodu. Nemainīgums nepadara dublējumu maģiski pareizu, bet tas var neļaut uzbrucējam to mainīt vai dzēst pēc kompromitēšanas.
Saglabājiet žurnālus par dublēšanas panākumiem, kļūmēm, dzēšanu un atjaunošanas darbībām. Brīdinājumiem jānonāk pie cilvēka, kurš var rīkoties, nevis iesūtnē, kas pārvērtusies par mazu digitālu muzeju. Uzraudzībai jāpārbauda arī glabātuves kapacitāte, dublēšanas ilgums un neparastas izmaiņas dublējuma apjomā. Pēkšņi ļoti mazs dublējums var norādīt uz izslēgtu datubāzi vai neveiksmīgu failu savākšanu; pēkšņi ļoti liels dublējums var norādīt uz žurnāliem, kešatmiņas failiem vai nevēlamiem datiem, kas nonāk dublējumu kopā.
Pārbaudiet atjaunošanu, pirms tā jums ir vajadzīga
Dublējums kļūst par atkopšanas rīku tikai pēc tam, kad tas ir veiksmīgi atjaunots. Dublēšanas darba statuss apstiprina, ka dati tika nokopēti. Tas nepierāda, ka arhīvs ir pilnīgs, nolasāms, saderīgs ar pašreizējo vidi vai izmantojams laika spiediena apstākļos.
Standarta uzņēmuma vietnei pārbaudiet atjaunošanu vismaz reizi ceturksnī, bet ieņēmumiem kritiskām lietotnēm — biežāk. Atjaunojiet to sagatavošanas vidē vai izolētā vietā, kur tas nevar pārrakstīt produkciju. Apstipriniet, ka lietotne palaižas, datubāze savienojas, multivides faili ielādējas, veidlapas darbojas, plānotie uzdevumi ir pieejami un kritiskās lietotāju darbības uzvedas normāli.
Pierakstiet, cik ilgi atjaunošana aizņēma un kādi manuāli soļi bija nepieciešami. Ja atkopšana ir atkarīga no tā, ka viens izstrādātājs atceras datubāzes paroli, DNS secību un piecus gadus vecu shell komandu, tas nav plāns. Tas ir folkloras artefakts.
Dokumentējiet izņēmumus un pārskatiet politiku
Jūsu glabāšanas politikai vajadzētu ietilpt vienā lapā un atbildēt uz dažiem tiešiem jautājumiem: kas tiek dublēts, cik bieži, kur tiek glabātas kopijas, cik ilgi katra kopija tiek glabāta, kurš var pieprasīt atjaunošanu un kā tiek dokumentēta atjaunošanas testēšana. Nosauciet arī sistēmas, kas nav iekļautas, lai neviens nepieņemtu, ka dublējums aptver trešās puses pakalpojumu, kuram tas nevar piekļūt.
Pārskatiet politiku pēc lielām vietnes izmaiņām, jaunas atbilstības prasības, datplūsmas pieauguma vai atkopšanas incidenta. Biežāki dublējumi var kļūt nepieciešami, tiešsaistes veikalam augot. Savukārt vairāku gadu ikdienas dublējumu glabāšana vietnei ar maz izmaiņām var radīt izmaksas bez noderīgas aizsardzības.
Veidojiet glabāšanas politiku, domājot par brīdi, kad tā būs visvairāk vajadzīga: steigā veiktu piektdienas izvietošanu, ļaunprātīgu spraudņa atjauninājumu vai diska problēmu nepiemērotā stundā. Skaidri atjaunošanas punkti, neatkarīga kopija un pārbaudīts process dod jūsu komandai kaut ko labāku par pārliecību. Tie dod jums praktiski izpildāmu nākamo soli.
Andres Saar Klientu apkalpošanas inženieris