Na kratko: Zanesljiva strategija varnostnih kopij strežnika sledi pravilu 3-2-1: tri kopije, dve vrsti pomnilnika, ena kopija zunaj hiše. Da varnostne kopije preživijo tudi napad, mora imeti vsaj ena kopija zaščito pred brisanjem s strani samega strežnika. In šele uspešen preizkus obnovitve pokaže, da varnostna kopija v nujnem primeru deluje.
Kaj pomeni pravilo 3-2-1
Pravilo 3-2-1 je preprosto, že leta preizkušeno načelo za varnostno kopiranje podatkov:
- 3 kopije: izvirni podatki in dve varnostni kopiji.
- 2 vrsti pomnilnika: na primer lokalni disk in objektni pomnilnik ali pomnilnik strežnika in trak.
- 1 kopija zunaj hiše: na drugi lokaciji, pri drugem ponudniku ali brez povezave.
Za spletne strežnike to konkretno pomeni: varnostna kopija na istem disku kot spletna stran ne šteje kot samostojna kopija. Če strežnik odpove ali je kompromitiran, sta obe izgubljeni. Za vodstvo temeljno vprašanje zato ni „Ali imamo varnostne kopije?“, ampak „Ali lahko delovanje obnovimo iz kopije, ki je incident ni dosegel?“
Strategija varnostnih kopij strežnika, ki preživi napad
Napadalci vedo, da varnostne kopije uničijo njihovo delo. Kdor ima dostop do strežnika, zato pogosto išče tudi varnostne kopije, da bi jih izbrisal ali šifriral. Sodobna strategija zato pravilo 3-2-1 pogosto razširi na 3-2-1-1-0: ena dodatna kopija brez povezave ali nespremenljiva in nič napak pri preizkusu obnovitve.
Trije principi naredijo varnostne kopije odporne:
- Pull namesto push: Ločen sistem za varnostno kopiranje podatke prevzame s spletnega strežnika. Sam spletni strežnik nima dostopnih podatkov, s katerimi bi lahko brisal varnostne kopije.
- Nespremenljivost: Objektni pomnilnik z zaklepom hranjenja ali posnetki (snapshots), ki jih določen čas ni mogoče izbrisati.
- Ločeni dostopi: Račun za varnostne kopije ni isti kot račun stranke pri ponudniku gostovanja in ima lasten drugi faktor.
Varnostne kopije zunaj hiše šifrirajte, ključ pa hranite ločeno. Izgubljen ključ naredi varnostno kopijo neuporabno, skupaj shranjen ključ pa naredi šifriranje brez vrednosti.
Kaj je treba zavarovati
Pri spletnih strežnikih se pogosto zavaruje samo koren spleta. Za popolno obnovitev potem manjkajo pomembni deli.
| Področje | Primeri | Opomba |
|---|---|---|
| Datoteke aplikacije | Koren spleta, nalaganja, teme, razširitve | Nalaganja se pogosto spreminjajo |
| Podatkovne zbirke | MySQL/MariaDB, PostgreSQL | zavarovati konsistentno, ne samo kopirati datotek |
| Konfiguracija | Spletni strežnik, pooli PHP-FPM, php.ini, cron opravila | potrebno za hiter ponovni zagon |
| Certifikati in ključi | Certifikati TLS, ključi aplikacije | hraniti šifrirano in ločeno |
| Dokumentacija | Dostopi, odvisnosti, potek obnovitve | brez nje vsaka ponovna postavitev traja dlje |
Primer: varnostno kopiranje podatkovne zbirke in datotek
Naslednji primer prikazuje osnovne gradnike dnevnega varnostnega kopiranja. V praksi prenos zunaj hiše prevzame orodje za varnostno kopiranje s šifriranjem, deduplikacijo in pravili hranjenja.
#!/bin/bash
set -euo pipefail
DATUM=$(date +%F)
ZIEL=/srv/backup/$DATUM
mkdir -p "$ZIEL"
chmod 700 "$ZIEL"
# Podatkovno zbirko zavarujte konsistentno; dostopni podatki iz zaščitene datoteke, ne v ukazu
mysqldump --defaults-extra-file=/root/.backup-my.cnf \
--single-transaction --routines --triggers shopdb | gzip > "$ZIEL/shopdb.sql.gz"
# Datoteke aplikacije in konfiguracija
tar -czf "$ZIEL/webroot.tar.gz" -C /var/www shop
tar -czf "$ZIEL/config.tar.gz" /etc/nginx /etc/php /etc/cron.d
# Kontrolne vsote za poznejše preverjanje
sha256sum "$ZIEL"/* > "$ZIEL/SHA256SUMS"
Datoteka .backup-my.cnf vsebuje dostopne podatke uporabnika podatkovne zbirke, ki sme samo brati, in ima pravice 0600. --single-transaction pri tabelah InnoDB poskrbi za konsistentno stanje, ne da bi trgovino ustavili.
Nato ločen sistem varnostno kopijo prenese zunaj hiše. Pomembno je, da se ta korak nadzira: opravilo varnostnega kopiranja, ki že dneve tiho spodleti, sicer pade v oči šele v nujnem primeru. Dnevno poročilo o uspehu, velikosti in trajanju zadošča, dokler ga nekdo bere in sledi odstopanjem.
Če dodatno uporabljate varnostne kopije ali posnetke svojega ponudnika gostovanja, pisno razjasnite, kako dolgo se hranijo, ali lahko sami obnovite in ali varnostne kopije ostanejo ohranjene pri odpovedanem ali blokiranem računu. Te kopije so dobra dopolnitev, a lastne, neodvisne varnostne kopije ne nadomestijo.
Hranjenje: zakaj so starejša stanja po PHP2Shell pomembna
Po napadu ni najdragocenejša najnovejša varnostna kopija, ampak najnovejša čista. Pri PHP2Shell je bil po poročilih medijev 17. 10. 2026 opažen prvi poskus napada, popravki so izšli 21. 10. 2026. Kdor hrani samo sedem dni, morda nima več stanja, ki bi bilo zanesljivo pred možnim vdorom.
Preizkušena shema združuje več obdobij, na primer dnevne varnostne kopije za nekaj tednov, tedenske za nekaj mesecev in mesečne za eno leto. Natančna obdobja so odvisna od vaše potrebe po zaščiti in od obveznosti brisanja po predpisih o varstvu podatkov.
Pomembno je tudi: varnostna kopija iz časa po vdoru lahko vsebuje webshelle ali spremenjene datoteke. Po incidentu nikoli ne obnavljajte na slepo, ampak datoteke primerjajte s čistim stanjem in jih preverite, preden je spletna stran znova na spletu. Napotke, na kaj paziti, najdete na strani Znaki kompromitacije. Popravek ne odstrani vnesene škodljive programske opreme, varnostna kopija pa tega prav tako ne naredi sama od sebe.
Preizkusite in dokumentirajte obnovitev
Varnostna kopija brez preizkusa je domneva. Šele obnovitev pokaže, ali so vsi deli prisotni, ali ključ deluje in kako dolgo postopek dejansko traja.
- Redno obnovite popolno varnostno kopijo v testnem okolju, vključno s podatkovno zbirko in konfiguracijo.
- Preverite, ali spletna stran po tem v celoti deluje: prijava, naročila, obrazci, e-pošta.
- Izmerite trajanje in zabeležite, kateri koraki so bili ročni. Rezultat primerjajte s časom, ki ga vaše poslovanje največ zdrži brez spletne strani.
- Navodilo za obnovitev shranite tam, kjer je dosegljivo tudi pri izpadlem strežniku, na primer v IT-načrtu za nujne primere.
Kako PHP SOS pomaga konkretno?
- Vaše obstoječe varnostne kopije preverimo glede popolnosti, hranjenja, ločitve od strežnika in zaščite pred brisanjem.
- Vzpostavimo varnostno kopiranje 3-2-1 z nespremenljivo kopijo in skupaj z vami preizkusimo obnovitev.
- Po incidentu določimo zadnje čisto stanje in ga v okviru odstranitve zlonamerne programske opreme obnovimo na popravljen sistem.
- V vzdrževalni pogodbi za varnost varnostne kopije stalno nadzorujemo in izvajamo redne preizkuse obnovitve.
Pogosta vprašanja
Kaj pomeni pravilo 3-2-1 pri varnostnih kopijah?
Tri kopije vaših podatkov, na dveh različnih vrstah pomnilnika, od tega ena na drugem mestu. Pravilo poskrbi, da niti okvara strojne opreme niti napad niti požar ne zadenejo vseh kopij hkrati.
Ali zadošča varnostna kopija mojega ponudnika gostovanja?
Je dobra dopolnitev, a redko zadostna. Razjasnite, kako dolgo ponudnik hrani stanja, ali lahko sami obnovite in ali bi napadalec z vašim računom stranke lahko izbrisal varnostne kopije. Priporočljiva je lastna, neodvisna kopija.
Ali lahko po vdoru preprosto namestim zadnjo varnostno kopijo?
Samo previdno. Zadnja varnostna kopija lahko že vsebuje škodljivo kodo, ranljivost, prek katere je napadalec prišel, pa je potem še odprta. Najprej razjasnite in zaprite vzrok, nato preverjeno stanje povrnite na popravljen sistem.
Kako pogosto naj preizkusim obnovitev?
Redno in po večjih spremembah sistema. Obnesel se je fiksen ritem, na primer popolna obnovitev vsako četrtletje v testnem okolju. Pomembno je, da je preizkus dokumentiran in da se vrzeli odpravijo.