SaaS mentés: amit a szolgáltatója már eldöntött Ön helyett

A SaaS mentés azt jelenti, hogy a felhős alkalmazásaiban tárolt adatairól visszaállítható másolatot tart a szolgáltató rendszerén kívül — a beépített lomtárakon, megőrzési szabályokon és exportgombokon túl. Azért van rá szükség, mert a szolgáltatóval kötött szerződése rendelkezésre állásról szól, nem adatvisszaállításról. A Microsoft saját szolgáltatási szerződése kifejezetten azt javasolja, hogy készítsen mentést arról, amit a szolgáltatásaiban tárol. A Google Workspace SLA-ja üzemidőt ígér és jóváírással kompenzál, a törölt adatok visszaszerzéséről viszont egy szót sem ejt. Az alábbiakban végigvesszük, pontosan hol van ez a rés, milyen határidőket döntött el Ön helyett a szolgáltató, és mitől lesz egy másolatból valódi mentés.

Mit jelent pontosan a SaaS mentés

Három feltétel, és mindhárom lényeges:

1. A másolat a szolgáltató hatókörén kívül létezik. Nem egy második régió ugyanazon a bérlőn belül, és nem egy hosszabbra állított érték ugyanazon az adaton — hanem olyan másolat, amely túléli annak a fióknak az elvesztését vagy kompromittálódását, amely az eredetit tárolja.
2. Ön választja meg a visszaállítási pontot. Nem az, amit a szolgáltató natív ablaka éppen megőrzött abban a pillanatban, amikor a hibát észrevette.
3. Egy részt vissza tud állítani az egész felülírása nélkül. Egy postafiókot, egy oldalfát, egy projektet — anélkül, hogy a körülötte lévő adatokhoz hozzányúlna.

Amit SaaS-környezetben mentésnek szoktak nevezni, jellemzően legalább az egyik feltételen elbukik. Többnyire a harmadikon.

A szerződés az üzemidőről szól, nem az adatairól

Ez az a rész, amely a legtöbb ügyfelünket meglepi, mert olyan dokumentumokban szerepel, amelyeket mindenki elfogad és senki nem olvas el.

A Microsoft szolgáltatási szerződése (2026. július 30-i kiadás) a Szolgáltatás rendelkezésre állása pontban így fogalmaz: minden online szolgáltatást érnek alkalmi fennakadások és kiesések, ezekért a Microsoft nem vállal felelősséget, kiesés esetén pedig előfordulhat, hogy nem fér hozzá a tárolt tartalmához és adataihoz — majd kimondja: „azt javasoljuk, hogy rendszeresen készítsen mentést” arról a tartalomról és adatról, amelyet a szolgáltatásokban tárol.

Ez a szolgáltatási szerződés, nem pedig a vállalati bérlőre vonatkozó kereskedelmi terméktételek szövege, és ezt a különbséget érdemes tudni, mielőtt idézi a szolgáltató felé. A szolgáltató álláspontja viszont így is le van írva: kiesések előfordulnak, az adatai elérhetetlenné válhatnak, a mentésük pedig az Ön feladata.

A Google Workspace SLA ugyanezt mondja a másik oldalról. Naptári hónaponként legalább 99,9%-os rendelkezésre állást vállal, és kifejezetten rögzíti, hogy ez a dokumentum tartalmazza az ügyfél „kizárólagos jogorvoslatát” arra az esetre, ha a Google nem teljesíti a vállalást — ez a jogorvoslat egy szolgáltatási jóváírás. A dokumentum arról szól, hogy a szolgáltatás elérhető-e. Semmilyen kötelezettséget nem vállal olyan adatok visszaállítására, amelyeket akkor töröltek, titkosítottak vagy írtak felül, amikor a szolgáltatás egyébként hibátlanul működött.

Mindkét szolgáltató korrekt: a saját platformjuk rendelkezésre állásáért és tartósságáért felelnek. Az Ön adatainak életciklusáért Ön. A teljes felelősségmegosztást a SaaS megosztott felelősségi modell bejegyzésünkben írtuk le, és az alábbi következmények mind ebből következnek.

Három dolog, amit tévesen mentésnek hisznek

A megőrzés és a jogi zárolás nem visszaállítás

A megőrzési szabály megakadályozza az adat eltávolítását. Arra viszont nem ad módot, hogy egy ismerten jó verziót visszategyen a helyére. A Google ezt a saját termékéről mondja ki: a Vault nem adatarchívum, exportálni tud, visszaállítani nem. A Microsoft megőrzési és eDiscovery megfelelői olyan állapotba őrzik meg az adatot, amelyből ezután keresni és kinyerni kell — ez egy jogi menetrend szerinti felderítési folyamat, nem egy üzemeltetési menetrend szerinti helyreállítás.

Ráadásul a megőrzés az élő bérlőn beállított érték, vagyis bárki lerövidítheti, akinek admin jogosultsága van — beleértve a támadót is, aki admin jogosultságot szerzett.

A szinkronizáció replikáció, és a kárt is átmásolja

A OneDrive saját felülete „fontos mappák biztonsági mentése” néven hivatkozik a mappaszinkronra. Ez nem mentés, hanem gyors és hűséges replikáció. Amikor egy zsarolóvírus titkosít egy szinkronizált mappát, a szinkronkliens pontosan azt teszi, amire tervezték: felviszi a titkosított verziókat a felhőbe. Ugyanez igaz a Drive asztali kliensére. A teljes csapdát — beleértve azt a licencfeltételt is, amely minden megőrzési beállítást felülír — a OneDrive biztonsági mentés bejegyzésben jártuk körbe.

Egy zsarolóvírus-incidens során a titkosítás jellemzően hitelesítetten érkezik: egy szinkronkliensen vagy egy API-tokenen keresztül, amelynek amúgy is ott a helye. A replikáció ezt nem tudja megkülönböztetni a rendes munkától.

Az export egy fájl, nem visszaállítási útvonal

Ez a legsúlyosabb következményű tévhit, és az Atlassian dokumentációja mondja ki a legnyíltabban minden szolgáltató közül.

Egy teljes Jira Cloud webhelyet lehet exportálni. Az Atlassian viszont dokumentálja, hogy az export visszaimportálása törli a meglévő adatokat, és a mentésből származó adatokra cseréli őket — továbbá kimondja, hogy ezzel az eljárással nem lehet egyetlen konkrét projektet importálni úgy, hogy a webhely meglévő adatai megmaradjanak. A fájl tehát létezik, de az egyetlen dokumentált felhasználási módja mindent megsemmisít, ami a mentés készítése óta keletkezett. 2026. január 22-től az Atlassian a Backup Managerből indított visszaállításokat a legfeljebb 30 napos mentésekre korlátozza, és ha csatolmányokat, avatarokat vagy logókat is belevesz, két mentés között 48 órát kell várnia.

A minta minden platformon ismétlődik. Egy Slack-export fájlhivatkozásokat ad át, nem fájlokat. A Google adatexportáló eszközénél várni kell, a törölt adatokat nem tartalmazza, az archívum lejár, és visszaállítási útvonal egyáltalán nincs hozzá — ez egy a négy útvonalból, amelyeket a Google Workspace mentés készítése bejegyzésben vettünk végig, és amelyek közül pontosan egy minősül mentésnek. A Confluence Backup Managere egyetlen másolatot tárol, amelynek a letöltési linkje lejár, a visszaállítása pedig felülírja a célwebhelyet.

Az export arra válaszol: „meg tudom kapni ennek a másolatát?” A mentés arra: „vissza tudom ezt tenni?” Ez két különböző kérdés, és a szolgáltatók többnyire csak az elsőre építettek megoldást.

A visszaállítási határidők, amelyeket már eldöntöttek Ön helyett

Ha csak a szolgáltató másolatai vannak a birtokában, akkor a visszaállítási pont célértékét (RPO) nem Ön választotta ki. Az lesz, amennyi az egyes natív ablakok hossza — munkaterhelésenként más szám, egyiket sem Ön határozta meg, és többet közülük lerövidít egy hétköznapi felhasználói művelet, például a lomtár kiürítése vagy a licenc visszavonása a kilépéskor.

Munkaterhelés	Dokumentált natív határ	Mi rövidíti le
Exchange Online	14 nap alapértelmezett elemmegőrzés, legfeljebb 30-ra emelhető; 30 nap a törölt postafiókra	Kilépő munkatárs; érintetlenül hagyott alapérték
OneDrive / SharePoint	93 nap a két lomtárszakaszra együttvéve, az eredeti törléstől számítva	Az első szakasz kiürítése; a licenc elvesztése
Microsoft Teams	kb. 30 nap egy törölt csapatra vagy csatornára; csevegőüzenetekre nincs önkiszolgáló visszaállítás	Archiválás helyett törlés
Gmail	30 napos lomtár és további 25 napos admin ablak, a törlés dátumához kötve	Alig — a két ablak összeadódik
Google Drive	30 napos lomtár és további 25 napos admin ablak, a lomtár kiürítéséhez kötve	A lomtár korai kiürítése
Slack	a törlés végleges, lomtár nincs	Egy megőrzési beállítás, amit a törlés előtt választottak
Jira	60 nap egy lomtárba helyezett projektre; egyesével törölt jegyekre nincs dokumentált lomtár	Semmi — a padló már eleve nulla
Confluence	törölt oldalakra nincs meghirdetett lejárat; törölt térre kemény 60 nap	Ha egy admin véglegesen kiüríti a tér lomtárát
Bitbucket	admin által indítható mentés nincs; a helyreállítás helyi klónból való újraépítés	Ha nincs naprakész klónja

Mindegyiket a szolgáltató dokumentálja, és mindegyiket részletesen tárgyalja az a bejegyzés, amelyre hivatkozik: Microsoft 365 mentés, Google Workspace, Slack megőrzés és Atlassian Cloud.

Egyben nézve a táblázat kényelmetlen olvasat: a leghosszabb határ 93 nap, a többség két és nyolc hét között van, egy pedig nulla. A támadói bennmaradási idő ugyanezen a léptéken mozog. Egy türelmes behatolónak nem kell legyőznie ezeket az ablakokat — elég kivárnia őket.

Mitől lesz egy másolatból mentés

Ezt az ellenőrzőlistát használjuk, amikor egy csapattal együtt vizsgáljuk meg, hogy amijük van, az mentés-e vagy irattár:

• Független a bérlőtől. Az admin fiók kompromittálódása ne érintse a másolatokat.
• Emlékeztető nélkül fut. Folyamatos vagy ütemezett mentés, nem egy gomb, amit valaki megnyom, ha eszébe jut.
• Részlegesen is visszaállít. Egy elem, egy projekt, egy postafiók — a szomszédai felülírása nélkül, vagyis pontosan az, amit a fenti Jira-importálás nem enged meg.
• Az Ön által választott időpontra állít vissza, nem arra a pillanatfelvételre, amelyik éppen fennmaradt.
• Lefedi a ténylegesen használt munkaterheléseket, azokat is, amelyeket a szolgáltatók kihagynak a saját beépített eszközeikből.
• Jelzi az anomáliákat — egy tömeges törlés vagy titkosítás akkor legyen látható, amikor történik, ne akkor, amikor a natív ablakok már bezárultak.
• Bizonyítékot állít elő. Visszaállítási naplókat és tesztjegyzőkönyveket, mert a NIS2, a GDPR, az ISO 27001 és a kibervédelmi biztosítói kérdőívek azt kérik, hogy a helyreállítást bizonyítsa, ne csak állítsa.
• Tesztelték. Egy nem tesztelt mentés csak feltételezés. Ennek a gondolatmenetnek a folytatása a SaaS katasztrófa-helyreállítási terv bejegyzésünkben olvasható.

Semmilyen mentés nem előzi meg a zsarolóvírus-támadást. Egy független, tesztelt másolat a kimenetelt változtatja meg: az incidensből ismert visszaállítási ponttal rendelkező helyreállítás lesz alkudozás helyett, és arról, hogy mit veszített el, többé nem egy lomtár időzítője dönt Ön helyett.

Hogyan derül ki, mire van szüksége

A helyes válasz attól függ, mely munkaterhelések hordozzák az üzemeltetési kockázatát, mit kell bizonyítania a hatóság és a biztosítója felé, és a jelenlegi felállásból mi végzi el ténylegesen azt a munkát, amiről Ön azt hiszi, hogy elvégzi. Ez beszélgetés kérdése, nem egy weboldalé.

Segítünk kiválasztani és bevezetni a szervezetéhez illeszkedő megoldást Microsoft 365, Google Workspace, Slack és Atlassian Cloud környezetben — és végigkísérjük a beállításon és a bevezetésen, hogy valóban működjön, ne csak félig konfigurálva álljon. Az eredményt Ön birtokolja és üzemelteti.

Ha szeretné pontosan látni, hol áll most a kitettsége, kérjen felmérést. Ez egy rövid, strukturált áttekintés arról, mely munkaterheléseihez van ma valódi visszaállítási útvonala, és melyek támaszkodnak olyan időablakra, amelyet más választott ki.