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.
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.
#!/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 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.
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 keretében visszaállítjuk egy javított rendszeren.
- A biztonsági karbantartási szerződésben 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.