Sigurnosna kopija web stranice trebala bi postojati u više verzija i na više mjesta, ne kao jedan zastarjeli arhiv spremljen na istom serveru koji pogoni samu stranicu. Za webshop s dnevnim narudžbama to znači kopiranje baze podataka svaki dan ili češće, dok statična prezentacijska stranica koja se rijetko mijenja može funkcionirati i s tjednim ritmom. Razlika ne ovisi o veličini tvrtke, nego o tome koliko podataka nastane između dva backupa i koliko bi taj gubitak stajao ako poslužitelj ili sama stranica otkažu bez upozorenja. Konkretno, tjedni backup dovoljan je za statičnu stranicu, dok webshop s dnevnim narudžbama treba barem dnevnu kopiju baze i jasan plan vraćanja podataka kad nešto pođe po zlu.
Zašto backup hostinga nije dovoljan za poslovnu web stranicu
Većina paketa hostinga danas uključuje neki oblik automatskog backupa, no ta usluga rijetko pokriva sve što poslovna web stranica stvarno treba. Retencija je često ograničena na nekoliko dana unatrag, kopija se sprema na istoj infrastrukturi na kojoj radi stranica, a vraćanje podataka obično znači vraćanje cijelog računa, ne samo jedne oštećene tablice ili datoteke. Ako poslužitelj ima kvar, ako dođe do napada koji zahvati cijeli hosting račun ili se pretplata na hosting neplaćanjem prekine, ista se ranjivost prenosi i na kopiju koja je trebala biti spas. Zato je nezavisna sigurnosna kopija web stranice - ona koja ne ovisi o infrastrukturi pružatelja hostinga - osnova svakog ozbiljnog plana kontinuiteta. Za WordPress stranice to u praksi znači dodatnu razinu preko dodatka kao što je UpdraftPlus, koji kopiju šalje na vanjsku lokaciju poput Google Drivea, Dropboxa ili Amazon S3. Postavljanje takvog sustava obično spada u uslugu web razvoja, ne u jednokratnu postavku koja se zaboravi nakon prvog mjeseca. Kontrolna lista sigurnosti web-stranice koja pokriva SSL certifikat, ažuriranja i lozinke dobro je mjesto za provjeru gdje backup uklapa u širu sliku zaštite - pogledajte checklist sigurnosti web stranice.
Koliko često raditi backup ovisno o vrsti stranice
Statična stranica naspram webshopa: različit ritam backupa
Prezentacijska ili blog stranica
Sadržaj se mijenja rijetko do nekoliko puta tjedno. Tjedni backup uz dodatnu kopiju prije veće izmjene dizajna ili sadržaja obično je dovoljan. Gubitak jednog dana rada znači ponovno pisanje teksta ili postavljanje slika, ne izgubljenu prodaju.
Webshop s aktivnim narudžbama
Baza podataka s narudžbama, zalihama i korisničkim računima mijenja se svaki sat rada trgovine. Dnevni backup baze podataka je donja granica, a trgovine s većim brojem transakcija razmatraju satne ili gotovo trenutne kopije. Gubitak dana znači izgubljene narudžbe i podatke o plaćanju.
Ako stranica kombinira blog i webshop, ritam backupa baze podataka treba pratiti najosjetljiviji dio - obično onaj s transakcijama, ne onaj s najviše teksta.
Učestalost backupa ovisi o tome koliko se sadržaja mijenja, ne o tipu djelatnosti tvrtke. Statična prezentacijska stranica s osnovnim podacima o tvrtki i uslugama može imati tjedni ritam kopiranja, uz dodatnu kopiju prije svake veće izmjene dizajna ili sadržaja. Blog ili stranica s novostima koja se ažurira nekoliko puta tjedno traži češći ritam, obično dnevni, jer se svaki izgubljeni dan pretvara u izgubljen članak ili objavu koju treba ponovno pisati. Webshop je poseban slučaj: baza podataka s narudžbama, stanjem zaliha i korisničkim računima mijenja se svaki sat rada trgovine, pa dnevni backup baze, uz kopiju datoteka nakon svake promjene teme ili dodatka u WooCommerceu ili Shopifyu, predstavlja donju granicu, ne preporučeni maksimum. Trgovine s većim brojem transakcija razmatraju i češće intervale, satne ili gotovo trenutne, jer gubitak jednog dana narudžbi znači izravan financijski trošak, ne samo neugodnost.
Pravilo 3-2-1: gdje čuvati kopije podataka
Pravilo 3-2-1 dolazi iz svijeta korporativnog IT-a, ali vrijedi jednako za jednu poslovnu web stranicu: tri kopije podataka, na dva različita medija ili sustava, s jednom kopijom izmještenom izvan lokacije na kojoj stranica radi. U praksi to znači jednu kopiju na samom hosting poslužitelju za brzo vraćanje manjih grešaka, jednu na vanjskom cloud servisu odvojenom od hostinga te po mogućnosti treću, lokalnu kopiju preuzetu na računalo ili vanjski disk, posebno ako stranica obrađuje osjetljive podatke o korisnicima. Kad backup web stranice sadrži osobne podatke kupaca - adrese, narudžbe, poruke iz kontakt obrasca - lokacija pohrane više nije samo tehničko pitanje. Takvi podaci potpadaju pod Zakon o provedbi Opće uredbe o zaštiti podataka, a Agencija za zaštitu osobnih podataka (AZOP) nadzire kako se osobni podaci obrađuju i čuvaju, uključujući sigurnosne kopije, ne samo produkcijsku bazu. Popis provjera iz GDPR checklista za web-stranice pokriva i pitanje pohrane podataka izvan primarnog poslužitelja.
Disaster recovery web-stranice: koraci nakon gubitka podataka
Redoslijed koraka nakon gubitka podataka
Koraci slijede kronološki, od trenutka otkrivanja problema do potvrde da stranica opet radi ispravno.
- Utvrditi opseg incidenta
Odmah nakon uočavanja problema provjerite je li pogođena cijela stranica, samo baza podataka ili samo dio datoteka. Ovaj korak obično radi vlasnik stranice ili osoba zadužena za IT, u prvih petnaest do trideset minuta.
- Zaustaviti širenje štete
Ako je uzrok hakiranje ili neispravno ažuriranje, stranicu je potrebno privremeno staviti u način održavanja ili je isključiti dok se ne utvrdi uzrok, da se spriječi dodatno oštećenje podataka ili korisnika koji nastavljaju slati narudžbe na neispravan sustav.
- Identificirati zadnju čistu kopiju
Provjerite datume dostupnih sigurnosnih kopija i odaberite posljednju verziju koja prethodi incidentu, ne nužno posljednju kreiranu kopiju - ako je backup nastao poslije infekcije, sadrži isti problem.
- Vratiti kopiju na testno okruženje
Prije vraćanja na produkciju, backup se vraća na zasebnu adresu ili stage okruženje kako bi se provjerilo je li baza podataka cjelovita i radi li stranica bez grešaka.
- Vratiti provjerenu kopiju na produkciju
Kad je testno okruženje potvrdilo da je kopija ispravna, ista se verzija postavlja na produkcijski poslužitelj, uz obavijest korisnicima ako je stranica bila nedostupna dulje vrijeme.
- Provjeriti ključne funkcije
Nakon vraćanja provjeravaju se narudžbe, kontakt obrasci, prijava korisnika i sustav plaćanja - ne samo je li stranica vizualno ista kao prije.
- Analizirati uzrok i spriječiti ponavljanje
Zadnji korak nije tehnički nego organizacijski: utvrditi zašto je do incidenta došlo i je li potrebno promijeniti lozinke, ažurirati sustav ili promijeniti ritam backupa za budućnost.
Vrijeme potrebno za cijeli postupak ovisi o veličini stranice i vrsti incidenta, ali tvrtka koja unaprijed zna ove korake gubi sate, ne dane.
Disaster recovery web-stranice ne događa se u trenutku kad se netko sjeti da backup postoji, nego prati unaprijed dogovoreni redoslijed koraka koji zna provesti osoba zadužena za stranicu, bez improvizacije usred krize. Kad stranica prestane raditi, kad je hakirana ili kad je greška u ažuriranju srušila bazu podataka, prvi minuti odlučuju je li šteta ograničena ili se širi dalje. Koraci u nastavku pretpostavljaju da nezavisna kopija izvan hostinga već postoji - ako ne postoji, prvi je korak nabaviti je, ne slijediti redoslijed oporavka koji na njoj počiva.
Kako provjeriti da backup stvarno radi
Backup koji se nikad nije vratio na testno okruženje jest pretpostavka, ne dokazana zaštita. Kopija koja se stvara automatski mjesecima, a nikad nije vraćena ni na jedno okruženje, može biti nepotpuna, oštećena ili jednostavno neupotrebljiva u trenutku kad zatreba - a to se obično otkrije tek tijekom stvarnog incidenta, kad je najgore vrijeme za takvo otkriće. Provjera znači vraćanje kopije na testno ili stage okruženje, provjeru je li baza podataka cjelovita, jesu li sve slike i datoteke prisutne i radi li stranica identično kao prije. Razuman ritam provjere je nakon svake veće promjene backup sustava - novog dodatka, promjene hostinga, migracije - i periodično, na primjer jednom u tromjesečju, bez obzira izgleda li da sve radi. Kod webshopova provjera mora uključivati i podatke o narudžbama nastalim između posljednjeg backupa i trenutka incidenta - te se transakcije neće naći u vraćenoj kopiji i moraju se ručno rekonstruirati iz e-mail potvrda, izvoda platnog sustava ili evidencije u WooCommerceu odnosno Shopifyu. Za WordPress instalacije test vraćanja najlakše je provesti na staging okruženju koje mnogi hosting paketi nude kao zasebnu opciju, ili lokalno pomoću alata poput Local by Flywheel, prije nego se ista kopija ikad postavi na produkciju. Ako stranica koristi dodatke koji spremaju postavke izvan standardne WordPress baze - primjerice određeni page builderi ili sustavi za članstvo - provjeru treba proširiti i na te tablice, jer se lako dogodi da izgledaju vraćene, a zapravo referenciraju obrisane zapise. Održavanje web stranice, uključujući provjeru backupa, obično je dio šireg paketa održavanja koji tvrtke ugovaraju uz hosting i ažuriranja; pregled tih troškova u vodiču o cijeni održavanja web stranice pokazuje gdje se ta stavka najčešće nalazi u ponudi.
