Процена решења за резервне копије из пословне перспективе

U ponedeljak ujutru finansije ne mogu da pristupe sistemu za fakturisanje. Webshop i dalje prima narudžbine, ali skladište ne vidi koliko je zaliha dostupno. Prvo pitanje je obično da li postoji bekap. Pravo pitanje je, međutim, koliko vremena je potrebno da se na osnovu procene rešenja za bekap podataka vrati rad, koji podaci su izgubljeni i ko to može pouzdano da potvrdi.

Mnoge kompanije imaju neki oblik bekapa: automatske verzije u okviru cloud servisa, eksterni uređaj povezan na server ili zadatak bekapa kojim upravlja IT stručnjak. To još uvek ne znači da se kritična poslovna situacija može rešiti. Postojanje bekapa i dokazano funkcionalna obnova su dve različite stvari.

Procena rešenja za bekap podataka počinje procesom

Vrednost sistema za bekap ne određuje kapacitet skladišta ili ime provajdera. Prvo treba razjasniti koji poslovni procesi staju bez podataka ili sistema. U proizvodnoj kompaniji to može biti plan proizvodnje, podaci o mašinama ili evidencija sirovina. U trgovačkoj kompaniji to su procesi naručivanja, zaliha i fakturisanja. Kod pružaoca usluga to su podaci o klijentima, ugovori i dokumentacija o radu.

Vredi razmišljati u lancima operacija, a ne u aplikacijama. Ako se baza podataka webshopa može vratiti, ali integracija za prenos narudžbina, ERP ili veza sa prevoznikom ne može, ispunjenje narudžbina i dalje može zahtevati ručno usklađivanje. U takvim slučajevima tehnička obnova znači samo delimičnu poslovnu obnovu.

Tokom prve procene treba pratiti kako informacije dolaze od narudžbine do isporuke, od proizvodnog zahteva do proizvodnje, ili od ispunjenja do fakturisanja. Gde se podaci generišu, između kojih sistema se kreću i koja tačka ispadanja parališe svakodnevni rad? Ovo često otkriva zavisnosti koje ostaju skrivene u normalnom radu.

Nisu svi podaci isti poslovni rizik

Pristup "sve bekapovati podjednako često" može biti skup, a ipak ne pruža odgovarajuću zaštitu. Gubitak višegodišnjeg arhiva je ozbiljan problem, ali možda neće zaustaviti dnevni rad. Nasuprot tome, gubitak nekoliko sati podataka o narudžbinama, proizvodnji ili zalihama može izazvati direktan gubitak prihoda, pogrešno ispunjenje i pritužbe klijenata.

Dva pitanja pomažu da se donese jasna odluka. Prvo: koliko gubitka svežih podataka je prihvatljivo? Ovo se često tumači kao cilj tačke obnove. Ako se podaci o narudžbinama bekapuju samo jednom dnevno, popodnevni kvar može značiti ručno rekonstruisanje celog radnog dana. Ako je kretanje podataka kontinuirano, noćni bekap možda više nije proporcionalan riziku.

Drugo pitanje: koliko dugo proces može biti van funkcije? Isključenje sistema za obračun plata može biti prihvatljivo u određenim periodima, ali u drugim može ugroziti rokove i zakonske obaveze. Ako je sistem skladišta van funkcije nekoliko sati, tim može nastaviti rad na papiru, ali ako je tačnost zaliha već nesigurna, to brzo može proizvesti dodatne greške.

Cilj nije smanjenje rizika na nulu. To bi u skoro svim slučajevima značilo nesrazmerne troškove i prekomernu složenost. Cilj je ravnoteža prihvaćena na nivou menadžmenta između posledica ispadanja, očekivanja obnove i operativnih troškova.

Bekap je bekap samo ako se može vratiti

Jedan od najčešćih nedostataka je da stižu e-mailovi o uspešnom izvršavanju zadataka bekapa, ali niko nije testirao obnovu u uslovima sličnim stvarnim. Zeleni status potvrđuje da su neki podaci prebačeni negde. Ne potvrđuje automatski da su podaci netaknuti, potpuni, dostupni sa odgovarajućim dozvolama i da se potrebni sistem zaista može pokrenuti iz njih.

Ovo je posebno složeno kod baza podataka, virtuelnih servera, fajl servera i integrisanih poslovnih sistema. Može se desiti da baza podataka postoji, ali nedostaju konfiguracija aplikacije, licence, sertifikati ili podešavanja integracije. Isto važi i za sisteme koji rade u cloudu: visoka dostupnost usluge ne štiti nužno kompaniju od pogrešnog brisanja, problema sa dozvolama ili zlonamernog šifrovanja.

Test obnove ne mora biti potpuna simulacija katastrofe svake nedelje. Ali treba redovno proveravati koliko brzo i sa kakvim rezultatom se može vratiti određeni fajl, baza podataka ili sistem. Za kritične procese potrebna je dokumentovana, vremenski merenja proba. Ovo daje stvarnu osnovu za procenu rizika na nivou menadžmenta.

Ko i kojim redosledom vrši obnovu?

Tokom incidenta, pored tehnologije, odlučujući je i redosled odgovornosti. Ako samo jedan administrator zna iz kog bekapa, kojim redosledom treba vratiti ERP, fajl server i integracije, kompanija se zapravo oslanja na znanje jedne osobe. To je rizik za kontinuitet poslovanja, a ne samo HR pitanje.

Dobar redosled obnove jasno određuje ko odlučuje o pokretanju procesa, ko upravlja tehničkim koracima, ko proverava poslovne podatke i kako se obaveštavaju relevantni menadžeri i klijenti. Nije potrebno previše regulisati svaki scenario, ali u kritičnim prvim satima nije potrebna improvizacija.

Zaštita od grešaka i napada

Strategija bekapa nije pripremljena samo za slučaj hardverskog kvara. Među češćim problemima su slučajno brisanje, pogrešan uvoz podataka, loše izvršena sinhronizacija ili izmena izvršena sa preširokim dozvolama. U tim slučajevima sistem često radi, samo je stanje podataka pogoršano. Tada su posebno vredni bekapi koji se čuvaju dovoljno dugo i omogućavaju izbor iz više vremenskih tačaka.

Ransomware napadi postavljaju dodatne zahteve. Ako napad šifruje proizvodne podatke, a napadač sa istim dozvolama pristupi i bekapima, mogućnost obnove može biti ugrožena. Zato je opravdano izdvajanje bekapa, ograničavanje pristupa i primena metoda čuvanja koje onemogućavaju jednostavno prepisivanje ili brisanje već stvorenog bekapa tokom određenog perioda.

Često spominjano pravilo 3-2-1 - više kopija, različita okruženja za skladištenje, barem jedna izdvojena kopija - korisna je polazna tačka. Međutim, samo po sebi nije plan. Ne govori šta treba bekapovati, koliko često, koliko dugo, sa kojim prioritetom i kako potvrditi mogućnost obnove.

Cloud, lokalna infrastruktura ili hibridni model?

Ne postoji model koji je jednako prikladan za sve kompanije. Prednost cloud bekapa može biti geografska izolacija, fleksibilni kapacitet i jednostavnije upravljanje. Međutim, kod velike količine podataka ili sporije internet veze, vreme za potpunu obnovu može postati kritično ograničenje. Obnova više terabajta fajl servera nije isto što i obnova nekoliko dokumenata.

Lokalna kopija može omogućiti bržu obnovu, ali ne štiti adekvatno od požara, krađe, nestanka struje ili napada koji se širi istom mrežom, ako nije izdvojena. Hibridni model je često praktičan: lokalni kapacitet za često potrebnu, brzu obnovu, a fizički izdvojena kopija za ozbiljnije događaje.

Pri donošenju odluke važni su propusnost, količina podataka, tehnička struktura aplikacija, regulatorni zahtevi i unutrašnja sposobnost upravljanja. Dobro zvučeća usluga ne rešava problem ako kompanija ne zna koje sisteme štiti i ko proverava rezultat.

Šta menadžeri treba redovno da vide?

Opšta izjava da je "sve u redu" nije dovoljna za stanje bekapa podataka. Menadžment treba da dobije kratku, jasnu sliku o tome koji kritični sistemi su obuhvaćeni bekapom, kada je poslednji put uspešno izvršena provera obnove, da li postoje neuspešni zadaci bekapa i u kojim oblastima nije ispunjeno vreme obnove koje je obećano.

Ovo nije svakodnevno mikromenadžment. To je pitanje upravljanja, kao što su tačnost zaliha, proizvodni otpad ili stanje potraživanja. Ako je rizik poznat, može se doneti odluka da li je prihvatljiv, treba li ga smanjiti ili prvo treba rešiti osnovnu zavisnost procesa i sistema.

Dobro procenjen bekap podataka nije samo IT zadatak koji se odvija u pozadini. To je dokaz da kompanija može nastaviti rad na kontrolisan način čak i nakon greške, napada ili ljudske greške. Vredi postaviti pitanja pre nego što skladište, finansije ili korisnička podrška već čekaju povratak sistema.