Jūsu eksperts datu dublēšanā un aizsardzībā!Jūsu vajadzībām pielāgots risinājums
DRP un BCP
Cik bieži testēt DRP?
Automātiski pārbaudiet, vai kopijas joprojām startē, vismaz reizi mēnesī, un vismaz reizi gadā veiciet reālu pārslēgšanu ar konkrētu darba darbību. Atkārtojiet testu, tiklīdz mainās serveris, tīkls, pakalpojumu sniedzējs vai persona, kurai ir atslēga.
Galvenais
- Katru dienu: pārskatīt dublēšanas kļūmes. Katru mēnesi: rezerves vides tehniskā startēšana.
- Katru ceturksni: atjaunošana ar laika mērīšanu. Katru gadu: reāla pārslēgšana ar atgriešanos.
- NIST paredz atjaunošanas spēju ikgadēju testu; VDAR un ANSSI (Francija) prasa regulārus testus.
- Katra būtiska izmaiņa (serveris, jauna galvenā versija, administrators, pakalpojumu sniedzējs, interneta pieslēgums) ir iemesls testam.
- Vissvarīgākais: pēdējā testa rakstiski fiksētais datums un novērstās novirzes.
Ko saka standarti un regulējums
- NIST. Vadlīnija SP 800-34, kas rakstīta ASV federālajām sistēmām, paredz katru gadu testēt atjaunošanas spējas un komandas, lai atklātu vājās vietas. Pats plāns jāatjaunina organizācijas noteiktā biežumā, piemēram, reizi gadā, un pēc katras būtiskas izmaiņas.
- VDAR. Tās 32. pants prasa līdzekļus, kas ļauj savlaicīgi atjaunot personas datu pieejamību, un procesu, lai regulāri testētu un izvērtētu drošības pasākumu efektivitāti.
- ANSSI (Francija). Francijas valsts kiberdrošības aģentūra uzskata, ka dublējumkopijas jātestē regulāri, un informācijas sistēmas atjaunošanas procedūrai jābūt uzrakstītai un regulāri izpildītai. Krīzes mācībām aģentūra iesaka domāt daudzgadu stratēģijas kategorijās, pakāpeniski palielinot mācību formātu sarežģītību.
Neviens no šiem dokumentiem neprasa «katru mēnesi reālos apstākļos». Visi tie norāda uz biežām pārbaudēm un pilnu testu vismaz reizi gadā.
Kāpēc ne «katru mēnesi reālos apstākļos»
Reāla pārslēgšana pārtrauc vai var pārtraukt ražošanas vidi. Veikt to katru mēnesi ir dārgi gan stundās, gan nogurumā, un komandas sāk to darīt pavirši. Labāk viens nopietns tests gadā nekā ikmēneša rituāls, kurā neviens neatver lietotni.
Tomēr gaidīt gadu, lai atklātu, ka dublējumkopija vairs nestartē, ir pārāk ilgi. Tāpēc tehniskā pārbaude ir bieža un viegla, bet biznesa tests – rets un pilnīgs.
Reāli izpildāms grafiks MVU
| Kad | Kas |
|---|---|
| Katru dienu | Pārskatīt dublēšanas kļūmes. DRP, kas balstās uz bojātu kopiju, ir bojāts DRP |
| Katru mēnesi | Rezerves vides tehniskā startēšana, neatslēdzot ražošanas vidi |
| Katru ceturksni | Faila vai datubāzes atjaunošana ar laika mērīšanu |
| Katru gadu | Reāla pārslēgšana vai līdzvērtīgs tests ar biznesa lietotāju un atgriešanos |
| Pēc katras izmaiņas | Jauns serveris, jauna galvenā versija, administratora aiziešana, pakalpojumu sniedzēja vai interneta pieslēguma maiņa |
Stingri regulētās nozarēs vai kritiski svarīgās sistēmās (veselības aprūpe, nepārtraukta ražošana) rindu «katru gadu» saīsina, dažkārt līdz pusgadam. Tas nav minimālais standarts pakalpojumu jomas MVU. Katra līmeņa sīkāks apraksts ir rakstā Kā testēt DRP?.
Kas ir svarīgāks par biežumu
Pēdējā testa rakstiski fiksētais datums un novērstās novirzes. DRP, kas testēts pirms vienpadsmit mēnešiem un kam ir protokols, ir labākā stāvoklī nekā DRP, kas tiek «testēts nepārtraukti», bet nekur nav fiksēts, kas tieši pārbaudīts. NIST prasa, lai katras mācības noslēgtos ar ziņojumu, kurā fiksēti novērojumi un uzlabojumu ieteikumi.
Ja pēdējais tests bija pirms vairāk nekā divpadsmit mēnešiem, pasakiet to vadībai tieši. Tā ir informācija, nevis kauns. Kļūda ir paziņot klientam vai apdrošinātājam, ka plāns ir darbspējīgs.
Pēc reāla incidenta
Reāla katastrofa ir tests, ja nedēļas laikā tiek sagatavots protokols: kas aizņēma vairāk laika nekā plānots, kā trūka, kas plānā tiek mainīts. Bez tā to pašu nāksies piedzīvot vēlreiz. Skatiet arī Serveris ir nokritis: ko darīt?.
WeDoBack pieeja
Startēšanas pārbaude notiek reizi mēnesī un ir iekļauta DRP, neskarot ražošanas vidi: tā aptver tabulas rindu «katru mēnesi» attiecībā uz attēlu, nevis uz biznesa darbību. Testu reālos apstākļos plāno līdz desmit stundām, pēc cenu piedāvājuma: tas ir dabisks kandidāts ikgadējai rindai. Nekas pakalpojumā neaizstāj jūsu cilvēcisko procedūru testēšanu (kas pieņem lēmumu, kur ir atslēga, kā informēt komandu). Šī daļa jāpārbauda līdz ar darbinieku aiziešanu un pieņemšanu, nevis programmatūras ritmā.
Biežāk uzdotie jautājumi
Vai pastāv likumā noteikts testēšanas biežums?
Vispārēja noteikuma visiem MVU nav. VDAR (32. pants) un ANSSI, Francijas kiberdrošības aģentūra, prasa testēt «regulāri», nenosakot konkrētu ritmu. NIST ASV federālajām sistēmām paredz ikgadēju testu. Dažas regulētas nozares, jūsu līgumi vai apdrošinātājs var prasīt biežāku ritmu.
Vai reāla katastrofa skaitās kā tests?
Jā, ja nedēļas laikā tiek sagatavots protokols: kas aizņēma vairāk laika nekā plānots, kā trūka, kas plānā jāmaina. Bez šī ieraksta incidents nepalīdz uzlabot plānu.
Ko teikt klientam vai apdrošinātājam, ja pēdējais tests bija pirms vairāk nekā gada?
Patiesību, norādot datumu. Paziņojot, ka plāns ir darbspējīgs bez neseniem testiem, jūs riskējat ar plaisu starp solījumu un realitāti katastrofas dienā. Labāk norādiet nākamā testa plānoto datumu.
Lasiet arī
Avoti
Dokumenti skatīti 2026. gada oktobrī.
- SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems — NIST
- Regula (ES) 2016/679 (VDAR), 32. pants — EUR-Lex
- Informācijas sistēmu datu dublēšana – pamatprincipi (ANSSI-BP-100, v1.1, 2025. gada 27. novembris) — ANSSI (Francijas aģentūra)
- Kiberkrīzes pārvaldības mācību organizēšana (franču valodā) — ANSSI (Francijas aģentūra)
- SP 800-84, Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities (2006. gada septembris) — NIST
- DRP piedāvājums: darbības atjaunošana pēc katastrofas — WeDoBack
Plānojat rezerves kopēšanas, DRP vai BCP projektu?
Vairāk nekā 20 gadu pieredze uzņēmumu datu aizsardzībā.
Pieprasīt piedāvājumu+33 9 72 50 78 28Aizsargājiet savus datus ar WeDoBack
Šifrēta ārpusvietas rezerves kopēšana, nemainīga krātuve, DRP un BCP: aprakstiet mums savus serverus, un mēs piedāvāsim piemērotāko risinājumu kombināciju.