# Serveri varundusstrateegia: varukoopiad 3-2-1-reegli järgi

> Serveri varundusstrateegia 3-2-1-reegli järgi: mida tuleb varundada, kuidas varukoopiad rünnaku üle elavad ja miks taastamist tuleb testida.

Allikas: https://phpsos.de/et/ratgeber/backups-3-2-1/  
Seis: 25.10.2026  
Pakkuja: PHP SOS, PHP hädaabi ja serveri turvalisus. Kohene abi WhatsAppis: https://wa.me/491736494914?text=Tere%2C%20PHP%20SOS%2C%20vajame%20abi%20oma%20PHP-serveriga.%20Ettev%C3%B5te%3A%20%E2%80%A6%20Veebisait%3A%20%E2%80%A6

**Lühidalt:** Töökindel serveri varundusstrateegia järgib 3-2-1-reeglit: kolm koopiat, kaks salvestusviisi, üks koopia väljaspool asukohta. Et varukoopiad rünnaku üle elaksid, vajab vähemalt üks koopia kaitset serveri enda poolt kustutamise eest. Ja alles õnnestunud taastetest näitab, et varundus tõsiolukorras toimib.

## Mida 3-2-1-reegel tähendab

3-2-1-reegel on lihtne, aastaid end tõestanud põhimõte andmete varundamiseks:

- **3 koopiat:** algandmed ja kaks varukoopiat.
- **2 salvestusviisi:** näiteks kohalik ketas ja objektihoidla või serveri salvestus ja lint.
- **1 koopia väljaspool asukohta:** teises asukohas, teise pakkuja juures või võrguühenduseta.

Veebiserverite puhul tähendab see konkreetselt: varukoopia samal kõvakettal kui veebisait ei loe iseseisva koopiana. Kui server ebaõnnestub või kompromiteeritakse, on mõlemad kadunud. Juhatuse jaoks ei ole põhiküsimus seetõttu „Kas meil on varukoopiad?“, vaid „Kas me saame töö taastada koopiast, milleni intsident ei ulatunud?“

## Serveri varundusstrateegia, mis rünnaku üle elab

Ründajad teavad, et varukoopiad teevad nende töö tühjaks. Kes on serverisse pääsenud, otsib seetõttu sageli ka varukoopiaid, et neid kustutada või krüpteerida. Kaasaegne strateegia laiendab 3-2-1-reeglit seetõttu sageli väärtusele **3-2-1-1-0**: üks koopia lisaks võrguühenduseta või muutumatult ning null viga taastetestil.

Kolm põhimõtet teevad varukoopiad vastupidavaks:

- **Pull, mitte push:** Eraldi varundussüsteem toob andmed veebiserverist ära. Veebiserveril endal ei ole ligipääsuandmeid, millega ta saaks varukoopiaid kustutada.
- **Muutumatus:** Objektihoidla säilituslukuga või hetktõmmised (snapshot), mida ei saa kindlaks ajaks kustutada.
- **Lahutatud ligipääsud:** Varundusekonto ei ole sama mis hostingu kliendikonto ja sellel on oma teine faktor.

> **Oluline:**
> Krüpteerige väljaspool asukohta olevad varukoopiad ja hoidke võtit eraldi. Kaotatud võti muudab varukoopia kasutuks, kaasasalvestatud võti muudab krüpteerimise väärtusetuks.

## Mida tuleb varundada

Veebiserverite puhul varundatakse sageli ainult veebijuur. Täielikuks taastamiseks puuduvad siis olulised osad.

| Valdkond | Näited | Märkus |
|---|---|---|
| Rakenduse failid | veebijuur, üleslaaditud failid, teemad, laiendused | üleslaadimised muutuvad sageli |
| Andmebaasid | MySQL/MariaDB, PostgreSQL | varundada järjepidevalt, mitte ainult faile kopeerida |
| Seadistus | veebiserver, PHP-FPM poolid, php.ini, cron-ülesanded | vajalik kiireks uuesti ülesehituseks |
| Sertifikaadid ja võtmed | TLS-sertifikaadid, rakenduse võtmed | hoida krüpteeritult ja eraldi |
| Dokumentatsioon | ligipääsud, sõltuvused, taastamise kulg | ilma selleta kestab iga uuesti ülesehitus kauem |

## Näide: andmebaasi ja failide varundamine

Järgmine näide näitab igapäevase varunduse põhielemente. Praktikas võtab edastamise väljaspool asukohta üle varundustööriist krüpteerimise, dubleerimise kõrvaldamise ja säilitusreeglitega.

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

# Andmebaas varundada järjepidevalt; ligipääsuandmed kaitstud failist, mitte käsus
mysqldump --defaults-extra-file=/root/.backup-my.cnf \
  --single-transaction --routines --triggers shopdb | gzip > "$ZIEL/shopdb.sql.gz"

# Rakenduse failid ja seadistus
tar -czf "$ZIEL/webroot.tar.gz" -C /var/www shop
tar -czf "$ZIEL/config.tar.gz" /etc/nginx /etc/php /etc/cron.d

# Kontrollsummad hilisemaks kontrolliks
sha256sum "$ZIEL"/* > "$ZIEL/SHA256SUMS"
```

Fail `.backup-my.cnf` sisaldab andmebaasikasutaja ligipääsuandmeid, kellel on lubatud ainult lugeda, ja selle õigused on `0600`. `--single-transaction` tagab InnoDB tabelite puhul järjepideva seisu poodi peatamata.

Seejärel edastab eraldi süsteem varukoopia väljaspool asukohta. Oluline on, et seda sammu jälgitakse: varunduse ülesanne, mis on päevi vaikselt ebaõnnestunud, jääb muidu silma alles tõsiolukorras. Piisab igapäevasest teatest õnnestumise, suuruse ja kestuse kohta, kui keegi seda loeb ja kõrvalekalletele reageerib.

Kui kasutate lisaks veebimajutaja varukoopiaid või hetktõmmiseid, selgitage kirjalikult, kui kaua neid säilitatakse, kas saate ise taastada ja kas varukoopiad säilivad lõpetatud või lukustatud konto korral. Need koopiad on hea täiendus, kuid ei asenda oma sõltumatut varundust.

## Säilitus: miks vanemad seisud on pärast PHP2Shelli olulised

Pärast rünnakut ei ole kõige väärtuslikum värskeim varukoopia, vaid värskeim puhas. PHP2Shelli puhul täheldati meediaraportite kohaselt 17.10.2026 esimest rünnakukatset, paigad ilmusid 21.10.2026. Kes säilitab ainult seitse päeva, ei pruugi omada enam seisu, mis asuks kindlalt enne võimalikku sissemurdmist.

End tõestanud skeem kombineerib mitu ajavahemikku, näiteks päevased varukoopiad mõneks nädalaks, nädalased mõneks kuuks ja kuised aastaks. Täpsed ajavahemikud sõltuvad teie kaitsevajadusest ja andmekaitsest tulenevatest kustutuskohustustest.

Oluline on ka: pärast sissemurdmist tehtud varukoopia võib sisaldada veebishelle või muudetud faile. Ärge taastage pärast intsidenti pimesi, vaid võrrelge faile puhta seisuga ja kontrollige neid, enne kui veebisait taas võrku läheb. Vihjeid, mille peale tähelepanu pöörata, leiate lehelt [Kompromiteerimise tunnused](https://phpsos.de/et/php2shell/bin-ich-gehackt-anzeichen/). Paik ei eemalda sissetoodud kahjutarkvara ja varukoopia ei tee seda samuti iseenesest.

## Taastamise testimine ja dokumenteerimine

Varukoopia ilma testita on oletus. Alles taastamine näitab, kas kõik osad on olemas, kas võti toimib ja kui kaua protsess tegelikult kestab.

- Taastage regulaarselt täielik varukoopia testkeskkonnas, koos andmebaasi ja seadistusega.
- Kontrollige, kas veebisait pärast seda täielikult töötab: sisselogimine, tellimused, vormid, e-kirjad.
- Mõõtke kestust ja fikseerige, millised sammud olid käsitsi. Võrrelge tulemust ajaga, mille võrra teie ettevõte ilma veebisaidita kõige rohkem hakkama saab.
- Paigutage taastamisjuhend sinna, kus see on kättesaadav ka serveri rikke korral, näiteks [IT-hädaolukorra plaani](https://phpsos.de/et/compliance/notfallplan-erstellen/).

## Kuidas PHP SOS konkreetselt aitab?

- Kontrollime teie olemasolevaid varukoopiaid täielikkuse, säilituse, serverist lahutatuse ja kustutamise vastu kaitse osas.
- Seame üles 3-2-1-varunduse muutumatu koopiaga ja testime taastamist koos teiega.
- Pärast intsidenti tuvastame viimase puhta seisu ja taastame selle [kahjuliku koodi eemaldamise](https://phpsos.de/et/leistungen/malware-entfernung/) käigus paigatud süsteemi.
- [Turvahoolduslepingu](https://phpsos.de/et/leistungen/security-wartungsvertrag/) raames jälgime varukoopiaid pidevalt ja teostame regulaarseid taastetesti.


## Korduma kippuvad küsimused

**Mida 3-2-1-reegel varukoopiate puhul tähendab?**  
Kolm koopiat teie andmetest, kahel erineval salvestusviisil, millest üks asub teises kohas. Reegel tagab, et ei riistvaratõrge, rünnak ega tulekahju ei tabaks kõiki koopiaid korraga.

**Kas minu veebimajutaja varukoopiast piisab?**  
See on hea täiendus, kuid harva piisav. Selgitage välja, kui kaua veebimajutaja seise säilitab, kas saate ise taastada ja kas ründaja saaks teie kliendikontoga varukoopiaid kustutada. Oma sõltumatu koopia on soovitatav.

**Kas pärast häkkimist võib lihtsalt viimase varukoopia tagasi paigaldada?**  
Ainult ettevaatusega. Viimane varukoopia võib juba sisaldada kahjulikku koodi ja turvaauk, mille kaudu ründaja sisse tuli, on pärast seda veel avatud. Esmalt põhjus selgitada ja sulgeda, seejärel kontrollitud seis paigatud süsteemi taastada.

**Kui tihti peaksin taastamist testima?**  
Regulaarselt ja pärast suuremaid süsteemimuudatusi. Kindel rütm, näiteks üks täielik taastamine kvartalis testkeskkonnas, on end tõestanud. Oluline on, et test dokumenteeritakse ja lüngad kõrvaldatakse.

## Allikad

- [BSI IT-Grundschutz](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)
- [BSI: andmete varundamine](https://www.bsi.bund.de/)
- [php.net: PHP2Shelli turvateated](https://www.php.net/)