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. 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, ezért nem biztonságos feltételezni, hogy létezik. 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: senki nem futtatja rendszeresen, nem emlékszik ütemezetten elindítani, és nem ellenőrzi, hogy a kapott fájl valóban visszaállítható-e — egészen addig, amíg szükség nem lesz rá, és akkor derül ki, hogy mégsem.

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.

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.

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. A Backup Manager exportja minden-vagy-semmi jellegű: a teljes webhely egyetlen fájlként, amelyet a legtöbb esetben csak az Atlassian ügyfélszolgálatához benyújtott jegy útján lehet visszaimportálni. 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 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.

Mi tölti be a rést

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.

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 el kell indítania
• Visszaállítás bármely időpontra, nem csak arra, amit az utolsó export 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
• 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.