Kako redovno testirati korporativne bekape?

Jednog ponedeljka ujutru poslovni sistem ne radi. Zbog greške na serveru, neispravnog ažuriranja ili ransomware-a, podaci o porudžbinama, zalihama i fakturisanju postaju nedostupni. Postoji rezervna kopija - kaže neko iz IT-a. To je umirujuće, ali samo po sebi ne odgovara na pitanje kada će rad moći da se nastavi. Pravo pitanje je kako redovno testirati korporativne rezervne kopije tako da u slučaju stvarne greške poslovanje zaista može biti obnovljeno.

U mnogim organizacijama, rezervna kopija je tehnički zadatak koji se odvija u pozadini. Sistem je svakodnevno pravi, provajder skladišta potvrđuje, a zelena kvačica se pojavljuje na nadzornoj tabli. U međuvremenu, niko ne proverava da li se podaci mogu otvoriti, da li se podudaraju i da li se iz njih može obnoviti upotrebljiv poslovni sistem. To je ista razlika kao kada postoji opis procesa, ali tim ga nikada nije probao u stvarnim uslovima.

Rezervna kopija ne postaje vredna pravljenjem datoteka. Ona je vredna kada se može dokazati da se iz nje može obnoviti rad.

Testiranje rezervne kopije je zapravo proba poslovanja

Tehnički uspeh i poslovni uspeh nisu uvek isto. Možda se baza podataka može obnoviti, ali webshop nije povezan sa trenutnim zalihama. Možda sadržaj servera sa datotekama postoji, ali nedostaju dozvole, pa zaposleni ne mogu pristupiti potrebnim folderima. Takođe se može desiti da baza podataka ERP-a i priloženi dokumenti potiču iz različitih vremena, pa sistem formalno počinje, ali status otvorenih porudžbina ostaje neizvestan.

Zato cilj testa ne treba formulisati kao „da li je uspelo vraćanje rezervne kopije”. Cilj je pre ovo: da li određeni poslovni proces može ponovo funkcionisati u prihvatljivom vremenskom roku, uz prihvatljiv gubitak podataka.

U trgovačkoj kompaniji to može značiti da ulazna webshop porudžbina ulazi u poslovni sistem, skladište vidi zadatak za komisioniranje, i faktura se može generisati. Kod proizvođača to znači da su dostupni trenutni proizvodni nalozi, struktura proizvoda i proizvodni podaci. Kod uslužne kompanije to znači da ugovori, podaci o klijentima i tekući poslovi ostaju dostupni.

Prvo treba razjasniti šta je kritično

Nisu svi sistemi jednako hitni. Česta greška je što se plan rezervne kopije pravi prema tehnološkim elementima: serverima, bazama podataka, virtuelnim mašinama, folderima. To je neophodna polazna tačka, ali nije dovoljna za donošenje odluka na rukovodećem nivou.

Vredi krenuti od poslovnih procesa. Šta se dešava ako se ne može primiti porudžbina? Koliko dugo može trajati zastoj u skladišnom izdavanju? Koje su posledice ako finansijski sistem nije dostupan ceo radni dan? U kom sistemu se nalaze podaci koji se ne mogu ponovo ručno kreirati?

Iz ovoga proizilaze dve ključne vrednosti. Jedna je ciljano vreme oporavka: koliko brzo proces mora ponovo da funkcioniše. Druga je prihvatljiv gubitak podataka: koliko podataka sme da nedostaje. Ako kompanija kontinuirano prima porudžbine, rezervna kopija od prethodne noći može biti tehnički u redu, ali poslovno predstavlja preveliki gubitak.

Ove odluke ne mogu se prepustiti isključivo IT-u. Operativni tim zna šta se može obnoviti i koliko brzo. Prodaja, finansije, logistika ili proizvodnja mogu reći koji gubitak je prihvatljiv. Dobar plan rezervne kopije i oporavka nastaje iz susreta ova dva gledišta.

Kako redovno testirati korporativne rezervne kopije?

Redovnost ne znači da se svakog meseca mora izvoditi isto potpuno vraćanje. Odgovarajuća učestalost zavisi od kritičnosti sistema, broja promena i poslovnih posledica zastoja.

Dobra praksa se sastoji iz nekoliko nivoa. Dnevna automatizovana provera ispituje da li su zadaci rezervne kopije izvršeni, da li su datoteke rezervne kopije kreirane i da li postoje greške ili neuobičajene promene veličine. Ovo je brza indikacija, ali ne i dokaz oporavka.

Sledeći nivo je redovna proba vraćanja. Tada se u izolovanom test okruženju obnavlja izabrani sistem ili baza podataka, a zatim se proverava njegova upotrebljivost. Nije dovoljno da server počne sa radom. Potrebno je prijaviti se, otvoriti relevantne podatke i proveriti nekoliko poslovno važnih zapisa: poslednju porudžbinu, fakturu, kretanje zaliha, proizvodni nalog ili dokument.

Treći nivo je potpunija proba poslovanja. Ovo se obično izvodi jednom godišnje, a u kritičnim okruženjima čak i češće. Ovde cilj nije obnova jednog komponenta, već proba stvarnog poslovnog lanca. Rezultati najčešće pokazuju da nedostaje neka integracija, sertifikat, dozvola, mrežno pravilo ili zavisnost od spoljnog provajdera za stvarno funkcionisanje.

Test treba izvesti u izolovanom okruženju

Vraćanje rezervne kopije na aktivni sistem je rizično. Može prepisati sveže podatke, prekinuti veze ili izazvati sporedne efekte koji ugrožavaju normalno funkcionisanje. Osnovni princip testiranja je stoga izolacija.

Obnovljeno okruženje ne mora uvek biti iste veličine kao infrastruktura, ali kritične zavisnosti moraju biti verodostojno predstavljene. Ako aplikacija zavisi od baze podataka, skladišta datoteka, direktorijumske usluge i spoljnog API-ja, test to mora uzeti u obzir. U suprotnom, samo dokazujemo da datoteka rezervne kopije postoji, a ne da se usluga može obnoviti.

Posebnu pažnju zaslužuju integrisani sistemi. Webshop, ERP, skladišni sistem i kurirska veza mogu se pojedinačno sačuvati, ali obnova stanja između njih je složenije pitanje. Ako je porudžbina u jednom sistemu već obrađena, a u drugom još uvek nije, nakon vraćanja može doći do duple isporuke, greške u zalihama ili nejasne fakturacije.

Neka bude dokaz, a ne samo sećanje

„Jednom smo to probali prošle godine” nije kontrola. Za svaki test potreban je kratak, pretraživi zapisnik: iz koje rezervne kopije je izvršeno vraćanje, kada je napravljena rezervna kopija, koliko je trajalo vraćanje, koje su provere izvršene, šta nije radilo iz prve i ko je odobrio rezultat.

Ovo nije administrativno opterećenje radi opterećenja. Nakon nekog vremena, trendovi postaju vidljivi. Da li se vreme vraćanja povećava? Da li se pojavila nova zavisnost nakon ažuriranja sistema? Dokumentovane razlike mogu se pretvoriti u zadatke za razvoj, odrediti odgovorne osobe i postaviti rokove.

Testovi moraju imati vlasnika. IT ili eksterni operater može biti odgovoran za tehničko izvršenje, ali poslovno odobrenje mora dati oblast koja koristi proces. Na primer, skladišni menadžer mnogo brže prepoznaje da su obnovljeni podaci o zalihama neupotrebljivi nego neko ko samo vidi da je veza sa bazom podataka uspešna.

Najčešće greške u praksi rezervnih kopija

Jedan od tipičnih problema je što se rezervne kopije prave u istom okruženju koje koristi originalni sistem. Ransomware, greška u dozvolama ili greška u infrastrukturi takođe mogu uticati na rezervne kopije. Rezervna kopija mora biti fizički i logički odvojena i zaštićena od neovlašćenih izmena ili brisanja.

Često se misli samo na centralni server. Izostavljaju se dokumenti u oblaku, izvozi SaaS sistema, konfiguracije, podešavanja mrežnih uređaja, integracioni ključevi ili datoteke koje pripadaju prilagođenim aplikacijama. Za obnovu sistema često nije potrebna samo baza podataka, već svi elementi koji okružuju rad sistema.

Treća greška je ignorisanje promena. Novi modul webshopa, nova lokacija, promenjen model dozvola ili reorganizovan skladišni proces mogu učiniti da stari test rezervne kopije više ne daje pravi odgovor. Plan rezervne kopije treba povezati sa upravljanjem promenama kao i svaki drugi kritični poslovni proces.

Dobro testirana rezervna kopija nije spektakularan rezultat. Ne ubrzava direktno fakturisanje i ne smanjuje administraciju preko noći. Međutim, kada zbog greške svi postavljaju isto pitanje - „kada možemo ponovo raditi?” - dokazana sposobnost oporavka nije tehnički detalj, već rukovodeći prostor za manevar.