Atlassian Cloud mentés: mit ment tényleg a Jira és a Confluence (és mit nem)

Ha az Atlassian Cloud mentés kifejezésre keresett, feltehetően már sejti, hogy a beépített lomtár önmagában nem elég. Igaza van — és az okok konkrétak, nem általános ijesztgetés. Ez a bejegyzés végigmegy azon, mit ment a Jira Cloud és a Confluence Cloud natívan, hol ér véget ez a védelem, és mit tesz hozzá egy független mentési megoldás.

Amit az Atlassian valójában ad

Az Atlassian saját adminisztrátori dokumentációja is nyíltan beszél erről, és ez két mechanizmusra bontható:

1. A lomtár — ami nem egy ablak, hanem több. Az Atlassian lomtárszabályai termékenként és a törölt elem típusa szerint eltérnek. Egy törölt Jira-projekt a jegyeivel, komponenseivel, csatolmányaival és verzióival együtt 60 napig marad meg a végleges törlés előtt, és Jira- vagy webhely-adminisztrátor állíthatja vissza (tér-adminisztrátor csak a csapat által kezelt projekteket helyezheti lomtárba és állíthatja vissza). Egy törölt Confluence-tér szintén 60 napot kap — ezt az automatikus tisztítást az Atlassian 2025. január 6-tól érvényesíti. A törölt Confluence-oldalak viszont ismét másképp viselkednek: meghirdetett lejárat nélkül maradnak a tér lomtárában, és addig állíthatók vissza, amíg egy tér-adminisztrátor véglegesen nem törli őket. Az Atlassian projekt-lomtárról szóló dokumentációja pedig nem terjeszti ki ezt a védőhálót az egyesével törölt Jira-jegyekre — és ahogy a következő szakasz mutatja, ez nem figyelmetlenség, hanem dokumentált hiány. A gyakorlati tanulság: a „majd a lomtárban megvan” nem egyetlen, megbízható szabály — a részletekért lásd, mit őriz meg valójában egy Confluence mentés.

2. Kézi mentés a Backup Manageren keresztül. A Jira és a Confluence Cloud admin felületén is található egy Backup Manager, amellyel egy admin egy teljes webhely-exportot indíthat el, ami egy tömörített XML fájlba kerül a folyamat végén. Ez valós funkció, de kézi, korlátozott gyakoriságú és lejárattal bír: ha csatolmányokat, avatarokat vagy logókat is belevesz, két mentés között 48 órát kell várnia, 2026. január 22-től pedig az Atlassian a Backup Managerből indított visszaállításokat a legfeljebb 30 napos mentésekre korlátozza. Egy tavasszal készített mentés ősszel már nem visszaállítási lehetőség.

A harmadik Atlassian-termék, amelyről a legtöbb kérdést kapjuk, a Bitbucket Cloud, ahol adminisztrátor által indítható teljes mentési funkció egyáltalán nincs. Az Atlassian dokumentált helyreállítási eljárása szó szerint az, hogy a repository-t egy helyi klónból építse újra — ez a commitokat és a branch-eket hozza vissza, a köréjük épült pull request-előzményt nem.

Jira mentés: az export nem visszaállítási útvonal

Ez külön szakaszt érdemel, mert a Jira esetében a legnagyobb a szakadék a „van mentésünk” és a „vissza tudjuk állítani” között — és mert az Atlassian ezt nyíltabban dokumentálja, mint a legtöbb szolgáltató.

Az egyesével törölt jegyekhez nincs lomtár. Az Atlassian saját tudásbázisa szerint „folyamatban lévő fejlesztési igény” egy lomtárszerű komponens bevezetése (JRACLOUD-36415) — vagyis ma nem létezik. A 60 napos lomtár a törölt projektre vonatkozik, nem arra a jegyre, amelyet valaki kitörölt belőle.

És egy webhelyszintű mentés sem adja vissza azt a jegyet. Az Atlassian egyértelműen kimondja, hogy az Atlassian-mentésekkel nem lehet egyesével törölt jegyeket visszaállítani. A dokumentált kerülőút az, hogy az XML-mentést egy különálló webhelyre állítja vissza, onnan exportálja a jegyet, majd CSV-ként importálja vissza — ekkor viszont a jegy már más azonosítóval jön létre, és minden hivatkozás, tábla és automatizáció, amely a régi kulcsra mutatott, a semmibe mutat. Ha nincs mentés, az Atlassian javaslata az, hogy a jegyet kézzel építse újra azokból az e-mail-értesítésekből, amelyeket a megfigyelői, a felelőse és a bejelentője kaptak.

Egyetlen projekt visszaállítása sem támogatott. Az Atlassian megfogalmazása egyértelmű: ezzel az eljárással nem lehet egy konkrét projektet importálni úgy, hogy a webhely meglévő adatai megmaradjanak. Egy webhelyszintű mentés importálása törli a meglévő adatokat, és a mentésből származó adatokra cseréli őket. A gondosan előállított fájlnak tehát az egyetlen dokumentált felhasználása az, hogy a teljes webhelyet visszagörgeti — megsemmisítve mindent, amit az összes többi csapat az export óta létrehozott. Egyetlen törölt projekt miatt ez rosszabb a betegségnél, és a legtöbb admin joggal utasítja el.

A Jira egyes részei egyáltalán nincsenek benne az exportban. Az Atlassian exportdokumentációja felsorolja, mit hagy ki egy webhelyszintű mentés, és a lista hosszabb a vártnál: az automatizálási folyamatok, a külső alkalmazások és azok adatai, az alkalmazás-hozzáférési beállítások, a Jira Service Management Assets modulja, az Opsgenie funkciói, valamint a Jira Product Discovery konfigurációi. Ha a szállítási folyamata egy marketplace-alkalmazásra épül — márpedig a legtöbbé arra épül —, annak az alkalmazásnak az adata nincs a fájlban.

Összegezve: a natív Jira mentés egy webhelyszintű, korlátozott gyakoriságú, 30 nap után lejáró, mindent-vagy-semmit pillanatfelvétel, amely kihagyja az alkalmazásadatokat, és nem tud visszaadni sem egyetlen jegyet, sem egyetlen projektet. Ez egy teljes adatvesztésre szánt katasztrófa-helyreállítási melléktermék, nem helyreállítási eszköz azokra a helyzetekre, amelyek ténylegesen elő szoktak fordulni.

Hol ér véget a natív eszközök hatóköre

Zsarolóvírus és lappangó támadások. Egy támadó, aki hozzáfér egy Atlassian admin fiókhoz, nem az infrastruktúrához kell hogy hozzáférjen — a terméken belülről tömegesen törölhet vagy szerkeszthet projekteket és tereket. Ha ez az aktivitás túléli a 60 napos projekt- és térszintű ablakokat (és a türelmes támadók pontosan erre számítanak), a lomtár már kiürült, mire bárki észreveszi. A Backup Manager fájljaira vonatkozó 30 napos visszaállítási korlát ugyanezt az ablakot szűkíti tovább.

Rosszul beállított automatizáció. Egy hibás Jira-automatizálási szabály percek alatt ezreket írhat át — egyéni mezőket, státuszokat, felelősöket. Minden változtatást egy jogosult fiók hajt végre, „legitim” módon. A lomtár csak a törléseket fogja meg, a mezőszintű felülírásokat egyáltalán nem. Egy rossz Confluence-makró vagy egy tér szintű keresés-csere ugyanebbe a vakfoltba esik.

Távozó adminok. Egy Jira- vagy Confluence-admin leépítésekor a hozzá tartozó projektek és terek nem tűnnek el azonnal — de a fiókhoz kötött automatizációk, irányítópultok és jogosultsági sémák igen, és utólag rekonstruálni, hogy kinek mihez volt hozzáférése, pontosan az a fajta munka, amit egy időpont-alapú mentés triviálissá, a lomtár pedig lehetetlenné tesz.

Részletes, tesztelt visszaállítás. Ahogy a fenti szakasz kifejti, a Backup Manager exportja tervezésénél fogva minden-vagy-semmi jellegű. Nincs mód egyetlen projekt, egyetlen tér vagy egyetlen jegy előzményének visszaállítására ebből a fájlból jelentős kézi munka és egy második webhely nélkül. Ha egy ügyfélnek csak egy Confluence-oldalfára van szüksége, nem a teljes Confluence-példányra, a natív eszközöket nem erre tervezték.

Megfelelőségi bizonyíték. A NIS2 és a hasonló szabályozások bizonyítható, tesztelhető helyreállítási képességet várnak el — nem azt, hogy „valószínűleg exportálni tudnánk, ha kérnék”. Egy alkalmi, kézi XML-mentés egy admin letöltési mappájában nem auditálható mentési folyamat.

Hogyan néz ez ki a gyakorlatban

Egy közepes méretű fejlesztői szervezetnél — 40 Jira-projekt, csapatonként egy Confluence-tér, Bitbucket a forráskódhoz — egy automatizálási szkript, amelynek egy projektben kellett volna lezárnia az elavult jegyeket, egy túl tág JQL-szűrő miatt 12 projektben 6000 jegyet állított „Kész” állapotba egyetlen éjszaka alatt. Minden állapotváltás jogosult, hitelesített művelet volt — a lomtárnak nem volt mit megfognia, hiszen semmit nem töröltek. A helyes állapot visszaállítása kézi újranyitást és néhány e-mail-értesítés alapján történő rekonstrukciót jelentett. Egy független mentés időpont-alapú, mezőszintű visszaállítással ebből egy tízperces visszagörgetést csinál egy kétnapos nyomozás helyett.

Mit kell nyújtania egy független Atlassian Cloud mentésnek

Ugyanaz a minta érvényes, mint amit a SaaS megosztott felelősségi modell bejegyzésünkben leírtunk: az Atlassian felel azért, hogy a platform üzemben maradjon, és az adatai túléljék az ő hardverhibáikat. Minden más — hogy az adatai meddig állíthatók vissza, milyen részletességgel, és hogyan bizonyítja ezt egy auditornak — Önön múlik. Ugyanez a felelősségmegosztás áll minden általunk lefedett platform mögött, ezért a SaaS mentés általános kritériumai itt is érvényesek.

Egy független Atlassian Cloud mentésnek ezt kell nyújtania:

• Folyamatos, inkrementális mentés a Jira-jegyekről, Confluence-oldalakról és Bitbucket-repókról — nem egy kézi export, amit valakinek egy 48 órás korláton belül el kell indítania
• Visszaállítás bármely időpontra, nem csak arra, amit az utolsó export a 30 napos visszaállítási ablakán belül véletlenül elkapott
• Projekt- és térszintű granularitás — egy projekt vagy egy oldalfa visszaállítása anélkül, hogy a többihez hozzányúlna, vagyis pontosan az, amire a natív importálás nem képes
• Zsarolóvírus-anomália-észlelés, hogy egy tömeges törlés vagy szerkesztés a történés pillanatában jelezzen, ne akkor, amikor a lomtár ablakai már bezárultak
• Audit-szintű helyreállítási naplók a NIS2, ISO 27001 és GDPR megfelelőséghez

Segítünk kiválasztani és bevezetni ezt a réteget — Ön birtokolja és irányítja a platformot, mi pedig végigkísérjük a beállításon és bevezetésen, hogy valóban működjön, ne csak félig konfigurálva álljon. A teljes, munkaterületenkénti áttekintésért lásd az Atlassian Cloud mentés és helyreállítás oldalunkat.

Ha nem biztos benne, hogy jelenlegi Atlassian-beállítása túlélne-e egy tömeges törlési incidenst vagy egy olyan zsarolóvírus-támadást, amely kivárja a lomtár ürülését, pontosan erre való egy felmérés — egy rövid, nyomásmentes áttekintés a jelenlegi kitettségéről és arról, mit zárna le egy megfelelő mentés.