SharePoint verziótörténet: meddig nyúlik vissza valójában

A SharePoint verziótörténet a fájlok korábbi változatait őrzi meg, hogy meg lehessen nézni, össze lehessen hasonlítani vagy vissza lehessen állítani őket — a Microsoft pedig a SharePoint és a OneDrive beépített adatvédelmi képességeinek szerves részeként pozicionálja, amely alkalmas a véletlen módosítások és a "rosszindulatú tevékenységek, például zsarolóvírusok" okozta változások visszavonására. Hogy meddig nyúlik vissza, arra nincs fix szám: egy verziókorláttól függ, amelyet szervezeti, webhely-, tár- vagy egyéni OneDrive szinten is be lehet állítani. Két dokumentált viselkedés dönti el, hogy tényleg megmenti-e Önt: a korlát túllépése miatt eltávolított verziók megkerülik a lomtárat, a mappáknak pedig egyáltalán nincs verziótörténetük.

Hol találja, és mit csinál a visszaállítás

Bármely SharePoint-dokumentumtárban vagy OneDrive-on tárolt fájlnál a Verzióelőzmények menüpont megjelenik a jobb gombos menüben és a fájl részletező paneljén is. Minden verziót felsorol a módosítás dátumával és a módosítást végző felhasználóval. Innen a következőket teheti:

• Megtekintés: egy korábbi verzió megnyitása anélkül, hogy a jelenlegit felülírná. Word- és Excel-fájloknál a verziók össze is hasonlíthatók.
• Visszaállítás: egy korábbi verzió a jelenlegi helyére lép. Fontos részlet, hogy a visszaállított verzió lesz az új aktuális verzió — a közbeeső verziók nem törlődnek, vagyis a visszaállítás előrelépés, nem kitörlés.
• Nyomon követés: ki, mit és mikor módosított. Ez inkább auditálási, mint helyreállítási felhasználás.

Az utolsó előtti pont többet nyom a latban, mint amennyinek hangzik. Mivel a visszaállítás új verziót hoz létre, nem pedig eltávolít, maga a visszaállítás is elhasznál egy verzióhelyet — ez pedig azonnal jelentőséget kap, amint közel kerül a korláthoz.

Meddig nyúlik vissza valójában

A verziókorlátok négy szinten állíthatók — szervezet, webhely, dokumentumtár és egyéni OneDrive-fiók —, és a szűkebb szint felülírhatja a tágabbat. Egy webhelytulajdonos felülbírálhatja a szervezeti alapértelmezést a saját webhelyén, egy dokumentumtár pedig a webhelyét. Ebből következik, hogy a "hány verziót őrzünk meg?" kérdésre az őszinte válasz úgy kezdődik: attól függ, melyik tárról beszélünk — és ezt érdemes ellenőrizni, nem feltételezni.

A Microsoft két beállítást kínál:

Automatikus. A Microsoft által ajánlott lehetőség, amely a verziótárolást magától kezeli, ahelyett hogy a rendszergazdának kellene darabszámot megtippelnie. Ha ez a szervezeti alapértelmezés, az új tárak ezt kapják.

Manuális. A főverziók konkrét darabszáma, opcionálisan lejárati idővel párosítva. A Microsoft dokumentációja saját példaként azt a tárat hozza, amely 500 főverziót tárol 365 napos lejárattal: legfeljebb 500 verzió marad meg, és minden egy évnél régebbi verzió automatikusan törlődik. Beállítható darabszám lejárat nélkül is.

Van egy küszöb, amelyről érdemes tudni. Az adminisztrációs felület nem fogad el 100 főverziónál kevesebbet vagy 30 napnál rövidebb lejáratot, a nyilvános API-k viszont igen — és a Microsoft világosan figyelmeztet, hogy ennél szigorúbb érték nem javasolt, mert "a felhasználói tevékenység nem szándékolt adatvesztést okozhat". Ha valaki egyszer tárhely-felszabadítás céljából szkriptből állított be szűkebb korlátot, az a beállítás ma is érvényben van, és a felületen már semmi nem jelzi rendellenesnek.

A mappáknak nincs verziótörténetük

Ez a leggyakoribb meglepetés, és nem hiba, nem is licenckérdés: a SharePointban a verziókövetés fájlokra és listaelemekre vonatkozik, mappákra nem. Egy mappa helyi menüjében nincs Verzióelőzmények pont, mert nincs is mit verziózni — a mappának nincs saját tartalma, csak a benne lévő elemek.

A gyakorlati következmények a fájdalmasak:

• Ha valaki átnevez vagy áthelyez egy mappát, nincs olyan mappaverzió, amelyre vissza lehetne állni. Marad a lomtár vagy a kézi újraépítés.
• Ha egy mappa szerkezetét átrendezik — ötven fájl kerül szét új almappákba —, minden fájl megőrzi a saját verziótörténetét, de magát az elrendezést sehol nem rögzítette a rendszer.
• A fájlok visszaállítása nem állítja vissza a struktúrát. A verziótörténet tervezetten elemenkénti, így minden fájl tartalmát vissza tudja adni — a körülöttük lévő rendszerezésből semmit.

Mappaszintű kár esetén nem a verziótörténet segít, hanem a 93 napos lomtár és a 30 napos OneDrive-visszaállítás.

A korlát miatt törölt verziók nem kerülnek a lomtárba

Ez az a viselkedés, amely a legnagyobb eséllyel lepi meg azt, aki a lomtárat végső védőhálónak hiszi. A Microsoft három különböző sorsot dokumentál a törölt verziókra, és ezek közül csak egy visszanyerhető:

Hogyan törlődött a verzió	Hová kerül
A felhasználó törli a fájl verziótörténetéből	A webhely lomtárába, egy ideig visszaállítható
Túllépi a dokumentumtár verziókorlátját	Végleges törlésre jelölve — megkerüli a lomtárat
A rendszergazda ütemezett feladattal nyesi a meglévő verziókat	Véglegesen törlődik — megkerüli a lomtárat

A Microsoft megfogalmazása az automatikus esetekre egyértelmű: ez a törlési folyamat megkerüli a szokásos lomtárat, és az így törölt verziók onnan nem állíthatók vissza. Vagyis éppen azok a verziók tűnnek el nyomtalanul, amelyek a legnagyobb eséllyel tűnnek el — a régiek, amelyeket az új aktivitás kiszorít.

Mit jelent mindez zsarolóvírus esetén

Tegye egymás mellé a két dokumentált viselkedést, és a hibaforgatókönyv magától összeáll. A SharePointot vagy a OneDrive-ot szinkronizáló kliensen keresztül elérő zsarolóvírus nem törli a fájlokat, hanem írja őket. Minden titkosított fájl egy új verzió a tiszta verzió tetején — pontosan ezért valódi első vonalbeli helyreállítási eszköz a verziótörténet: kisebb, gyorsan észlelt incidensnél a fájlok visszagörgetése az utolsó tiszta verzióra működik.

Csakhogy minden titkosított írás elhasznál egy verzióhelyet. Ahol a dokumentumtárra manuális darabszámkorlát van érvényben, ott az ismételten író támadó — vagy egy órákig futó folyamat, amelyet senki nem vesz észre — kiszorítja a tiszta verziókat a korláton túlra. Ezek a verziók ekkor korláttúllépés miatt törlődnek, a Microsoft saját táblázata szerint pedig a korláttúllépés miatti törlés megkerüli a lomtárat. A védőháló tehát nem egyszerűen kimerül: véglegesen megszűnik, és a felületen semmi nem jelzi, hogy ez megtörtént.

Ugyanaz a szerkezeti pont ez, amelyet a felhőmentés zsarolóvírus elleni védelméről szóló írásunkban is kifejtettünk: a natív mechanizmusok idő- és darabszám-korlátos visszavonási funkciók, amelyeket véletlen hibákra terveztek, nem hitelesített és türelmes ellenfélre. A kimenetelt nem a verziótörténet megléte dönti el, hanem az észlelés késése.

Két dolog, ami mégis megvédi a verziókat

A Microsoft két kivételt dokumentál, és mindkettőt érdemes ismerni, mert ezek az egyetlen natív módok a nyesés megállítására:

• A megőrzési szabályok és az eDiscovery zárolások felülírják a verziókorlátokat. A megőrzési szabály hatálya alatt álló vagy eDiscovery zárolással érintett elemnél a dokumentumtár verziókorlátait a rendszer figyelmen kívül hagyja, amíg a megőrzési idő le nem jár vagy a zárolást fel nem oldják. Ha egy nyesési feladat ilyen verzióba ütközik, törlés helyett lejárati dátumot bélyegez rá.
• A rekordként megjelölt dokumentumok verziói nem törölhetők. Rekordoknál a verziótörlés eleve tiltott.

Egyik sem mentés. Olyan fájlok verzióit védik, amelyek még léteznek, azon a tenanten belül, amely tárolja őket, olyan beállítások alatt, amelyeket egy kellően magas jogosultságú rendszergazda kezel. De ha vannak olyan dokumentumtárak, ahol a verziótörténet tényleg a helyreállítási terv, akkor a megőrzési szabály hatókörébe vonásuk a létező natív eszköz.

A Microsoft a verziótörténettel kapcsolatos tevékenységet a Purview auditnaplójába is rögzíti: a korlátok módosítását minden szinten, az ütemezett nyesési feladatokat, a tömeges és az egyedi verziótörléseket. Ha arra kíváncsi, szigorított-e valaki egy korláton, a válasz ott van.

Hogyan kapja meg a választ a saját környezetére

A tisztázandó kérdések rövidek, és egyikhez sem kell előbb termékdöntést hozni: mely Microsoft 365 dokumentumtárai futnak automatikus korláton és melyek manuális darabszámon, állított-e be valaha bárki API-n keresztül a felületi küszöb alatti értéket, és mely tárakban van olyan tartalom, ahol a verziótörténet elvesztése valódi kárt okozna.

Ha ezt a valós helyreállítási igényéhez mérten szeretné látni — meddig kell visszamenőleg helyreállítani, mely munkaterhelések hordozzák a kockázatot, és hol húzódnak ma a natív határok —, a helyreállítási felmérésünk végigveszi a bérlői környezetét, és megmutatja, hol nem elég már a verziótörténet. Mi a környezetéhez illő megoldás kiválasztásában és üzembe helyezésében segítünk; onnantól Öné a rendszer, és Ön üzemelteti.