Backup i rollback strategija za custom PHP web

Backup nije “kopija negdje na serveru”, a rollback nije “vrati stari file ako nešto pukne”. Kod custom PHP weba treba znati što se mijenja, što se može vratiti, što se ne smije pregaziti i kako provjeriti da restore stvarno radi. Bez toga je svaki deploy malo kockanje.

Glavna ideja: backup i rollback nisu isto. Backup čuva stanje koje možete vratiti. Rollback je postupak vraćanja aplikacije na stabilnu verziju. Dobra strategija ima oboje, plus provjeru da vraćanje zaista funkcionira.

1. Prvo definirajte što se na projektu može promijeniti

Nije svaki PHP web isti. Jednostavna prezentacijska stranica možda ima samo PHP datoteke, slike i CSS. Custom CMS ima bazu, uploadane slike, administraciju, korisnike, draftove, sitemap i možda logove. Web shop ima narudžbe, proizvode, plaćanja i mailove. Rollback plan ovisi o tome što se mijenja.

Dio projekta

Backup potreban

Rollback rizik

Aplikacijski kod

Git commit i kopija produkcijskih datoteka prije deploya.

Novi kod se može brzo vratiti ako nije mijenjao bazu.

Baza podataka

Dump prije promjene sheme ili sadržajnog deploya.

Rollback može izgubiti nove unose ako se radi neoprezno.

Uploadi i slike

Kopija media/upload mapa ili inkrementalni backup.

Novi uploadi nakon backupa ne smiju nestati.

Config

Produkcijski config treba čuvati odvojeno i pažljivo.

Najveći rizik je pregaziti produkcijske SMTP/baza podatke.

2. Git nije backup produkcije

Git je odličan za verzioniranje koda, ali nije potpuni backup produkcije. Ne sadrži produkcijski config, bazu podataka, uploadane slike, logove i datoteke koje korisnici ili CMS stvaraju nakon deploya. Git vam pomaže vratiti kod, ali ne cijeli web.

Zato prije deploya treba znati što je verzionirano, a što nije. Ako mijenjate samo statičan PHP članak i sliku, rollback je relativno jednostavan. Ako mijenjate CMS tablice ili importate podatke, priča je ozbiljnija.

Praktično pravilo: ako nešto nije u Gitu i može se promijeniti na produkciji, treba zaseban backup plan.

3. Minimalni backup prije deploya

Za mali custom PHP web minimalni backup prije deploya najčešće uključuje kopiju izmijenjenih produkcijskih datoteka, dump baze ako se dira sadržaj ili shema, te provjeru produkcijskog configa. Ne morate svaki put arhivirati cijeli server, ali morate moći vratiti ono što mijenjate.

Shell Primjer MySQL dumpa prije deploya

mkdir -p backups/2026-06-03

mysqldump \
  --single-transaction \
  --quick \
  --routines \
  --triggers \
  -u db_user \
  -p database_name \
  > backups/2026-06-03/database-before-deploy.sql

--single-transaction je koristan za InnoDB tablice jer smanjuje rizik od zaključavanja i daje konzistentniji dump. Kod većih sustava backup strategija mora biti ozbiljnija, ali za male poslovne webove ovo je dobar početni minimum.

4. Backup datoteka ne smije završiti u public_html

Jedna od opasnijih grešaka je ostaviti .zip, .sql ili .tar.gz backup u javnoj mapi. Ako netko pogodi URL ili ga crawler pronađe, backup može sadržavati izvorni kod, config, lozinke, emailove, SQL dump i druge osjetljive podatke.

Sigurna pravila za backup datoteke

Backup ne držite u javno dostupnoj mapi.
Backup datoteke ne ostavljajte s predvidljivim nazivima.
SQL dump ne smije sadržavati javno dostupne lozinke ili tokene.
Stare backup kopije brišite ili arhivirajte prema planu.
Za osjetljive projekte koristite enkripciju backupa.

5. Rollback koda treba biti brz i dosadan

Rollback aplikacijskog koda ne smije biti improvizacija. Ako znate koji je zadnji stabilan commit i koje su datoteke uploadane, povratak treba biti mehanički postupak. Najgori trenutak za smišljanje rollback plana je trenutak kada produkcija već ne radi.

Git Pronalaženje zadnje stabilne verzije

git log --oneline -5

# primjer:
# 1.0.73 novi članak ili deploy
# 1.0.72 taxonomy polish
# 1.0.71 prethodna stabilna verzija

Ako koristite ručni FTP deploy, rollback znači uploadati prethodne verzije datoteka koje su se mijenjale. Ako koristite release foldere, rollback može biti promjena symlinka na prethodni release. Na shared hostingu je često realnije imati discipliniran popis promijenjenih datoteka i lokalni Git kao izvor prethodne verzije.

6. Baza podataka je najosjetljiviji dio rollbacka

Kod baze treba biti oprezan jer vraćanje starog dumpa može obrisati nove upite, narudžbe, korisnike ili CMS izmjene nastale nakon deploya. Zato rollback baze nije uvijek “vrati dump”. Ponekad je bolje napraviti korektivnu migraciju koja popravi problem bez gubitka novih podataka.

Promjena

Mogući rollback

Napomena

Dodana kolona

Korektivna migracija ili ignoriranje kolone.

Brisanje kolone može obrisati nove podatke.

Promijenjen sadržaj

Ručno vraćanje samo zahvaćenih redaka.

Cijeli dump može biti pregrub potez.

Obrisani zapisi

Restore iz dumpa u privremenu bazu pa selektivni import.

Sigurnije od vraćanja cijele baze.

7. Restore test je važniji od samog backupa

Backup koji nikad niste probali vratiti je samo nada u obliku datoteke. Povremeno treba testirati možete li iz backupa dobiti radnu kopiju: datoteke, bazu, uploadane slike i konfiguraciju. Tek tada znate da backup nije oštećen, nepotpun ili spremljen na krivo mjesto.

Shell Restore dumpa u testnu bazu

mysql -u db_user -p test_database \
  < backups/2026-06-03/database-before-deploy.sql

Testni restore ne treba raditi na produkcijskoj bazi. Dovoljno je imati lokalnu ili staging bazu na kojoj možete provjeriti da se dump uopće može učitati.

8. Deploy checklist smanjuje ljudske greške

Većina deploy problema nisu spektakularni bugovi, nego sitnice: zaboravljen asset, pregazen config, cache nije osvježen, sitemap nije uploadan, assembly nije bumpan ili nova stranica nije provjerena. Checklist je dosadan alat, ali upravo zato radi.

Praktična checklist lista

Provjeriti lokalni status i diff prije commita.
Pokrenuti PHP lint za izmijenjene datoteke.
Provjeriti sitemap ako se dodaje ili mijenja javni URL.
Napraviti backup baze ako se dira sadržaj ili shema.
Ne uploadati cijeli produkcijski config, nego mijenjati samo nužnu vrijednost.
Bumpati assembly ili asset verziju nakon deploya.
Provjeriti nove i izmijenjene URL-ove na produkciji.

Ovaj dio se prirodno veže uz cache busting za CSS, JS i slike, jer asset verzije i deploy checklist često spašavaju od “meni lokalno radi” problema.

9. Rollback nije zamjena za staging

Rollback je zaštita kada problem prođe do produkcije. Ali cilj je da većina problema nikad ne dođe do produkcije. Za manje projekte staging može biti lokalni mirror ili skrivena testna kopija. Za veće projekte staging treba biti što sličniji produkciji: ista PHP verzija, sličan config, slična baza i isti deploy proces.

Dobra praksa: staging ne mora biti savršen, ali mora uhvatiti najčešće rizike: syntax greške, krive putanje, nedostajuće assete, loš config, problem s bazom i neispravan routing.

10. Što dokumentirati nakon svakog deploya

Ako vodite custom web dugoročno, korisno je imati malu deploy bilješku. Ne mora biti velika dokumentacija. Dovoljno je znati što je mijenjano, koji je commit, koji je assembly, je li sitemap ažuriran, koje stranice su provjerene i postoji li nešto za GSC.

Deploy note Kratki zapis nakon objave

Deploy: 2026-06-03
Commit: abc1234
Assembly: 1.0.74
Changed URLs:
- /blog/backup-rollback-strategija-custom-php-web
Uploaded:
- pages-blog/backup-rollback-strategija-custom-php-web.php
- pages/blog.php
- sitemap.xml
Production checks:
- article 200
- blog 200
- sitemap 200
GSC:
- submit sitemap
- request indexing for new URL

Zaključak: dobar rollback plan uklanja paniku iz deploya

Backup i rollback strategija ne treba biti komplicirana, ali mora biti stvarna. Trebate znati što čuvate, gdje se nalazi, kako se vraća i što može poći po zlu. Kod custom PHP webova to je posebno važno jer često nema gotovog platformskog mehanizma koji sve radi umjesto vas.

Najbolji deploy je onaj koji je dovoljno dosadan da ga možete ponoviti bez stresa. Backup prije rizičnih promjena, jasan popis datoteka, kontroliran config, provjeren sitemap, assembly bump i produkcijski testovi čine razliku između sigurnog održavanja i vatrogasnog posla. Za širu sliku strukture projekta pogledajte i kako organizirati PHP projekt bez frameworka.

Održavanje web stranica Cache busting vodič