Poslovni podaci najčešće ne nestaju u jednom dramatičnom događaju. Problem često počinje brisanjem mape, neuspjelom nadogradnjom poslužitelja, kvarom diskovnog sustava ili kompromitiranim korisničkim računom. Kada se to dogodi, backup softver mora omogućiti više od pukog postojanja kopije podataka: mora omogućiti brz, provjerljiv i siguran povratak u rad.
Za direktora je ključno pitanje koliko dugo poslovanje može funkcionirati bez pojedinog sustava. Za IT administratora je pitanje može li se vratiti konkretna datoteka, cijeli virtualni poslužitelj ili poslovna aplikacija u točno određenom stanju. Dobar sustav sigurnosnog kopiranja mora odgovoriti na oba pitanja prije incidenta, a ne tijekom njega.
Što backup softver mora zaštititi
Backup nije samo kopija datoteka s mrežnog diska. U poslovnom okruženju podaci su raspoređeni na više mjesta: na fizičkim i virtualnim poslužiteljima, radnim stanicama, mrežnim spremištima, bazama podataka te u Microsoft 365 okruženju. Svaki od tih izvora ima drugačiji način rada i drugačije zahtjeve za oporavak.
Primjerice, kopiranje virtualnog poslužitelja nije isto što i kopiranje nekoliko dokumenata. Ako je na tom poslužitelju poslovna aplikacija, potrebno je osigurati da se nakon oporavka mogu pokrenuti operativni sustav, aplikacija i pripadajuća baza podataka. Kod baze podataka važan je i trenutak do kojeg se podaci mogu vratiti, osobito ako se transakcije unose tijekom cijelog radnog dana.
Microsoft 365 također zahtijeva zasebnu procjenu. Dostupnost platforme ne znači automatski da organizacija ima vlastitu, dovoljno dugu i upravljivu kopiju svih poruka, datoteka, timova i korisničkih podataka. Pravila zadržavanja, brisanje korisnika i potrebe internog oporavka treba definirati prema načinu rada tvrtke.
Inventar sustava dolazi prije odabira rješenja
Prije nabave ili promjene rješenja treba popisati sustave koji stvarno utječu na rad: računovodstvene aplikacije, dokumentaciju, zajedničke mape, baze podataka, virtualne strojeve, konfiguracije mrežne opreme i podatke u cloud servisima. Popis treba sadržavati vlasnika sustava, lokaciju podataka, količinu podataka te prihvatljivo vrijeme prekida rada.
Ovaj korak često otkrije da postoje sustavi bez jasnog vlasnika ili podaci koji se nalaze samo na jednoj radnoj stanici. Takve situacije stvaraju veći rizik od samog izbora softvera.
RPO i RTO određuju konfiguraciju backupa
Dva pojma treba jasno definirati s upravom i odgovornim korisnicima. RPO, odnosno ciljna točka oporavka, određuje koliko podataka organizacija smije izgubiti. Ako se backup radi jednom dnevno, moguće je izgubiti promjene nastale od posljednje kopije do trenutka incidenta.
RTO, odnosno ciljano vrijeme oporavka, govori koliko je vremena prihvatljivo da sustav bude nedostupan. Tvrtka može imati kopiju poslužitelja, ali ako je za povratak potrebno dva dana, a poslovanje ne može čekati dulje od nekoliko sati, konfiguracija nije odgovarajuća.
Za arhivu dokumenata može biti prihvatljiv dnevni backup i oporavak sljedeći radni dan. Za sustav narudžbi, proizvodnje ili financija zahtjevi su često stroži. Zato nije racionalno sve podatke tretirati jednako niti svima dodijeliti isti raspored kopiranja.
Brzina vraćanja važna je koliko i brzina kopiranja
Pojedina rješenja dobro obavljaju sigurnosno kopiranje, ali su spora pri vraćanju većih sustava. To se posebno vidi kada je primarna kopija na udaljenoj lokaciji, a internetska veza ograničena. U takvoj situaciji oporavak cijelog poslužitelja iz clouda može trajati znatno dulje nego što se očekuje.
Zato se u poslovnoj praksi često kombinira lokalna kopija za brži oporavak i izdvojena kopija za zaštitu od fizičkog incidenta na primarnoj lokaciji. Točan odnos ovisi o količini podataka, propusnosti veze, infrastrukturi i dogovorenom RTO-u.
Pravilo 3-2-1-1-0 kao operativni standard
Jednostavno pravilo 3-2-1-1-0 pomaže provjeriti postoji li stvarna otpornost sustava. Podrazumijeva najmanje tri kopije podataka, pohranjene na dva različita medija, uz jednu kopiju izvan primarne lokacije. Dodatna jedinica označava jednu nepromjenjivu ili odvojenu kopiju, a nula znači nula grešaka pri redovitoj provjeri oporavka.
Nije nužno da svaka tvrtka koristi istu tehnologiju, ali načelo razdvajanja kopija ostaje jednako. Ako su produkcijski podaci i backup na istom poslužitelju ili pod istim administratorskim računom, jedan kvar ili kompromitacija mogu zahvatiti oboje.
Nepromjenjiva kopija ima posebnu vrijednost kada treba spriječiti izmjenu ili brisanje backupa tijekom unaprijed definiranog razdoblja. Takvu zaštitu treba pravilno konfigurirati. Sama oznaka “immutable” nije dovoljna ako osobe koje upravljaju produkcijskim sustavom imaju i široke ovlasti nad spremištem sigurnosnih kopija.
Sigurnost backupa nije dodatna opcija
Backup infrastruktura sadrži najvrjedniju kopiju poslovnih podataka pa mora imati vlastite sigurnosne kontrole. Administratorski računi za backup trebaju biti odvojeni od uobičajenih korisničkih računa, uz višefaktorsku autentifikaciju gdje je dostupna. Pristup konzoli, spremištu i konfiguracijama treba dodjeljivati prema stvarnoj potrebi, a ne prema praktičnosti.
Potrebno je zaštititi i komunikaciju prema udaljenim lokacijama te šifrirati kopije u prijenosu i mirovanju kada to zahtijeva arhitektura i klasifikacija podataka. Jednako je važno čuvati ključeve za šifriranje i dokumentirati tko im može pristupiti. Backup koji se ne može dešifrirati nije upotrebljiv backup.
Zadržavanje kopija također treba imati poslovnu logiku. Prekratko zadržavanje može onemogućiti povratak na stanje prije neprimijećenog problema. Predugo zadržavanje povećava troškove pohrane i administrativne obveze. Uobičajeno je kombinirati češće kratkoročne kopije s rjeđim mjesečnim ili godišnjim kopijama, ali raspored mora pratiti stvarne potrebe organizacije.
Test oporavka je jedini dokaz da sustav radi
Uspješno izvršen backup zadatak ne dokazuje da se podaci mogu vratiti u rad. Zapis “success” može značiti samo da je proces kopiranja završio bez prijavljene greške. Ne govori nužno jesu li aplikacija, baza podataka i ovlasti korisnika nakon oporavka funkcionalni.
Testiranje treba planirati prema važnosti sustava. Za neke podatke dovoljno je periodično vratiti uzorak datoteka. Za kritične virtualne poslužitelje treba provesti kontrolirani oporavak u izdvojenom okruženju i provjeriti pokretanje operativnog sustava, aplikacije i ključnih poslovnih funkcija.
Dobar zapis testa navodi datum, oporavljeni sustav, korištenu točku oporavka, trajanje postupka, uočene probleme i osobu koja je potvrdila rezultat. Takva dokumentacija kasnije omogućuje realnije planiranje prekida rada i olakšava odlučivanje o potrebnim ulaganjima.
Nadzor sprječava da greška ostane neprimijećena
Backup softver treba redovito nadzirati. Neuspjeli zadaci, upozorenja o kapacitetu spremišta, preskočeni uređaji i predugo trajanje kopiranja zahtijevaju reakciju. U malim i srednjim tvrtkama čest je problem što obavijesti stižu na zajednički sandučić koji nitko ne pregledava sustavno.
Odgovornost mora biti jasna: tko pregledava izvještaje, tko otklanja grešku, u kojem roku i tko odlučuje kada je potreban veći zahvat. Automatizirani izvještaji pomažu, ali ne zamjenjuju odgovornu osobu koja razumije kontekst infrastrukture.
Posebnu pozornost treba posvetiti rastu podataka. Sustav koji je bio pravilno dimenzioniran prije dvije godine može danas imati nedovoljno spremišta, predug backup prozor ili prespor oporavak. Redoviti pregled kapaciteta i politika zadržavanja sprječava da se problem otkrije tek kada ponestane prostora.
Kako odabrati backup softver za poslovno okruženje
Odabir ne bi trebao početi pitanjem koji je proizvod najpoznatiji, nego koje sustave treba zaštititi i koliko brzo ih treba vratiti. Rješenje mora podržavati postojeću infrastrukturu, uključujući virtualizaciju, poslužitelje, baze podataka, radne stanice i cloud servise koje organizacija koristi.
Treba provjeriti može li se vratiti pojedinačna datoteka, cijeli uređaj, aplikacijski objekt ili kompletan virtualni stroj. Važni su i automatizacija, izvještavanje, upravljanje pravima pristupa, mogućnost pohrane na odvojenoj lokaciji te način licenciranja koji odgovara rastu tvrtke.
Najjeftiniji pristup često postaje skup kada oporavak traje predugo ili kada je potrebna vanjska intervencija bez dokumentacije. S druge strane, pretjerano složeno rješenje nema smisla ako ga nitko ne održava i ne testira. Pravilno rješenje je ono koje organizacija može pouzdano nadzirati, održavati i koristiti pod pritiskom.
CarPen Rebuild pri procjeni backup sustava polazi od poslovnih procesa, postojeće infrastrukture i realnog vremena oporavka koje tvrtka može prihvatiti. Tek nakon toga ima smisla definirati tehnologiju, lokaciju kopija, politike zadržavanja i način nadzora.
Prije sljedeće promjene infrastrukture ili obnove licenci vrijedi napraviti barem jedan kontrolirani test oporavka najvažnijeg sustava. Rezultat tog testa često daje jasniji odgovor o stvarnoj spremnosti poslovanja od bilo kojeg izvještaja o uspješno izvršenim backup zadacima.