Mentés, amelyet tényleg használsz
A cégek többsége csak a katasztrófa pillanatában jön rá, hogy a mentése nem működik. Ezért azt javasoljuk, hogy a mentésre folyamatként tekints, ne pipálható négyzetként: automatikus másolatok, az éles szervertől távol tárolva, rendszeresen tesztelt visszaállítással. cPanelen a napi mentés automatikusan fut, és a panelből állítod vissza; VPS-en és dedikált szervereken a DevOps-csapat a benne foglalt órákból ütemezett visszaállítási teszteket állíthat be.
Melyik csomag milyen mentést tartalmaz
A cPanel hosting automatikus napi mentéssel rendelkezik, amelyet a panelből állítasz vissza. A VPS-hez snapshotok tartoznak – a szerver állapotának teljes másolatai – garantált gyakoriság nélkül. A dedikált szerverek alapból nem tartalmaznak mentést: az NVMe lemezek párban érkeznek, a RAID a telepítéskor kerül beállításra, de a RAID nem mentés. A külső mentést, az adatbázisok PITR-jét és a visszaállítási teszteket csapatunk állítja be a benne foglalt DevOps-órákból (dedikáltnál 5–10 óra/hó).
| Csomag | Mentés | Visszaállítás | Helyszín |
|---|---|---|---|
| cPanel hosting | Automatikus napi mentés | Az ügyfélpanelből | EU (Frankfurt) |
| VPS | Snapshotok, garantált gyakoriság nélkül | Snapshotból | EU (Frankfurt) |
| VPS – külső mentés | Kérésre, a DevOps-órákból | A beállított stratégia szerint | A csapattal egyeztetve |
| Dedikált szerver | Alapból nem tartalmazza – kérésre beállítjuk | A stratégia szerint (3-2-1, PITR) | EU (Frankfurt) + kérésre külső tárhely |
RPO és RTO – a számok, amelyeket neked kell meghatároznod
A „minél előbb mentés” helyett érdemes két konkrét értéket rögzíteni. Az RPO (Recovery Point Objective) megmondja, mennyi adatot engedhetsz meg magadnak elveszíteni. Az RTO (Recovery Time Objective) megmondja, meddig tarthat egy visszaállítás. A csapat ezekre az értékekre építi a stratégiát.
A maximális adatvesztés, amelyet elfogadsz. Napi mentésnél akár egy nap is elveszhet; WAL streaminggel egy adatbázis egy perc alá kerül – kérésre beállítjuk.
A visszaállítás ideje az adatmennyiségtől és a választott stratégiától függ. RTO-t nem garantálunk – az egyetlen megbízható érték az, amelyet egy visszaállítási teszten mértünk.
Katasztrófahelyzetek – és hogyan védekezz ellenük
A katasztrófák ritkák, de nagy hatásúak. Íme a leggyakoribb forgatókönyvek és az ellenük ajánlott védelem. VPS-en és dedikált szervereken ezeket az intézkedéseket a csapat a benne foglalt DevOps-órákból állítja be.
Hardverhiba (lemez, RAM)
Az adatvesztés leggyakoribb oka. A dedikált szervereken párosított NVMe lemezek vannak, telepítéskor beállított RAID-del, az EPYC és Xeon szinteken pedig ECC RAM-mal. A RAID lemezhiba esetén is működésben tartja a szervert, de nem helyettesíti a mentést – külső másolatra továbbra is szükség van.
Védelem: RAID + külső mentésZsarolóvírus vagy fiókfeltörés
A támadó titkosítja a szerver fájljait – és minden másolatot, amelyet a szerver elér. Ezért legalább egy másolatnak a szerveren kívül kell lennie, ahol az éles fiók nem módosíthatja (módosíthatatlan vagy offline). Kérésre beállítjuk, a DevOps-órákból.
Védelem: elszigetelt másolatVéletlen adattörlés
„DROP TABLE users” az éles rendszeren. A leggyakoribb emberi hiba. Ha az adatbázison be van állítva az időponthoz kötött helyreállítás (PITR), közvetlenül a hiba elé léphetsz vissza; a napi mentés csak az utolsó másolatig visz vissza.
Védelem: PITR kérésreTeljes adatközpont-kiesés
Tűz, árvíz, elhúzódó üzemeltetői leállás. A védelem egy másik helyszínen tárolt másolat, például egy második adatközpontban. A replikáció és a feladatátvétel alapból nem tartozik a csomaghoz; a csapat kérésre beállítja, a DevOps-órákból.
Védelem: másolat másik helyszínenAz alkalmazás hibája adatokat rongál
Egy telepítés hibát visz be, amely megrongálja az adatbázis rekordjait. Különálló adatbázis-mentéssel csak az adatbázist állítod vissza (nem az egész szervert) – az alkalmazásfájlok maradnak, az adatok visszagörgetődnek.
Védelem: különálló adatbázis-mentésKöltözés másik szerverre
Kinövöd a jelenlegi csomagot. A VPS magasabb szintre léphet több vCPU-val, RAM-mal és lemezzel; másik szerverre költözéshez előre megtervezzük a migrációt, hogy rövid maradjon az állásidő.
Tipp: tervezd meg korán a migrációtAdatbázis-mentés – stratégiák motoronként
A teljes VPS-mentés nem mindig elég. Az adatbázisoknak saját, időponthoz kötött helyreállítási (PITR) mechanizmusaik vannak – ezekkel pontosan a kiválasztott pillanatra léphetsz vissza, nem csak az utolsó snapshotra. Ezeket kérésre állítjuk be, a benne foglalt DevOps-órákból.
Mi van benne – és mit állítunk be kérésre
Nincs külön eladott „prémium mentés”: ami benne van, azt minden csomagnál feltüntetjük, minden mást pedig a csapat az előfizetésedben lévő DevOps-órákból épít meg. A keret feletti órákat külön, óradíjjal számlázzuk.
- cPanel: automatikus napi mentés, visszaállítás a panelből – benne van
- VPS: snapshotok, garantált gyakoriság nélkül – benne van
- Dedikált szerverek: párosított NVMe lemezek, telepítéskor beállított RAID – a mentés alapból nincs benne
- Külső mentés a 3-2-1 szabály szerint – kérésre, a DevOps-órákból (dedikáltnál 5–10 óra/hó)
- Adatbázisok PITR-je (WAL, binlog, oplog) – kérésre, a DevOps-órákból
- Visszaállítási tesztek és megőrzési idő – a csapattal egyeztetve, a DevOps-órákból beállítva
Mentés visszaállítása – 4 lépésben
Nyisd meg a panelt
Jelentkezz be az ügyfélpanelbe. cPanelen itt állítod vissza a napi mentést; VPS-en itt választasz snapshotot.
Válassz időpontot
Válaszd a probléma előtti másolatot. A legfrissebb nem mindig a megfelelő, ha a hiba már egy ideje fennáll.
Kattints a „Visszaállítás” gombra
A visszaállítás felülírja a jelenlegi állapotot. Ha bizonytalan vagy, kérd meg a csapatot, hogy előbb egy külön környezetbe állítsa vissza, hogy összehasonlíthasd.
Ellenőrizd az eredményt
Nézd meg, hogy fut-e az alkalmazás, és az adatok ott vannak-e, ahol lenniük kell. A visszaállítás időtartama az adatmennyiségtől függ.
Gyakran ismételt kérdések
Le kell állítani a szervert a snapshothoz?
Általában nem: a VPS-snapshot futó szerveren készül. Adatbázisnál viszont egy futó szerver snapshotja nem mindig konzisztens, ezért külön adatbázis-mentést (dump vagy WAL/binlog) javaslunk, amelyet a csapat kérésre beállít.
Mennyi ideig tart egy nagyon nagy snapshot (pl. 500 GB) visszaállítása?
Az adatmennyiségtől, a lemeztől és a másolat tárolási helyétől függ – külső másolatból a visszaállítás tovább tart, mint helyiből. Nem ígérünk fix időt: a reális érték egy visszaállítási tesztből jön, amelyet veled együtt lefuttathatunk.
Titkosítottak a mentések?
A külső mentések titkosítása része annak a stratégiának, amelyet kérésre beállítunk – például olyan másolatok, amelyek csak titkosított formában hagyják el a szervert, a kulcsokat pedig az éles rendszertől elkülönítve tartják. A beállítás kérésekor jelezd a csapatnak az igényeidet.
Mi van, ha 30 napnál hosszabb megőrzést szeretnék?
A külső mentések megőrzési idejét a csapat a stratégia beállításakor határozza meg, az igényeid és a jogi archiválási kötelezettségeid alapján. A hosszabb megőrzéshez szükséges tárhelyet a csapattal egyeztetjük; a csomagokat az árak oldalán találod.
Letölthetek egy snapshotot helyben?
VPS-en és dedikált szervereken root hozzáférésed van, és a számodra kedves eszközökkel (rsync, tar) másolod az adataidat. A csapat a DevOps-órákból automatizált másolatokat is beállíthat külső tárhelyre, például AWS S3-ra, Google Cloud Storage-ra vagy Azure Blobra.
Az adataid túl értékesek ahhoz, hogy a szerencsére bízd őket
A cPanel napi mentést tartalmaz, a VPS pedig snapshotokat. Dedikált szervereken a csapat a benne foglalt DevOps-órákból építi meg a mentési stratégiát. A részletekért nézd meg az árakat.
Csomagok megtekintése →Útmutatók magyarországi cégeknek
- Mi a NIS2 a tárhelyszolgáltatásban? Mit jelent a 2024. évi LXIX. törvény a tárhelyet bérlő cégeknek?
- cPanel tárhely Magyarországra: mire figyelj, ha külföldi (EU) adatközpontban lévő tárhelyet választasz?
- Hol tárhelyezz egy React alkalmazást olcsón? VPS vagy cPanel Node.js nélkül?
- GDPR és Infotv. tárhelyen: adatfeldolgozói szerződés (DPA, 28. cikk) és a NAIH elvárásai