Backup custom CMS-a treba posmatrati kao deo njegovog dizajna, a ne kao podešavanje koje se dodaje kada projekat već bude u produkciji. Ako se sačuva samo baza, možda nedostaju uploadovani fajlovi, konfiguracija, verzije aplikacije ili ključevi potrebni za čitanje šifrovanih podataka. Ako se sačuva sve, ali nikada nije provereno vraćanje sistema, organizacija i dalje ne zna koliko brzo i pouzdano može da se oporavi.
Praktičan cilj je definisati šta se vraća, sa koliko starim podacima i u kom roku. Za to služe RPO (Recovery Point Objective) i RTO (Recovery Time Objective). RPO opisuje prihvatljiv gubitak podataka izražen kroz vreme, dok RTO opisuje ciljno vreme potrebno da se servis vrati u upotrebljivo stanje. Ove vrednosti nisu iste za svaki custom CMS: sajt sa retkim uredničkim izmenama nema isti rizik kao portal sa čestim unosima, porudžbinama ili integracijama.
Šta disaster recovery treba da obuhvati
Disaster recovery je širi od backup-a. Backup je sačuvana kopija podataka ili komponenti sistema. Recovery je plan i niz koraka kojima se te kopije koriste za obnovu rada posle greške, napada, kvara infrastrukture ili pogrešne izmene.
Za custom CMS plan obično treba da obuhvati najmanje sledeće komponente:
- Bazu podataka: sadržaj, korisnike, uloge, podešavanja, revizije i podatke koje generišu integracije.
- Uploadovane fajlove: slike, dokumente, video, eksportovane fajlove i druge medije koji nisu nužno smešteni u bazi.
- Izvorni kod i verzije: aplikaciju, module, migracije i zavisnosti potrebne za pokretanje konkretne verzije.
- Konfiguraciju okruženja: podešavanja domena, web servera, queue procesa, cron zadataka, storage-a i konekcija.
- Tajne i sertifikate: API ključeve, podatke za konekciju, enkripcijske ključeve i sertifikate, uz odvojenu i kontrolisanu zaštitu.
- DNS i spoljne servise: informacije potrebne za preusmeravanje saobraćaja i ponovno povezivanje sa servisima za slanje mejla, pretragu, plaćanje ili analitiku.
Ne mora svaki element imati isti režim čuvanja. Izvorni kod se često već nalazi u kontrolisanom repozitorijumu, dok baza i media storage zahtevaju redovne kopije. Ipak, recovery dokument treba da pokaže gde se svaka komponenta nalazi i kako se obnavlja.
Kako odrediti RPO i RTO za custom CMS
RPO: koliko podataka sme da nedostaje?
Ako je RPO 24 sata, plan mora omogućiti oporavak do tačke koja nije starija od jednog dana. To ne znači nužno da se backup pravi jednom dnevno; učestalost treba uskladiti sa količinom promena i posledicama gubitka. Kod uredničkog sajta može biti važno sačuvati nove članke i izmene, dok kod sistema sa čestim transakcijama i integracijama prihvatljivi gubitak može biti mnogo manji.
RPO se određuje razgovorom sa vlasnicima sadržaja i procesa, ne samo tehničkom procenom. Pitanja koja pomažu su: koje izmene bi bilo teško ručno ponoviti, da li postoji paralelni izvor podataka i da li gubitak nekoliko sati rada proizvodi pravni, finansijski ili reputacioni problem?
RTO: koliko dugo servis može da bude nedostupan?
RTO uključuje više od samog kopiranja baze. U vreme oporavka mogu ući detekcija incidenta, odluka da se aktivira plan, priprema infrastrukture, vraćanje podataka, provera integriteta, podešavanje DNS-a i testiranje ključnih funkcija.
Za informativni sajt možda je prihvatljiv ručni postupak na rezervnom okruženju. Za CMS koji podržava poslovno kritične procese može biti potrebna spremna infrastruktura, automatizovane migracije i jasno definisane odgovornosti. Važno je da RTO bude realan u odnosu na budžet, složenost sistema i dostupnost ljudi koji mogu da sprovedu oporavak.
Backup strategija: šta čuvati i gde
Dobra strategija razdvaja nekoliko rizika: kvar primarnog servera, slučajno brisanje, neispravnu deploy izmenu, kompromitovane naloge i problem sa samim backup sistemom. Zbog toga jedna kopija na istom serveru nije dovoljna zaštita. Ako napadač dobije pristup produkciji, može pokušati da obriše i lokalne kopije; ako disk otkaže, nestaju i aplikacija i backup.
U praksi se često koristi princip više kopija na različitim medijima i lokacijama, uz najmanje jednu kopiju koja nije stalno dostupna za upis iz produkcionog sistema. Tačan raspored zavisi od infrastrukture, ali treba proveriti sledeće:
- da li se kopije čuvaju izvan primarnog servera ili regiona;
- da li su backup nalozi odvojeni od svakodnevnih administratorskih naloga;
- da li postoji zaštita od naknadne izmene ili brisanja kopija;
- koliko dugo se čuvaju dnevne, nedeljne i mesečne tačke;
- da li se o neuspešnom backup-u šalje upozorenje odgovornoj osobi.
Retencija treba da prati način rada. Kratka retencija može zaštititi od kvara, ali ne i od problema koji se primeti tek posle nekoliko nedelja. Duža retencija povećava trošak storage-a i zahteve za upravljanje, pa je korisno definisati poslovne i pravne potrebe umesto čuvanja svega bez plana.
Vrste backup-a i njihovi kompromisi
Logički i fizički backup baze
Logički backup izvozi podatke i strukturu baze u obliku koji se može uvesti u drugu instancu. Može biti koristan za migraciju, selektivni oporavak i proveru sadržaja, ali vraćanje velikih baza može trajati duže. Fizički backup kopira datoteke baze ili koristi mehanizam koji je bliži njenom internom formatu; često je pogodniji za brži oporavak cele instance, ali zahteva veću pažnju prema kompatibilnosti verzija i stanju baze.
Izbor ne treba donositi samo prema tome šta hosting nudi kao dugme. Potrebno je znati da li backup predstavlja konzistentnu tačku, kako se obnavlja na čistom okruženju i da li može da se vrati bez ručnih intervencija koje nisu dokumentovane.
Fajlovi, storage i baze moraju biti usklađeni
CMS može upisati zapis u bazu pre nego što je fajl dostupan na storage-u, ili obrnuto. Ako se baza i media fajlovi vraćaju iz različitih vremenskih tačaka, mogu nastati neispravne putanje, nedostajući dokumenti i sadržaj koji urednik vidi, ali posetilac ne može da otvori. Zbog toga je važno definisati redosled kopiranja i, kada je potrebno, koristiti snapshot ili mehanizam koji obezbeđuje konzistentnu tačku.
Konfiguracija i tajne
Backup konfiguracije ne znači da se tajne smeju čuvati kao običan tekst u istom folderu. API ključevi, lozinke i enkripcijski ključevi zahtevaju ograničen pristup, enkripciju i proceduru za rotaciju. Istovremeno, recovery plan mora objasniti kako se tajne bezbedno dobavljaju kada se podiže novo okruženje. Ako je ključ potreban za dešifrovanje podataka izgubljen, sama kopija šifrovanog backup-a možda neće biti upotrebljiva.
Zaštita od najčešćih scenarija gubitka
| Scenario | Šta plan treba da reši |
|---|---|
| Slučajno brisanje sadržaja | Vraćanje pojedinačnog zapisa, fajla ili ranije verzije bez nepotrebnog vraćanja celog sistema. |
| Neuspešna izmena ili migracija | Pre-deploy backup, mogućnost vraćanja i jasna odluka kada se radi rollback, a kada popravka migracije. |
| Kvar servera ili storage-a | Obnova na drugoj infrastrukturi, DNS procedura i provera integracija. |
| Kompromitovan nalog ili ransomware | Odvojene privilegije, zaštićene kopije, rotacija tajni i provera da se u novo okruženje ne vraća kompromitovana komponenta. |
| Nedostupan eksterni servis | Dokumentovan način rada bez servisa, zamena endpoint-a ili kontrolisano odlaganje procesa. |
Audit log može pomoći da se utvrdi šta je menjano pre incidenta i da se razdvoji greška korisnika od sistemskog problema. Za detaljniji pregled te teme pogledajte audit log u CMS-u. Backup, međutim, nije zamena za audit log: backup vraća stanje, dok log pomaže da se incident razume i da se odredi koju tačku treba vratiti.
Testiranje restore-a je obavezni deo plana
Uspešno kreiran fajl nije dokaz da je recovery moguć. Restore test treba sprovesti u izolovanom ili privremenom okruženju, bez ugrožavanja produkcije. Minimalni test može obuhvatiti podizanje aplikacije, vraćanje baze, povezivanje media storage-a, prijavu urednika, otvaranje nekoliko tipova stranica i proveru ključnih integracija.
Za svaki test zabeležite:
- koju backup tačku ste koristili i koliko je stara;
- koliko je trajalo vraćanje svake komponente;
- koje korake je bilo potrebno ručno izvršiti;
- da li su sadržaj, fajlovi, dozvole i linkovi ispravni;
- koji problemi su pronađeni i ko je odgovoran za njihovo rešavanje.
Test ne mora biti komplikovan da bi bio koristan, ali mora biti ponovljiv. Posle većih promena u strukturi baze, storage-u, hostingu ili autentikaciji treba proveriti da li stari recovery postupak i dalje važi. Plan koji postoji samo u glavi jedne osobe predstavlja operativni rizik.
Kako backup uklopiti u razvoj i governance
Backup politika treba da bude povezana sa procesom objave. Pre rizične migracije ili promene modula može se napraviti dodatna tačka oporavka, uz proveru da je kopija dostupna. Posle objave treba proveriti osnovne funkcije, a ne pretpostaviti da će se greška uočiti kroz backup sistem.
Odgovornosti takođe moraju biti jasne: ko prati upozorenja, ko odobrava vraćanje produkcije, ko komunicira sa hosting provajderom i ko proverava sadržaj nakon oporavka. Ova podela je deo CMS governance pristupa, posebno kada marketing upravlja sadržajem, a development održava kod i infrastrukturu.
Backup može uticati i na performanse. Velike baze, obrada medija i snapshot operacije mogu opteretiti disk ili mrežu, pa se termin i način izrade kopija planiraju u odnosu na saobraćaj i produkcione procese. Tema je povezana sa pitanjima rasta obrađenim u tekstu Caching i performance u custom CMS-u.
Checklist za specifikaciju recovery plana
- Popisati sve komponente bez kojih CMS ne može da radi.
- Definisati RPO i RTO za različite klase sadržaja ili funkcija.
- Odrediti učestalost, retenciju i lokacije backup-a.
- Odvojiti privilegije za produkciju, backup storage i recovery okruženje.
- Dokumentovati vraćanje baze, fajlova, konfiguracije, tajni i DNS-a.
- Definisati proveru integriteta i minimalni set funkcionalnih testova.
- Planirati restore test i beležiti rezultat, vreme i probleme.
- Ažurirati dokumentaciju posle promena infrastrukture ili aplikacije.
Ove odluke je najbolje doneti dok se custom CMS projektuje, jer arhitektura određuje koliko su komponente povezane i koliko je oporavak automatizovan. Ako procenjujete novi ili postojeći sistem, pogledajte pristup custom CMS rešenjima i uključite backup i disaster recovery u tehnički scope, a ne kao naknadni dodatak. Za širi kontekst planiranja celog digitalnog projekta može biti koristan i vodič za izradu sajta.
Sledeći korak nije kupovina još jednog storage servisa. Napravite mapu komponenti, napišite realan RPO/RTO i izvedite jedan kontrolisani restore test. Rezultat će pokazati da li je postojeći backup zaista plan oporavka ili samo arhiva kojoj se nada da nikada neće biti potrebna.
