# Mentési stratégia szerverhez: mentések a 3-2-1 szabály szerint

> Mentési stratégia szerverhez a 3-2-1 szabály szerint: mit kell menteni, hogyan élik túl a mentések a támadást, és miért kell tesztelni a visszaállítást.

Forrás: https://phpsos.de/hu/ratgeber/backups-3-2-1/  
Állapot: 2026. 10. 25.  
Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6

**Röviden:** Egy terhelhető szerver-mentési stratégia a 3-2-1 szabályt követi: három másolat, két tárolótípus, egy másolat házon kívül. Hogy a mentések a támadást is túléljék, legalább egy másolatnak védettnek kell lennie a szerver általi törléssel szemben. És csak egy sikeres visszaállítási teszt mutatja meg, hogy a mentés éles helyzetben működik.

## Mit jelent a 3-2-1 szabály

A 3-2-1 szabály egy egyszerű, évek óta bevált alapelv az adatmentéshez:

- **3 másolat:** az eredeti adatok és két mentés.
- **2 tárolótípus:** például helyi lemez és objektumtároló, vagy szerver-tároló és szalag.
- **1 másolat házon kívül:** másik helyszínen, másik szolgáltatónál vagy offline.

Webszerverekre ez konkrétan azt jelenti: a weboldallal azonos merevlemezen lévő mentés nem számít önálló másolatnak. Ha a szerver kiesik vagy feltörik, mindkettő elvész. A vezetőség számára a központi kérdés ezért nem az „Van mentésünk?“, hanem a „Vissza tudjuk állítani az üzemet egy olyan másolatból, amelyet az incidens nem ért el?“

## Egy szerver-mentési stratégia, amely túléli a támadást

A támadók tudják, hogy a mentések tönkreteszik a munkájukat. Aki hozzáfér egy szerverhez, gyakran a mentéseket is keresi, hogy törölje vagy titkosítsa őket. Egy modern stratégia ezért gyakran kiterjeszti a 3-2-1 szabályt **3-2-1-1-0**-ra: egy további, offline vagy módosíthatatlan másolat, és nulla hiba a visszaállítási tesztnél.

Három alapelv teszi ellenállóvá a mentéseket:

- **Pull a push helyett:** Egy külön mentési rendszer hozza le az adatokat a webszerverről. Maga a webszerver nem rendelkezik olyan hozzáférési adatokkal, amelyekkel törölhetné a mentéseket.
- **Módosíthatatlanság:** megőrzési zárolással ellátott objektumtároló, vagy olyan pillanatképek, amelyek egy meghatározott ideig nem törölhetők.
- **Elkülönített hozzáférések:** A mentési fiók nem ugyanaz, mint a tárhely-ügyfélfiók, és saját második faktora van.

> **Fontos:**
> A házon kívül tárolt mentéseket titkosítsa, és a kulcsot elkülönítve őrizze. Egy elveszett kulcs használhatatlanná teszi a mentést, egy együtt tárolt kulcs értéktelenné teszi a titkosítást.

## Mit kell menteni

A webszervereknél gyakran csak a webgyökeret mentik. A teljes visszaállításhoz ekkor fontos részek hiányoznak.

| Terület | Példák | Megjegyzés |
|---|---|---|
| Alkalmazásfájlok | webgyökér, feltöltések, témák, bővítmények | a feltöltések gyakran változnak |
| Adatbázisok | MySQL/MariaDB, PostgreSQL | konzisztensen mentse, ne csak fájlokat másoljon |
| Konfiguráció | webszerver, PHP-FPM-poolok, php.ini, cron-feladatok | a gyors újraépítéshez szükséges |
| Tanúsítványok és kulcsok | TLS-tanúsítványok, alkalmazáskulcsok | titkosítva és elkülönítve tárolja |
| Dokumentáció | hozzáférések, függőségek, a visszaállítás menete | nélküle minden újraépítés tovább tart |

## Példa: adatbázis és fájlok mentése

A következő példa egy napi mentés alapelemeit mutatja. A gyakorlatban egy titkosítással, deduplikálással és megőrzési szabályokkal rendelkező mentőeszköz végzi a házon kívüli átvitelt.

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

# Az adatbázis konzisztens mentése; hozzáférési adatok védett fájlból, nem a parancsban
mysqldump --defaults-extra-file=/root/.backup-my.cnf \
  --single-transaction --routines --triggers shopdb | gzip > "$ZIEL/shopdb.sql.gz"

# Alkalmazásfájlok és konfiguráció
tar -czf "$ZIEL/webroot.tar.gz" -C /var/www shop
tar -czf "$ZIEL/config.tar.gz" /etc/nginx /etc/php /etc/cron.d

# Ellenőrző összegek a későbbi ellenőrzéshez
sha256sum "$ZIEL"/* > "$ZIEL/SHA256SUMS"
```

A `.backup-my.cnf` fájl egy csak olvasási joggal rendelkező adatbázis-felhasználó hozzáférési adatait tartalmazza, és `0600` jogokkal rendelkezik. A `--single-transaction` InnoDB-táblák esetén konzisztens állapotról gondoskodik a webshop leállítása nélkül.

Ezután egy külön rendszer viszi át a mentést házon kívülre. Fontos, hogy ezt a lépést felügyeljék: egy mentési feladat, amely napok óta csendben hibázik, különben csak éles helyzetben tűnik fel. Egy napi jelentés a sikerről, a méretről és az időtartamról elég, amíg valaki elolvassa, és utánajár az eltéréseknek.

Ha a tárhelyszolgáltatója mentéseit vagy pillanatképeit is használja, tisztázza írásban, meddig őrzik őket, vissza tud-e állítani maga, és megmaradnak-e a mentések egy felmondott vagy zárolt fiók esetén. Ezek a másolatok jó kiegészítések, de nem pótolnak egy saját, független mentést.

## Megőrzés: miért fontosak a régebbi állapotok a PHP2Shell után

Egy támadás után nem a legfrissebb mentés a legértékesebb, hanem a legfrissebb tiszta. A PHP2Shellnél médiabeszámolók szerint 2026. 10. 17-én megfigyeltek egy első támadási kísérletet, a javítások 2026. 10. 21-én jelentek meg. Aki csak hét napig őriz, annak esetleg már nincs olyan állapota, amely biztosan a lehetséges behatolás előtt van.

Egy bevált séma több időszakot kombinál, például napi mentéseket néhány hétig, heti mentéseket néhány hónapig és havi mentéseket egy évig. A pontos időszakok a védelmi igényétől és az adatvédelemből eredő törlési kötelezettségektől függnek.

Az is fontos: egy behatolás utáni időből származó mentés webshelleket vagy módosított fájlokat tartalmazhat. Egy incidens után soha ne töltsön vissza vakon, hanem vesse össze a fájlokat egy tiszta állapottal, és ellenőrizze őket, mielőtt a weboldal ismét online kerül. Támpontokat arra, mire figyeljen, a [A feltörés jelei](https://phpsos.de/hu/php2shell/bin-ich-gehackt-anzeichen/) oldalon talál. A javítás nem távolítja el a bejuttatott kártékony szoftvert, és a mentés sem teszi ezt meg magától.

## A visszaállítás tesztelése és dokumentálása

Egy teszt nélküli mentés feltételezés. Csak a visszaállítás mutatja meg, hogy minden rész megvan-e, működik-e a kulcs, és mennyi ideig tart ténylegesen a folyamat.

- Rendszeresen töltsön vissza egy teljes mentést egy tesztkörnyezetben, az adatbázissal és a konfigurációval együtt.
- Ellenőrizze, hogy a weboldal ezután teljesen működik-e: bejelentkezés, rendelések, űrlapok, levelek.
- Mérje az időtartamot, és jegyezze fel, mely lépések voltak kézi műveletek. Vesse össze az eredményt azzal az idővel, amelyet a vállalkozása legfeljebb weboldal nélkül kibír.
- A visszaállítás útmutatóját olyan helyen tárolja, ahol kiesett szerver esetén is elérhető, például az [IT-vészhelyzeti tervben](https://phpsos.de/hu/compliance/notfallplan-erstellen/).

## Hogyan segít konkrétan a PHP SOS?

- Ellenőrizzük a meglévő mentéseit teljesség, megőrzés, a szervertől való elkülönítés és a törlés elleni védelem szempontjából.
- Beállítunk egy módosíthatatlan másolatot tartalmazó 3-2-1 mentést, és Önnel együtt teszteljük a visszaállítást.
- Egy incidens után azonosítjuk az utolsó tiszta állapotot, és a [kártevő-eltávolítás](https://phpsos.de/hu/leistungen/malware-entfernung/) keretében visszaállítjuk egy javított rendszeren.
- A [biztonsági karbantartási szerződésben](https://phpsos.de/hu/leistungen/security-wartungsvertrag/) folyamatosan felügyeljük a mentéseket, és rendszeres visszaállítási teszteket végzünk.


## Gyakori kérdések

**Mit jelent a 3-2-1 szabály a mentéseknél?**  
Az adatairól három másolat, két különböző tárolótípuson, ebből egy másik helyen. A szabály gondoskodik arról, hogy sem egy hardverhiba, sem egy támadás, sem egy tűz ne érje egyszerre az összes másolatot.

**Elég a tárhelyszolgáltatóm mentése?**  
Jó kiegészítés, de ritkán elégséges. Tisztázza, meddig őrzi a szolgáltató az állapotokat, vissza tud-e állítani maga, és törölhetné-e egy támadó az ügyfélfiókjával a mentéseket. Egy saját, független másolat ajánlott.

**Egy feltörés után egyszerűen visszatölthetem az utolsó mentést?**  
Csak óvatosan. Az utolsó mentés már tartalmazhat kártékony kódot, és a rés, amelyen a támadó bejutott, utána még nyitva van. Először tisztázza és zárja le az okot, utána egy ellenőrzött állapotot töltsön vissza egy javított rendszerre.

**Milyen gyakran teszteljem a visszaállítást?**  
Rendszeresen és a rendszer nagyobb módosításai után. Egy rögzített ritmus, például negyedévente egy teljes visszaállítás egy tesztkörnyezetben, bevált. Fontos, hogy a tesztet dokumentálják, és a hiányosságokat kijavítsák.

## Források

- [BSI IT-Grundschutz (német Szövetségi Információbiztonsági Hivatal)](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)
- [BSI: adatmentés](https://www.bsi.bund.de/)
- [php.net: biztonsági közlemények a PHP2Shellről](https://www.php.net/)