# Palvelimen varmuuskopiostrategia: varmuuskopiot 3-2-1-säännön mukaan

> Palvelimen varmuuskopiostrategia 3-2-1-säännön mukaan: mitä on varmistettava, miten varmuuskopiot selviävät hyökkäyksestä ja miksi palautus testataan.

Lähde: https://phpsos.de/fi/ratgeber/backups-3-2-1/  
Tilanne: 25.10.2026  
Palveluntarjoaja: PHP SOS, PHP-hätäapu ja palvelimen tietoturva. Pikaapu WhatsAppilla: https://wa.me/491736494914?text=Hei%20PHP%20SOS%2C%20tarvitsemme%20apua%20PHP-palvelimemme%20kanssa.%20Yritys%3A%20%E2%80%A6%20Verkkosivusto%3A%20%E2%80%A6

**Lyhyesti:** Kestävä palvelimen varmuuskopiostrategia noudattaa 3-2-1-sääntöä: kolme kopiota, kaksi tallennustyyppiä, yksi kopio toisessa paikassa. Jotta varmuuskopiot selviävät myös hyökkäyksestä, vähintään yhden kopion tarvitsee olla suojassa palvelimen itsensä suorittamalta poistolta. Ja vasta onnistunut palautustesti osoittaa, että varmuuskopio toimii hätätilanteessa.

## Mitä 3-2-1-sääntö tarkoittaa

3-2-1-sääntö on yksinkertainen, vuosia toimivaksi osoittautunut periaate tietojen varmuuskopiointiin:

- **3 kopiota:** alkuperäiset tiedot ja kaksi varmuuskopiota.
- **2 tallennustyyppiä:** esimerkiksi paikallinen levy ja objektivarasto, tai palvelimen tallennustila ja nauha.
- **1 kopio toisessa paikassa:** eri sijainnissa, eri palveluntarjoajalla tai offline-tilassa.

Verkkopalvelimille se tarkoittaa konkreettisesti: varmuuskopio samalla kiintolevyllä kuin verkkosivusto ei ole itsenäinen kopio. Jos palvelin vikaantuu tai vaarantuu, molemmat menetetään. Johdolle ydinkysymys ei siksi ole ”Onko meillä varmuuskopioita?” vaan ”Voimmeko palauttaa toiminnan kopiosta, jota poikkeama ei ole tavoittanut?”

## Palvelimen varmuuskopiostrategia, joka selviää hyökkäyksestä

Hyökkääjät tietävät, että varmuuskopiot tekevät heidän työnsä tyhjäksi. Joka on päässyt palvelimelle, etsii siksi usein myös varmuuskopioita poistaakseen tai salatakseen ne. Nykyaikainen strategia laajentaa 3-2-1-sääntöä siksi usein muotoon **3-2-1-1-0**: yksi kopio lisäksi offline-tilassa tai muuttumattomana, ja nolla virhettä palautustestissä.

Kolme periaatetta tekee varmuuskopioista kestäviä:

- **Pull Pushin sijaan:** Erillinen varmuuskopiojärjestelmä hakee tiedot verkkopalvelimelta. Itse verkkopalvelimella ei ole tunnuksia, joilla se voisi poistaa varmuuskopioita.
- **Muuttumattomuus:** Objektivarasto säilytyslukolla tai tilannevedokset, joita ei voi määräajan sisällä poistaa.
- **Erilliset pääsyt:** Varmuuskopiotili ei ole sama kuin hostingin asiakastili, ja sillä on oma toinen tekijänsä.

> **Tärkeää:**
> Salatkaa varmuuskopiot, jotka ovat toisessa paikassa, ja säilyttäkää avain erillään. Kadonnut avain tekee varmuuskopiosta käyttökelvottoman, mukana tallennettu avain tekee salauksesta arvottoman.

## Mitä on varmistettava

Verkkopalvelimilla varmistetaan usein vain web-juuri. Täydelliseen palautukseen silloin puuttuu tärkeitä osia.

| Alue | Esimerkit | Huomautus |
|---|---|---|
| Sovellustiedostot | Web-juuri, uploadit, teemat, laajennukset | Uploadit muuttuvat usein |
| Tietokannat | MySQL/MariaDB, PostgreSQL | varmista yhdenmukaisesti, älä vain kopioi tiedostoja |
| Asetukset | Verkkopalvelin, PHP-FPM-poolit, php.ini, cron-tehtävät | tarpeen nopeaan uudelleenrakennukseen |
| Varmenteet ja avaimet | TLS-varmenteet, sovellusavaimet | tallenna salattuina ja erillään |
| Dokumentaatio | Pääsyt, riippuvuudet, palautuksen kulku | ilman sitä jokainen uudelleenrakennus kestää kauemmin |

## Esimerkki: tietokannan ja tiedostojen varmistus

Seuraava esimerkki näyttää päivittäisen varmistuksen perusosat. Käytännössä varmuuskopiotyökalu salauksella, deduplikoinnilla ja säilytyssäännöillä hoitaa siirron toiseen paikkaan.

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

# Varmista tietokanta yhdenmukaisesti; tunnukset suojatusta tiedostosta, ei komennossa
mysqldump --defaults-extra-file=/root/.backup-my.cnf \
  --single-transaction --routines --triggers shopdb | gzip > "$ZIEL/shopdb.sql.gz"

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

# Tarkistussummat myöhempää tarkistusta varten
sha256sum "$ZIEL"/* > "$ZIEL/SHA256SUMS"
```

Tiedosto `.backup-my.cnf` sisältää tietokantakäyttäjän tunnukset, jolla on vain lukuoikeus, ja sen oikeudet ovat `0600`. `--single-transaction` huolehtii InnoDB-tauluissa yhdenmukaisesta tilasta pysäyttämättä verkkokauppaa.

Sen jälkeen erillinen järjestelmä siirtää varmuuskopion toiseen paikkaan. Tärkeää on, että tätä vaihetta valvotaan: varmuuskopiotyö, joka on epäonnistunut äänettömästi päiviä, huomataan muuten vasta hätätilanteessa. Päivittäinen ilmoitus onnistumisesta, koosta ja kestosta riittää, kunhan joku lukee sen ja käsittelee poikkeamat.

Jos käytätte lisäksi hosting-yrityksenne varmuuskopioita tai tilannevedoksia, selvittäkää kirjallisesti, kuinka kauan niitä säilytetään, voitteko palauttaa itse ja säilyvätkö varmuuskopiot, jos tili irtisanotaan tai suljetaan. Nämä kopiot ovat hyvä lisä, mutta eivät korvaa omaa, riippumatonta varmuuskopiota.

## Säilytys: miksi vanhemmat tilat ovat tärkeitä PHP2Shellin jälkeen

Hyökkäyksen jälkeen arvokkain ei ole tuorein varmuuskopio vaan tuorein puhdas. PHP2Shellissä havaittiin mediaraporttien mukaan 17.10.2026 ensimmäinen hyökkäysyritys, ja korjaukset ilmestyivät 21.10.2026. Joka säilyttää vain seitsemän päivää, ei ehkä enää omista tilaa, joka olisi varmasti ennen mahdollista murtoa.

Toimiva malli yhdistää useita jaksoja, esimerkiksi päivittäiset varmuuskopiot muutaman viikon ajan, viikoittaiset muutaman kuukauden ja kuukausittaiset vuoden. Tarkat jaksot määräytyvät suojaustarpeen ja tietosuojan poistovelvoitteiden mukaan.

Tärkeää on myös: murron jälkeen otettu varmuuskopio voi sisältää web shellejä tai muutettuja tiedostoja. Älkää palauttako poikkeaman jälkeen sokkona vaan vertailkaa tiedostoja puhtaaseen tilaan ja tarkistakaa ne, ennen kuin verkkosivusto palaa verkkoon. Vihjeitä siitä, mihin kannattaa kiinnittää huomiota, löytyy sivulta [Vaarantumisen merkit](https://phpsos.de/fi/php2shell/bin-ich-gehackt-anzeichen/). Korjaus ei poista lisättyä haittaohjelmaa, eikä varmuuskopiokaan tee sitä itsestään.

## Palautuksen testaus ja dokumentointi

Varmuuskopio ilman testiä on olettamus. Vasta palautus osoittaa, ovatko kaikki osat mukana, toimiiko avain ja kuinka kauan toimenpide todella kestää.

- Palauttakaa säännöllisesti täydellinen varmuuskopio testiympäristöön, tietokanta ja asetukset mukaan lukien.
- Tarkistakaa, toimiiko verkkosivusto sen jälkeen täysin: kirjautuminen, tilaukset, lomakkeet, sähköpostit.
- Mitatkaa kesto ja kirjatkaa, mitkä vaiheet olivat käsin tehtyjä. Verratkaa tulosta aikaan, jonka toimintanne enintään kestää ilman verkkosivustoa.
- Tallentakaa palautusohje paikkaan, josta se on tavoitettavissa myös palvelimen ollessa poissa käytöstä, esimerkiksi [IT-hätäsuunnitelmaan](https://phpsos.de/fi/compliance/notfallplan-erstellen/).

## Miten PHP SOS auttaa konkreettisesti?

- Tarkistamme nykyiset varmuuskopionne täydellisyyden, säilytyksen, erotuksen palvelimesta ja poistosuojauksen osalta.
- Otamme käyttöön 3-2-1-varmistuksen muuttumattomalla kopiolla ja testaamme palautuksen yhdessä kanssanne.
- Poikkeaman jälkeen tunnistamme viimeisimmän puhtaan tilan ja palautamme sen korjatulle järjestelmälle [haittaohjelmien poiston](https://phpsos.de/fi/leistungen/malware-entfernung/) yhteydessä.
- [Tietoturvahuoltosopimuksessa](https://phpsos.de/fi/leistungen/security-wartungsvertrag/) valvomme varmuuskopioita jatkuvasti ja teemme säännöllisiä palautustestejä.


## Usein kysytyt kysymykset

**Mitä 3-2-1-sääntö tarkoittaa varmuuskopioinnissa?**  
Kolme kopiota tiedoistanne, kahdella eri tallennustyypillä, joista yksi toisessa paikassa. Sääntö huolehtii siitä, ettei laitteistovika, hyökkäys tai tulipalo osu kaikkiin kopioihin yhtä aikaa.

**Riittääkö hosting-yritykseni varmuuskopio?**  
Se on hyvä lisä, mutta harvoin riittävä. Selvittäkää, kuinka kauan hosting-yritys säilyttää tiloja, voitteko palauttaa itse ja voisiko hyökkääjä asiakastilillänne poistaa varmuuskopiot. Oma, riippumaton kopio on suositeltava.

**Voinko murron jälkeen vain palauttaa viimeisimmän varmuuskopion?**  
Vain varoen. Viimeisin varmuuskopio voi jo sisältää haittakoodia, ja aukko, jonka kautta hyökkääjä pääsi sisään, on sen jälkeen yhä auki. Selvittäkää ja sulkekaa ensin syy, palauttakaa sitten tarkistettu tila korjatulle järjestelmälle.

**Kuinka usein palautus pitäisi testata?**  
Säännöllisesti ja suurempien järjestelmämuutosten jälkeen. Kiinteä rytmi, esimerkiksi täydellinen palautus kerran neljänneksessä testiympäristöön, on osoittautunut toimivaksi. Tärkeää on, että testi dokumentoidaan ja puutteet korjataan.

## Lähteet

- [BSI IT-Grundschutz](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)
- [BSI: tietojen varmuuskopiointi](https://www.bsi.bund.de/)
- [php.net: PHP2Shellin tietoturvatiedotteet](https://www.php.net/)