# Datoteke varnostnih kopij v webrootu: .zip, .sql in .bak

> Datoteke varnostnih kopij v webrootu lahko prenese vsakdo. Tako poiščete datoteke .zip, .sql in .bak, jih blokirate in preverite, ali so bile klicane.

Vir: https://phpsos.de/sl/blog/backup-dateien-im-webroot/  
Stanje: 25.10.2026  
Ponudnik: PHP SOS, Nujna pomoč za PHP in varnost strežnikov. Takojšnja pomoč po WhatsAppu: https://wa.me/491736494914?text=Pozdravljeni%2C%20PHP%20SOS%2C%20potrebujemo%20pomo%C4%8D%20z%20na%C5%A1im%20stre%C5%BEnikom%20PHP.%20Podjetje%3A%20%E2%80%A6%20Spletna%20stran%3A%20%E2%80%A6

**Na kratko:** Datoteke varnostnih kopij v webrootu, torej izpise baz podatkov (`.sql`), arhive (`.zip`, `.tar.gz`) in varnostne kopije (`.bak`, `.old`, `~`), lahko prenese vsakdo, ki pozna ali ugane ime datoteke. Take datoteke redno iščite z `find`, varnostne kopije premaknite zunaj javnega imenika, tipične končnice blokirajte v spletnem strežniku in v dnevnikih dostopa preverite, ali so bile že klicane.

## Varnostna kopija, ki postane uhajanje

Tik pred posodobitvijo nekdo še hitro ustvari varnostno kopijo: `backup.zip` v glavnem imeniku, ob njej `datenbank.sql`. Posodobitev uspe, datoteki ostaneta. Mesece pozneje sta še vedno tam, s celotno kodo, vsemi podatki strank in dostopnimi podatki spletne strani.

Ta vzorec sodi med najpogostejše ugotovitve pri pregledih spletnih strežnikov. Ne potrebuje izkoriščanja ranljivosti niti ranljivosti v PHP. Spletni strežnik iz webroota dostavlja, kar tam leži, arhivov ali datotek SQL pa ne izvede, ampak jih ponudi za prenos.

Arhiv spletne strani ne vsebuje samo podatkov, ampak tudi kodo s konfiguracijo. Kdor ga prenese, lahko v miru išče ranljivosti in pozna dostopne podatke za bazo podatkov.

Samodejni skenerji ciljno iščejo tipična imena, kot so `backup.zip`, `site.tar.gz` ali `dump.sql`, pogosto v kombinaciji z imenom domene ali datumom. Kdor misli, da ga nenavadno ime datoteke ščiti, podcenjuje, kako sistematično to iskanje poteka.

## Katere datoteke so mišljene

Datoteke varnostnih kopij v webrootu nastopajo v več oblikah:

| Vrsta | Tipične končnice | Kaj je notri |
|---|---|---|
| Izpisi baz podatkov | `.sql`, `.sql.gz`, `.dump` | podatki strank, naročila, zgoščene vrednosti gesel, nastavitve |
| Arhivi spletne strani | `.zip`, `.tar`, `.tar.gz`, `.tgz`, `.rar`, `.7z` | vsa koda, konfiguracija, nalaganja |
| Kopije posameznih datotek | `.bak`, `.old`, `.orig`, `.save`, `.php~`, `.copy` | pogosto konfiguracijske datoteke z dostopnimi podatki |
| Ostanki urejevalnika | `.swp`, `.swo`, `~` na koncu | deli datotek, ki so se ravno urejale |
| Varnostne kopije vtičnikov | lastne podmape v CMS | popolne varnostne kopije, deloma z ugibljivimi imeni |

Posebej občutljive so kopije konfiguracijskih datotek. Izvirno datoteko `config.php` strežnik izvede, njena vsebina ostane skrita. Kopijo `config.php.bak` dostavi kot besedilo, skupaj z geslom baze podatkov.

## Iskanje varnostnih kopij v webrootu: iskanje na strežniku

Naslednje iskanje navede sumljive datoteke pod webrooti z datumom in velikostjo. Poti prilagodite svojemu strežniku:

```bash
find /var/www /srv/www -type f \( \
  -iname '*.sql' -o -iname '*.sql.gz' -o -iname '*.dump' -o \
  -iname '*.zip' -o -iname '*.tar' -o -iname '*.tar.gz' -o -iname '*.tgz' -o \
  -iname '*.rar' -o -iname '*.7z' -o \
  -iname '*.bak' -o -iname '*.old' -o -iname '*.orig' -o -iname '*.save' -o \
  -iname '*~' -o -iname '*.swp' \) \
  -printf '%TY-%Tm-%Td  %10s  %p\n' 2>/dev/null | sort
```

Vsak zadetek ni težava. Nekateri arhivi so namerno dani na voljo za prenos, na primer priročniki. Vsaka datoteka pa si zasluži zavestno odločitev. Posebej bodite pozorni na velike datoteke in na mape vtičnikov za varnostno kopiranje. Pri skupnem gostovanju brez dostopa do lupine pomaga pregled datotek v nadzorni plošči gostovanja ali klic prek SFTP.

> **Ukrepajte takoj:**
> Če v webrootu najdete izpis baze podatkov s podatki strank, ga takoj premaknite iz javnega imenika in varnostno shranite dnevnike dostopa, preden se zavrtijo. Šele nato razjasnite, ali je bila datoteka klicana.

## Ali je bila datoteka že prenesena?

Odgovor je v dnevnikih dostopa spletnega strežnika. Iščejo se uspešni klici, torej status 200, na najdene datoteke:

```bash
# Uspešni klici tipičnih končnic varnostnih kopij (format dnevnika Combined)
zgrep -hE '\.(sql|sql\.gz|zip|tar|tgz|gz|bak|old|7z|rar)[ ?]' /var/log/nginx/access.log* \
  | awk '$9 == 200 {print $4, $1, $7, $10}'
```

Izpis pokaže čas, naslov, pot in velikost odgovora. Če prenesena velikost ustreza velikosti datoteke, je bila datoteka v celoti naložena. Kako daleč nazaj segajo dnevniki, je odvisno od rotacije. Če ne segajo do datuma nastanka datoteke, prejšnjega klica ni mogoče izključiti. Podrobno to opisuje [Ocena dnevnikov spletnega strežnika po napadu](https://phpsos.de/sl/ratgeber/logfiles-auswerten/). Brez dostopa do surovih dnevnikov, na primer pri skupnem gostovanju, pri ponudniku gostovanja zaprosite za dnevnike za zadevno obdobje.

Če je bil klican izpis z osebnimi podatki ali tega ni mogoče izključiti, se začne preverjanje obveznosti prijave. Osnove povzema [Obveznost prijave po GDPR: 72 ur po incidentu](https://phpsos.de/sl/compliance/dsgvo-meldepflicht-72-stunden/); presoja v posameznem primeru sodi k vašemu pooblaščencu za varstvo podatkov. Dostopne podatke iz klicanih datotek v vsakem primeru zamenjajte.

## Vtičniki za varnostno kopiranje, nadzorne plošče in selitve

Mnoge najdbe izvirajo iz vtičnikov za varnostno kopiranje v CMS-jih in spletnih trgovinah. Varnostne kopije pogosto shranjujejo v podmapo webroota, deloma z imeni iz datuma in domene, ki jih je mogoče uganiti. V vsakem vtičniku preverite tri nastavitve: kam se shranjuje? Ali se lokalne kopije po nalaganju na zunanji cilj izbrišejo? Ali je lokalna mapa zaščitena pred neposrednim klicem?

Varnostne kopije iz nadzornih plošč gostovanja praviloma ležijo zunaj webroota, na primer v domačem imeniku. Težava nastane, ko nekdo tako kopijo skopira v webroot, ker je prenos v brskalniku udobnejši kot prek SFTP. Za selitve zato velja: prenos prek SFTP ali neposredno med strežniki, nikoli prek javne povezave.

Če vaše spletne strani vzdržujejo agencije ali ponudniki storitev, naj to pravilo stoji tudi v pogodbi, skupaj z obveznostjo čiščenja po vzdrževalnih delih. Napotke daje [Pogodbe z ponudniki IT: jasno uredite varnostne obveznosti](https://phpsos.de/sl/blog/dienstleistervertrag-sicherheit/).

## Trajno preprečevanje: mesto shranjevanja in blokade

Da se težava ne ponovi, sta potrebni dve ravni. Prva je organizacijska: varnostne kopije imajo stalno mesto zunaj webroota in dodatno zunaj strežnika. Kako izgleda zanesljiva varnostna kopija, opisuje vodnik [Varnostne kopije po pravilu 3-2-1](https://phpsos.de/sl/ratgeber/backups-3-2-1/).

Druga raven je tehnična: spletni strežnik načeloma zavrne tipične končnice varnostnih kopij, tudi če kakšna datoteka vseeno ostane.

```nginx
location ~* \.(sql|sql\.gz|dump|bak|old|orig|save|swp|swo)$ {
    return 404;
}
location ~ ~$ {
    return 404;
}
```

Arhive, kot je `.zip`, blokirate samo, če vaša spletna stran ne ponuja prenosov v tej obliki, ali ciljno v imenikih, kjer ni prenosov. Dodatno pomagajo redno samodejno iskanje z obveščanjem in kratko pravilo v ekipi: nobenih varnostnih kopij in kopij v webrootu, niti za pet minut. Sorodne primere, kot so skrite konfiguracijske datoteke, obravnava [Pravilna zaščita dostopnih podatkov in datotek .env](https://phpsos.de/sl/blog/env-dateien-schuetzen/).

## Kako konkretno pomaga PHP SOS?

- Preiščemo vaše webroote glede izpisov, arhivov, kopij in varnostnih kopij vtičnikov ter ocenimo vsako najdbo.
- Na podlagi dnevnikov dostopa preverimo, ali so bile datoteke klicane, in rezultat dokumentiramo za vašo presojo varstva podatkov.
- Vzpostavimo blokade v spletnem strežniku in redno samodejno iskanje.
- Varnostne kopije prestavimo na zaščiteno mesto zunaj webroota.

Ta dela so del našega [utrjevanja strežnikov PHP](https://phpsos.de/sl/leistungen/server-haertung/).


## Pogosta vprašanja

**Zakaj varnostne kopije sploh pristanejo v webrootu?**  
Večinoma iz udobja: izpis se ustvari za selitev, vtičnik shrani varnostne kopije v lastno mapo ali pa se pred spremembo hitro naredi kopija datoteke s končnico .bak. Nato datoteka utone v pozabo.

**Kako nevarna je datoteka, kot je config.php.bak?**  
Zelo. Datoteko s končnico .php strežnik izvede, njena vsebina ostane skrita. Kopijo z drugo končnico pa strežnik praviloma dostavi kot besedilo, skupaj z geslom baze podatkov in ključi.

**Ali je javno dosegljiv izpis baze podatkov kršitev varstva podatkov?**  
Če vsebuje osebne podatke in je bil klican ali klica ni mogoče izključiti, pride v poštev obveznost prijave po GDPR. Presojo v posameznem primeru prevzameta vaš pooblaščenec za varstvo podatkov ali vaše pravno svetovanje.

**Kje naj bodo varnostne kopije namesto tega?**  
Zunaj webroota in dodatno zunaj strežnika, po pravilu 3-2-1. Vsaj ena kopija naj bo shranjena tako, da je spletni strežnik sam ne more izbrisati ali spremeniti.

## Viri

- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [GDPR, 33. člen: prijava nadzornemu organu](https://dsgvo-gesetz.de/art-33-dsgvo/)
- [Dokumentacija Nginx](https://nginx.org/en/docs/)