# Strategija sigurnosnih kopija za poslužitelje: kopije prema pravilu 3-2-1

> Strategija sigurnosnih kopija za poslužitelje prema pravilu 3-2-1: što morate sigurnosno kopirati, kako kopije prežive napad i zašto testirati vraćanje.

Izvor: https://phpsos.de/hr/ratgeber/backups-3-2-1/  
Stanje: 25.10.2026  
Pružatelj: PHP SOS, PHP hitna pomoć i sigurnost poslužitelja. Hitna pomoć putem WhatsAppa: https://wa.me/491736494914?text=Pozdrav%20PHP%20SOS%2C%20trebamo%20pomo%C4%87%20s%20na%C5%A1im%20PHP%20poslu%C5%BEiteljem.%20Tvrtka%3A%20%E2%80%A6%20Web-stranica%3A%20%E2%80%A6

**Ukratko:** Pouzdana strategija sigurnosnih kopija za poslužitelje slijedi pravilo 3-2-1: tri kopije, dvije vrste pohrane, jedna kopija izvan lokacije. Da bi kopije preživjele i napad, barem jedna kopija treba zaštitu od brisanja s samog poslužitelja. A tek uspješan test vraćanja pokazuje da sigurnosna kopija u kritičnom slučaju funkcionira.

## Što znači pravilo 3-2-1

Pravilo 3-2-1 jednostavno je, godinama provjereno načelo sigurnosnog kopiranja podataka:

- **3 kopije:** izvorni podaci i dvije sigurnosne kopije.
- **2 vrste pohrane:** primjerice lokalni disk i objektna pohrana, ili pohrana poslužitelja i traka.
- **1 kopija izvan lokacije:** na drugoj lokaciji, kod drugog pružatelja ili offline.

Za web-poslužitelje to konkretno znači: sigurnosna kopija na istom disku kao web-stranica ne računa se kao samostalna kopija. Ako poslužitelj ispadne ili bude kompromitiran, obje su izgubljene. Za upravu je ključno pitanje stoga ne „Imamo li sigurnosne kopije?“, nego „Možemo li poslovanje vratiti iz kopije do koje incident nije dosegnuo?“

## Strategija sigurnosnih kopija za poslužitelje koja preživljava napad

Napadači znaju da sigurnosne kopije poništavaju njihov rad. Tko ima pristup poslužitelju, stoga često traži i sigurnosne kopije kako bi ih obrisao ili šifrirao. Moderna strategija zato pravilo 3-2-1 često proširuje na **3-2-1-1-0**: jedna dodatna kopija offline ili nepromjenjiva, i nula pogrešaka pri testu vraćanja.

Tri osnovna načela čine sigurnosne kopije otpornima:

- **Pull umjesto push:** Zaseban sustav za sigurnosno kopiranje preuzima podatke s web-poslužitelja. Sam web-poslužitelj nema pristupne podatke kojima bi mogao brisati kopije.
- **Nepromjenjivost:** Objektna pohrana sa zaključavanjem čuvanja ili snapshotovi koji se određeno vrijeme ne mogu obrisati.
- **Odvojeni pristupi:** Račun za sigurnosne kopije nije isti kao korisnički račun za hosting i ima vlastiti drugi faktor.

> **Važno:**
> Šifrirajte sigurnosne kopije koje su izvan lokacije i ključ čuvajte odvojeno. Izgubljen ključ čini kopiju neupotrebljivom, a zajedno pohranjen ključ čini šifriranje bezvrijednim.

## Što treba sigurnosno kopirati

Kod web-poslužitelja često se kopira samo webroot. Za potpuno vraćanje tada nedostaju važni dijelovi.

| Područje | Primjeri | Napomena |
|---|---|---|
| Datoteke aplikacije | webroot, uploadi, teme, ekstenzije | Uploadi se često mijenjaju |
| Baze podataka | MySQL/MariaDB, PostgreSQL | kopirati konzistentno, ne samo kopirati datoteke |
| Konfiguracija | web-poslužitelj, PHP-FPM poolovi, php.ini, cron zadaci | potrebno za brzu ponovnu izgradnju |
| Certifikati i ključevi | TLS certifikati, ključevi aplikacije | pohraniti šifrirano i odvojeno |
| Dokumentacija | pristupi, ovisnosti, tijek vraćanja | bez nje svaka ponovna izgradnja traje dulje |

## Primjer: sigurnosno kopiranje baze podataka i datoteka

Sljedeći primjer prikazuje osnovne gradivne elemente dnevne sigurnosne kopije. U praksi prijenos izvan lokacije preuzima alat za sigurnosno kopiranje sa šifriranjem, deduplikacijom i pravilima čuvanja.

```bash
#!/bin/bash
set -euo pipefail
DATUM=$(date +%F)
ZIEL=/srv/backup/$DATUM
mkdir -p "$ZIEL"
chmod 700 "$ZIEL"

# Bazu podataka kopirati konzistentno; pristupni podaci iz zaštićene datoteke, ne u naredbi
mysqldump --defaults-extra-file=/root/.backup-my.cnf \
  --single-transaction --routines --triggers shopdb | gzip > "$ZIEL/shopdb.sql.gz"

# Datoteke aplikacije i konfiguracija
tar -czf "$ZIEL/webroot.tar.gz" -C /var/www shop
tar -czf "$ZIEL/config.tar.gz" /etc/nginx /etc/php /etc/cron.d

# Kontrolni zbrojevi za kasniju provjeru
sha256sum "$ZIEL"/* > "$ZIEL/SHA256SUMS"
```

Datoteka `.backup-my.cnf` sadrži pristupne podatke korisnika baze podataka koji smije samo čitati i ima prava `0600`. `--single-transaction` kod InnoDB tablica osigurava konzistentno stanje bez zaustavljanja shopa.

Zatim zaseban sustav prenosi sigurnosnu kopiju izvan lokacije. Važno je da se taj korak nadzire: zadatak sigurnosnog kopiranja koji danima tiho ne uspijeva inače se primijeti tek u kritičnom slučaju. Dnevna poruka o uspjehu, veličini i trajanju dovoljna je, sve dok je netko čita i prati odstupanja.

Ako dodatno koristite sigurnosne kopije ili snapshotove svog pružatelja hostinga, pisano razjasnite koliko se dugo čuvaju, možete li sami vraćati i ostaju li kopije sačuvane kod otkazanog ili blokiranog računa. Te su kopije dobra dopuna, ali ne zamjenjuju vlastitu, neovisnu sigurnosnu kopiju.

## Čuvanje: zašto su stariji presjeci važni nakon PHP2Shella

Nakon napada najvrjednija nije najnovija sigurnosna kopija, nego najnovija čista. Kod PHP2Shella je prema medijskim izvješćima 17.10.2026. opažen prvi pokušaj napada, a zakrpe su se pojavile 21.10.2026. Tko čuva samo sedam dana, možda više nema stanje koje sigurno leži prije moguće provale.

Provjeren obrazac kombinira više razdoblja, primjerice dnevne kopije nekoliko tjedana, tjedne nekoliko mjeseci i mjesečne godinu dana. Točna razdoblja ovise o Vašoj potrebi za zaštitom i obvezama brisanja iz zaštite podataka.

Važno je i ovo: sigurnosna kopija iz vremena nakon provale može sadržavati webshellove ili izmijenjene datoteke. Nakon incidenta nikad ne vraćajte naslijepo, nego usporedite datoteke s čistim stanjem i provjerite ih prije nego web-stranica ponovno ode online. Napomene na što paziti nalaze se na stranici [Znakovi kompromitacije](https://phpsos.de/hr/php2shell/bin-ich-gehackt-anzeichen/). Zakrpa ne uklanja ubačeni zlonamjerni softver, a ni sigurnosna kopija to ne čini sama od sebe.

## Testiranje i dokumentiranje vraćanja

Sigurnosna kopija bez testa je pretpostavka. Tek vraćanje pokazuje jesu li svi dijelovi prisutni, radi li ključ i koliko postupak zaista traje.

- Redovito vraćajte potpunu sigurnosnu kopiju na testnom okruženju, uključujući bazu podataka i konfiguraciju.
- Provjerite funkcionira li web-stranica nakon toga u cijelosti: prijava, narudžbe, obrasci, poruke e-pošte.
- Izmjerite trajanje i zabilježite koji su koraci bili ručni. Rezultat usporedite s vremenom koje Vaše poslovanje najviše može izdržati bez web-stranice.
- Uputu za vraćanje pohranite tamo gdje je dostupna i kad poslužitelj ispadne, primjerice u [IT plan za hitne slučajeve](https://phpsos.de/hr/compliance/notfallplan-erstellen/).

## Kako PHP SOS konkretno pomaže?

- Provjeravamo Vaše postojeće sigurnosne kopije na potpunost, čuvanje, odvojenost od poslužitelja i zaštitu od brisanja.
- Postavljamo sigurnosnu kopiju 3-2-1 s nepromjenjivom kopijom i s Vama testiramo vraćanje.
- Nakon incidenta utvrđujemo zadnje čisto stanje i vraćamo ga na zakrpani sustav u okviru [uklanjanja zlonamjernog softvera](https://phpsos.de/hr/leistungen/malware-entfernung/).
- U [ugovoru o sigurnosnom održavanju](https://phpsos.de/hr/leistungen/security-wartungsvertrag/) neprekidno nadziremo sigurnosne kopije i provodimo redovite testove vraćanja.


## Česta pitanja

**Što znači pravilo 3-2-1 kod sigurnosnih kopija?**  
Tri kopije Vaših podataka, na dvije različite vrste pohrane, od kojih je jedna na drugom mjestu. Pravilo osigurava da ni kvar hardvera, ni napad, ni požar ne pogode sve kopije istodobno.

**Je li dovoljna sigurnosna kopija mog pružatelja hostinga?**  
To je dobra dopuna, ali rijetko dovoljna. Razjasnite koliko dugo pružatelj čuva stanja, možete li sami vraćati i bi li napadač s Vašim korisničkim računom mogao obrisati sigurnosne kopije. Preporučuje se vlastita, neovisna kopija.

**Mogu li nakon hakiranja jednostavno vratiti zadnju sigurnosnu kopiju?**  
Samo uz oprez. Zadnja sigurnosna kopija može već sadržavati zlonamjerni kod, a ranjivost kroz koju je napadač došao nakon toga je još otvorena. Najprije razjasnite i zatvorite uzrok, zatim vratite provjereno stanje na zakrpani sustav.

**Koliko često trebam testirati vraćanje?**  
Redovito i nakon većih promjena sustava. Pokazao se dobrim fiksni ritam, primjerice potpuno vraćanje jednom po kvartalu na testnom okruženju. Važno je da se test dokumentira i da se praznine otklone.

## Izvori

- [BSI IT-Grundschutz (njemački standard)](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)
- [BSI: sigurnosno kopiranje podataka](https://www.bsi.bund.de/)
- [php.net: sigurnosne objave o PHP2Shellu](https://www.php.net/)