Megjegyzés
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhat bejelentkezni vagy módosítani a címtárat.
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhatja módosítani a címtárat.
Engedélyezheted a blobverzió-kezelést, hogy automatikusan fenntartsd az objektum korábbi verzióit. Ha engedélyezed a blob verziókat, hozzáférhetsz a blob korábbi verzióihoz, hogy visszanyerd az adatokat, ha módosítják vagy törölték.
Figyelemfelhívás
Miután engedélyezte a blobok verziószámozását egy tárfiókhoz, a fiókban lévő blobok írási műveletei egy új verzió létrehozását eredményezik. Ezért a blob verzió engedélyezése plusz költségeket okozhat. A költségek minimalizálása érdekében használj Lifecycle Management szabályzatot vagy Storage Actions feladatot az előző verziók automatikus törlésére.
Ajánlott adatvédelmi konfiguráció
A Blob verziókezelés a több adatvédelmi funkció egyike. A megfelelő funkció vagy funkciókombináció kiválasztása a munkaterhelésedtől és attól függ, mitől védekezel. További információkért a Microsoft adatvédelmi ajánlásairól lásd: Adatvédelmi áttekintés.
Verziók és pillanatképek összehasonlítása
A blob verzió hasonló a snapshothoz, de a kettő eltér abban, hogyan készülnek és mire alkalmasak leginkább. Egy verzió automatikus és a rendszer által felügyelt: az Azure Storage minden íráskor vagy törléskor új verziót hoz létre, amikor a blobverziózás engedélyezve van, és nincs szükség alkalmazáslogikára. A pillanatkép kézi és alkalmazásvezérelt: kifejezetten létrehozol egy adott időpontbeli másolatot, amikor az alkalmazás úgy dönt, hogy szükséges.
Használj verziózást, ha automatikus, folyamatos védelmet szeretnél a véletlen vagy rosszindulatú felülírások és törlések ellen. Használj pillanatképeket, amikor szándékos, pont-in-time másolatokat szeretnél, például egy biztosan működő visszaállítási pontot a tervezett frissítés előtt. A Microsoft azt javasolja, hogy hagyd abba a blokkblobokról készült pillanatképek készítését, amint a verziószámozás engedélyezve van.
A blob verziókezelésének működése
A verzió egy blob állapotát rögzíti egy adott időpontban. Minden verziónak van verzióazonosítója. Amikor engedélyezed a blobverziózást egy tárolófióknál, az Azure Storage automatikusan létrehoz egy új verziót egyedi azonosítóval, amikor először létrehozol egy blobot, és minden alkalommal, amikor módosítod a blobot.
A verzióazonosító azonosíthatja az aktuális vagy az előző verziót. Egy blobnak egyszerre csak egy aktuális verziója lehet, az aktuális állapota. Egy blobnak több korábbi verziója is lehet.
Új blob létrehozásakor egyetlen verzió létezik, és ez a jelenlegi verzió. Meglévő blob módosításakor az aktuális verzió egy korábbi verzió lesz. Létrejön egy új verzió a frissített állapot rögzítéséhez, és az új verzió az aktuális verzió. Blob törlésekor a blob aktuális verziója korábbi verzióvá válik, és már nincs aktuális verzió. A blob korábbi verziói megmaradnak.
Az alábbi ábra bemutatja, hogyan hozhatók létre verziók írási műveletek során, és hogyan léptethető elő egy korábbi verzió aktuális verzióvá:
A korábbi blob verziók változatlanok, vagyis nem lehet módosítani a tartalmat vagy a metaadatokat.
Fontos
Ha blobonként nagy számú verzióval rendelkezik, azzal növelheti a blobok felsorolási műveleteinek késését. A Microsoft azt javasolja, hogy blobonként kevesebb mint 1000 verziót tartsanak fenn. Használhatsz Életciklus-menedzsment szabályzatot vagy Storage Actions feladatot arra, hogy automatikusan töröld a régi verziókat.
A blobverziózás nem segít helyreállítani a véletlenül törölt tárolófiókot vagy tárolót. A tárfiók véletlen törlésének megakadályozása érdekében konfiguráljon egy zárolást a tárfiók-erőforráson. További információ a tárfiók zárolásáról: Az Azure Resource Manager zárolás alkalmazása egy tárfiókra.
Verzióazonosító
Minden blob verziónak egyedi verzióazonosítója van. A verzióazonosító értéke az időbélyeg, amikor a blob frissült. A verzióazonosítót akkor rendeled hozzá, amikor létrehozod a verziót.
Egy adott blobverziót a verzióazonosítójának használatával olvashatsz vagy törölhetsz. Ha nem adod meg a verzióazonosítót, a művelet a jelenlegi verziót célozza meg.
Amikor írási műveletet hajtasz végre egy blob létrehozásához vagy módosításához, az Azure Storage a válaszban visszaadja az x-ms-version-id fejlécet. Ez a fejléc tartalmazza az aktuális verzió verzióazonosítóját, amelyet az írási művelet hozott létre.
A verzióazonosító a verzió élettartama alatt változatlan marad.
Írási műveletek verziókezelése
Amikor bekapcsolod a blob verziózást, minden egyes blobba írt művelet új verziót hoz. Az írási műveletek közé tartozik a Blob elhelyezése, a Blokklista elhelyezése, a Blob másolása és a Blob metaadatainak beállítása.
Ha az írási művelet új blobot hoz létre, akkor az eredmény a folb aktuális verziója lesz. Ha az írási művelet módosít egy meglévő blobot, a jelenlegi verzió egy korábbi verzióvá válik, és egy új, aktuális verzió rögzíti a frissített blobot.
Az alábbi diagram bemutatja, hogyan befolyásolják az írási műveletek a blobverziókat. Az egyszerűség kedvéért a cikkben szereplő diagramok egyszerű egész értékként jelenítik meg a verzióazonosítót. A valóságban a verzióazonosító egy időbélyeg. Az aktuális verzió kék, a korábbi verziók pedig szürke színnel jelennek meg.
Megjegyzés
Az a blob, amelyet a tárolófiókhoz a verziókezelés engedélyezése előtt hozott létre, nem rendelkezik verzióazonosítóval. Amikor módosítod azt a blobot, a módosított blob az új aktuális verzióvá válik, és a blob frissítés előtti állapota egy korábbi verzióvá válik. A jelenlegi verzióhoz egy olyan verzióazonosító van hozzárendelve, amely megegyezik a létrehozás időpontjával.
Amikor engedélyezed a blob verziózást egy tárolófióknál, minden blokk bloban lévő írási művelet új verzió létrehozását indítja el, kivéve a Put Block műveletet.
Lapblobok és hozzáfűző blobok esetén csak az írási műveletek egy részhalmaza aktiválja a verzió létrehozását. Ezek a műveletek a következők:
Az alábbi műveletek nem indítják el új verzió létrehozását:
- Oldal elhelyezése (lapblob)
- Hozzáfűző blokk (hozzáfűző blob)
A műveletekből származó változások rögzítéséhez készíts kézi snapshotot. További információért lásd: Blob snapshots.
A blob minden verziójának azonos blobtípusúnak kell lennie. Ha egy blob korábbi verzióival rendelkezik, nem írhatja felül az egyik típusú blobot egy másik típussal, kivéve, ha először törli a blobot és annak összes verzióját.
Verziószámozás törlési műveletek esetén
Ha a Delete Blob műveletet verzióazonosító megadás nélkül hajtod végre, a jelenlegi verzió egy korábbi verzióvá válik, és már nincs jelenlegi verzió. A művelet megőrzi a folb összes korábbi verzióját.
Az alábbi ábra egy törlési művelet egy verziószámozott blobra gyakorolt hatását mutatja be:
A blob egy adott verziójának törléséhez adja meg az adott verzió azonosítóját a törlési műveletben. Ha a blob soft delete funkciót is engedélyezed a tárolófióknál, a rendszer megtartja a verziót, amíg a soft delete megtartási ideje le nem jár.
Ha új adatokat ír a blobba, a blob új, aktuális verzióját hozza létre. Ez a művelet nem érinti a meglévő verziókat, ahogy az alábbi ábrán látható.
Hozzáférési szintek
A blokkblobok bármely verzióját, beleértve az aktuális verziót is, áthelyezheti egy másik blobhozzáférési szintre a Blobréteg beállítása művelet meghívásával. A blob régebbi verzióinak a ritka elérésű vagy archív szintre történő áthelyezésével kihasználhatja az alacsonyabb kapacitásdíjakat. További információ: Gyakori elérésű, ritka elérésű, hideg elérésű és archív hozzáférési szintek a blobadatokhoz.
A blokkblobok megfelelő szintre történő áthelyezésének automatizálásához hozz létre Lifecycle Management szabályzatot, hozz létre Storage Actions feladatot, vagy engedélyezd a Smart Tier funkciót.
Blobverzió engedélyezése vagy letiltása
A blobverziózás engedélyezésére és letiltására vonatkozó utasításokért lásd a(z) A blobverziózás engedélyezése és kezelése.
A blobverziók letiltása nem törli a meglévő blobokat, verziókat vagy pillanatképeket. Ha kikapcsolod a blob verziózást, nem tudsz új verziókat létrehozni.
Miután letiltod a verziózást, a jelenlegi verzió módosítása egy olyan blobot hoz létre, amely nem verzió. A blob minden későbbi frissítése felülírja az adatait az előző állapot mentése nélkül. Az összes meglévő verzió megmarad a korábbi verziókban.
A verziókezelés letiltása után a verzióazonosító használatával beolvashatod vagy törölheted a verziókat. A blobok verzióit a verziószámozás letiltása után is listázhatja.
Az objektumreplikálás blobverzióra támaszkodik. A blobok verziószámozásának letiltása előtt törölnie kell a fiók összes objektumreplikációs szabályzatát. Az objektumreplikálással kapcsolatos további információkért lásd a blokkblobok objektumreplikálását ismertető témakört.
Az alábbi ábra bemutatja, hogy a blobok verziószámozásának letiltása után történő módosítása hogyan hoz létre nem verziószámozott blobot. A blobhoz társított meglévő verziók megmaradnak.
Funkciók támogatása
Ennek a funkciónak a támogatását befolyásolhatja a Data Lake Storage Gen2, a Hálózati fájlrendszer (NFS) 3.0 protokoll vagy az SSH Fájlátviteli Protokoll (SFTP) engedélyezése. Ha engedélyezte ezen képességek bármelyikét, tekintse meg Blob Storage funkciótámogatást Azure Storage fiókokban a funkció támogatásának felméréséhez.
A Blob verziószámozása a standard általános célú v2, prémium szintű blokkblobok és régi Blob tároló fiókok esetében érhető el. A Azure Data Lake Storage használatára engedélyezett hierarchikus névtérrel rendelkező tárfiókok jelenleg nem támogatottak.
A Azure Storage REST API 2019-10-10-es és újabb verziója támogatja a blobok verziószámozását.
A verziószerkesztés nem támogatott azoknál a blobokban, amelyeket Data Lake Storage API-kkal töltünk fel.
Műveletek engedélyezése blobverziókon
A blob verziókhoz hozzáférést engedélyezheted az alábbi módszerek egyikével:
- Használd az Azure szerepalapú hozzáférési vezérlést (Azure RBAC) egy Microsoft Entra biztonsági alapvetleg jogosultságának megadásához. Microsoft a Microsoft Entra ID használatát javasolja a kiváló biztonság és a könnyű használat érdekében. További információt a Microsoft Entra ID blobműveletekkel való használatáról az Azure Storage adatokhoz való hozzáférés engedélyezése részben talál.
- Használj közös hozzáférési aláírást (SAS) a hozzáférés delegálására a blob verziókhoz. Megadjuk a verzióazonosítót az aláírt erőforrás-típushoz
bv, amely egy blob verziót képvisel, hogy SAS tokent hozz létre egy adott verzión végzett műveletekhez. A megosztási hozzáférési aláírásokkal kapcsolatos további információkért lásd: Az Azure Storage erőforrásokhoz történő korlátozott hozzáférés megadása megosztási hozzáférési aláírások (SAS) használatával. - Használd a fiókhozzáférési kulcsokat a Shared Key használatával a blob verziók elleni műveletek hitelesítéséhez. További információ: Engedélyezés megosztott kulccsal.
A blobverziók úgy lettek kialakítva, hogy megvédjék az adatokat a véletlen vagy rosszindulatú törléstől. A védelem javításához a blobverzió törléséhez speciális engedélyekre van szükség. A következő szakaszok a blobverzió törléséhez szükséges engedélyeket ismertetik.
Azure RBAC-művelet a blobverzió törléséhez
Az alábbi táblázat azt mutatja be, hogy mely Azure RBAC-műveletek támogatják a blobok vagy blobverziók törlését.
| Leírás | Blobszolgáltatás-művelet | RBAC-adatművelet Azure szükséges | Azure beépített szerepkör támogatása |
|---|---|---|---|
| Az aktuális verzió törlése | Blob törlése | Microsoft.Storage/storageAccounts/blobServices/containers/blobs/delete | Storage blobadat-közreműködő |
| Előző verzió törlése | Blob törlése | Microsoft.Storage/storageAccounts/blobServices/containers/blobs/deleteBlobVersion/action | Storage-Blob adattulajdonos |
Közös hozzáférésű jogosultságkód (SAS) paraméterei
A blobverzió aláírt erőforrása a következő: bv. További információ: szolgáltatási SAS létrehozása vagy felhasználói delegációs SAS létrehozása.
Az alábbi táblázat a blobverzió törléséhez szükséges sas-engedélyeket mutatja be.
| Engedély | URI-szimbólum | Engedélyezett műveletek |
|---|---|---|
| Törlés | x | Egy blobverzió törlése. |
Meglévő munkaterhelési szempontok
A blob törlése már nem szabadít fel helyet. Amikor engedélyezed a verziózást, egy blob törlése nem távolítja el az adatait. A jelenlegi verzió egy korábbi verzióvá válik, amely megmarad, és továbbra is díjköteles marad. Azok a munkaterhelések, amelyek törlési műveletekre támaszkodnak a tároló visszaszerzéséhez, folyamatosan díjakat vonnak maguk után, amíg kifejezetten nem törlöd ezeket a verziókat.
A felülírás-intenzív munkaterhelések verziókat halmozhatnak fel. A verziók addig maradnak, amíg kifejezetten nem törlöd őket. Ez a perzisztencia változatok felhalmozódásához vezethet, ha nem kezeled őket megfelelően. A költségek csökkentése érdekében a verziók közötti blokkszintű módosítások blokkszinten legyenek elszámolva, minimalizálva a verziónkénti költségeket.
Funkciók közötti interakciók
Lágy törlés
A blobok verziószámozása és a blobok helyreállítható törlése a tárfiókok ajánlott adatvédelmi konfigurációjának része. A Microsoft adatvédelmi javaslatairól az adatvédelem áttekintésében talál további információt.
Blob felülírása
Ha engedélyezed mind a blob verziózást, mind a blob soft delete használatát egy tárolófióknál, akkor a blob felülírása automatikusan létrehoz egy új korábbi verziót, amely tükrözi a blob állapotát az írás előtti művelet előtt. Az új verzió nem kerül ideiglenes törlésre, és addig marad, amíg kifejezetten nem törlik. A rendszer nem hoz létre helyreállíthatóan törölt pillanatképeket.
Blob vagy verzió törlése
Ha egyszerre engedélyezed a verziókövetést és a helyreállítható törlést egy tárolófióknál, akkor a blob jelenlegi verziója egy korábbi verzióvá válik. A művelet nem hoz létre új verziót vagy semmilyen helyreállítható pillanatképet. A lágy törlés megőrzési időszaka nem vonatkozik a törölt folcra.
A soft delete extra védelmet nyújt a blob verziók törlésekor. Ha töröl egy korábbi verziót a blobból, a művelet helyreállítható módon törli azt a verziót. A helyreállíthatóan törölt verzió mindaddig megmarad, amíg a helyreállítható törlés megőrzési ideje el nem telik, és ekkor véglegesen törlődik.
A blob egy korábbi verziójának törléséhez hívja meg a Blob törlése műveletet, és adja meg a verzióazonosítót.
Lágyan törölt verzió visszaállítása
A Blob helyreállítása művelettel a helyreállíthatóan törölt verziók a helyreállítható törlés megőrzési időszaka alatt visszaállíthatók. Az Undelete Blob művelet mindig visszaállítja a blob összes soft-deletelt verzióját. Nem lehet csak egyetlen lágyan törölt verziót visszaállítani.
Az ideiglenesen törölt verziók visszaállítása a Undelete Blob művelet használatával nem tesz egyetlen verziót sem aktuális verzióvá. Az aktuális verzió visszaállításához először állítsa vissza az összes puha törléssel törölt verziót, majd a Copy Blob művelettel másolja az előző verziót egy új, aktuális verzióra.
A helyreállítható törlés megőrzési időszakának lejárta után a rendszer véglegesen törli a helyreállíthatóan törölt blobverziókat.
Blob-pillanatképek
A blob pillanatképe egy blob adott időpontban készített, csak olvasható másolata. A blobsnapshotok és a blobverziók hasonlóak, de egy snapshotot te vagy az alkalmazásod manuálisan hoz létre, míg a blobverzió automatikusan létrejön írási vagy törlési művelet során, amikor engedélyezed a blobverzió-kezelést a tárfiókodhoz.
Fontos
Miután engedélyezted a blobverziózást, frissítsd az alkalmazásodat, hogy többé ne készítsen pillanatképeket a blokkblobokról. Ha engedélyezed a tárolófiókodhoz tartozó verziózást, a verziók rögzítik és megőrzik az összes blokk blob frissítését és törlését. A snapshotok készítése nem nyújt extra védelmet a blokk blob adatai számára, ha a blob verziózás engedélyezett, és növelheti a költségeket és az alkalmazás bonyolultságát.
Pillanatfelvétel készítése egy blobról verziószám engedélyezésekor
Bár ez nem ajánlott, készíthet pillanatképet egy olyan blobról is, amely verziókövetést használ. Ha nem tudja frissíteni az alkalmazást, hogy leállítsák a blobok pillanatképeinek készítését a verziószámozás engedélyezésekor, az alkalmazás támogatja a pillanatképeket és a verziókat is.
Amikor egy verziózott blob snapshotját készíted, egy új verziót is létrehozol a snapshottal egy időben. Új aktuális verziót is létrehozol, amikor fotót készítesz.
Az alábbi ábra bemutatja, mi történik, ha pillanatképet vesz fel egy verziószámozott blobról. A diagramban a 2. és 3. verziójú blobverziók és pillanatképek azonos adatokat tartalmaznak.
Ismert korlátozások
Hierarchikus névterű (Azure Data Lake Storage-) fiókok esetén nem támogatott, illetve Data Lake Storage API-kkal feltöltött blobok esetén.
Nem véd a konténer- vagy fióktörlés ellen. A verziózás csak a blob szinten működik. Egy konténer törlése eltávolítja az összes blobot és azok verzióit. A törlésből való helyreállításhoz konténer soft delete szükséges. A fióktörlés elleni védelemhez erőforrás-zárolás szükséges.
A verziók nem módosíthatók. Nem lehet megváltoztatni egy meglévő verzió tartalmát vagy metaadatait.
A blob minden verziójának azonos blobtípusúnak kell lennie. Nem írhatsz felül egy blobot egy másik blob típussal, amíg korábbi verziói vannak, hacsak nem törlöd előbb a blobot és az összes verzióját.
Nem minden írási művelet hoz létre verziót. Hivatkozz a cikk korábbi részleteire, amelyek a kivételeket részletezik. Ezeknek az állapotoknak a rögzítéséhez használjon kézi pillanatképet.
Nem lehet letiltani a verziózást, amíg léteznek objektumreplikációs szabályzatok a fiókon. Először törölni kell az összes objektumreplikációs szabályzatot.
Undelete Blobvisszaállítja a blob összes helyreállíthatóan törölt verzióját, nem csak egyet. Nem lehet szelektíven visszavonni egyetlen verzió törlését. Az Undelete soha nem tesz egy verziót aktuálissá.Ajánlott felső határ: 1 000 verzió blobonként. Ha ezt túllépi, romlik a blobok listázásának teljesítménye.
Árképzés és számlázás
Ha engedélyezed a blobverziókat, további adattárolási díjak is felmerülhetnek. Amikor megtervezed az alkalmazást, gondold át, hogyan adódnak össze ezek a díjak, hogy alacsonyan tartsd a költségeket.
A blobverziókért, például a blobsnapshotokért, ugyanolyan díjszabás szerint számláznak, mint az aktív adatokért. Az, hogy hogyan történik a verziók számlázása, attól függ, hogy kifejezetten beállítottad-e a szintet a blob aktuális vagy korábbi verzióihoz (vagy snapshotjaihoz). A blobszintekről további információt a blobadatok gyakori elérésű, ritka elérésű, hideg és archív hozzáférési szintjeiben talál.
Ha nem változtatja meg egy blob vagy verzió hozzáférési szintjét, akkor az adott blobban, annak verzióiban és az esetleges pillanatképeiben található egyedi adatblokkok után kell fizetnie. További információért lásd: Számlázás, amikor a blob szint nincs kifejezetten beállítva.
Ha megváltoztatod egy blob vagy verzió szintjét, akkor az egész objektumért számláznak, függetlenül attól, hogy a blob és a verzió újra ugyanabba a szintbe kerül-e. További információért lásd: Számlázás, amikor a blob szint explicit módon be van állítva.
Megjegyzés
Ha engedélyezed a verziózást olyan adatoknál, amelyeket gyakran felülírsz, akkor megnövekedett tárolókapacitási díjakat és nagyobb késleltetést tapasztalhatsz a listázási műveletek során. E problémák kezelésére tárold a gyakran felülírt adatokat egy külön tárolófiókban, kikapcsolt verziókezeléssel.
Ha engedélyezed a verziókezelést azokon a tárfiókokon, amelyekről gyakran készül biztonsági mentés, akkor adatlekérési díjakat idézhetsz elő, amikor a verziókat hűvös vagy hideg hozzáférési szinteken tárolják.
A blob-pillanatképek számlázási részleteiről további információt a Blob pillanatképek című témakörben talál.
Az okos szintet használó tárolófiókoknál teljes tartalomhosszúságú verziókért és snapshotért fizetsz. További információ: Költségek optimalizálása intelligens szinttel.
Számlázás, amikor nem állítod be kifejezetten a blob szintet
Ha nem állítod be kifejezetten a blob szintjét a blob egyetlen verziójához sem, akkor a díjszabás az összes verzióban és az esetleg hozzájuk tartozó pillanatképeken található egyedi blokkokon vagy lapokon alapul. A blobverziók között megosztott adatokért csak egyszer kell fizetnie. Amikor frissítesz egy blobot, az új, jelenlegi verzióban szereplő adatok eltérnek a korábbi verziókban tárolt adatoktól, így számláznak az egyedi adatokért blokkonként vagy oldalonként.
Ha egy blokkot egy blokkblobon belül cserélsz le, akkor azért a blokkért egyedi blokkként számítanak fel díjat. Ez a szabály akkor is érvényes, ha a blokk ugyanazzal a blokkazonosítóval és ugyanazokkal az adatokkal rendelkezik, mint amilyennel az előző verzióban rendelkezett. Miután újra commitálod a blokkot, az eltér az előző verzió megfelelőjétől, és felszámítják az adatai költségét. Ugyanez a szabály vonatkozik egy oldal blobban lévő oldalra, amelyet azonos adatokkal frissítesz.
A blob tároló nem tudja meghatározni, hogy két blokk azonos adatokat tartalmaz-e. Minden blokkot, amit feltöltesz és commisszitálsz, egyediként kezelik, még akkor is, ha ugyanaz az adat és ugyanaz a blokk azonosítója. Mivel egyedi blokkokat számláznak, ne feledd, hogy egy blob frissítése, amikor verziózás engedélyezett, extra egyedi blokkokat és további díjakat eredményez.
Amikor engedélyezed a blob verziózást, hívd a blokk blobokra vonatkozó frissítési műveleteket, hogy a lehető legkevesebb blokkot frissítsék. A blokkok részletes vezérlését lehetővé tevő írási műveletek a Blokkok elhelyezése és a Blokkok listázása. A Put Block átmenetileg tárolja a módosításokat, de a tényleges módosítás és verzió létrehozása a Put Block List műveleten történik. A Put Blob művelet viszont lecseréli a blob teljes tartalmát, így többletköltségeket eredményezhet.
Az alábbi forgatókönyvek bemutatják, hogyan merülnek fel a költségek egy blokkblob és annak verziói esetében, ha nem állítja be kifejezetten a blob hozzáférési szintjét.
1. eset
Az 1. forgatókönyvben a blobnak van egy korábbi verziója. A blobot a verzió létrehozása óta nem frissítették, így csak az 1-es, 2-es és 3-as egyedi blokkokért kell díjat fizetni.
2. eset
A 2-es forgatókönyvben egy blokk (a diagramon a 3-as blokk) frissül a blobban. Annak ellenére, hogy a frissített blokk ugyanazokat az adatokat és azonos azonosítót tartalmazza, nem ugyanaz, mint a 3. blokk az előző verzióban. Ennek eredményeképpen a fiókot négy blokkért számítják fel.
3. eset
A 3. forgatókönyvben a blob frissül, de a verzió nem. A 3-as blokkot a jelenlegi blobban a 4-es blokk váltja fel, de az előző verzió még mindig tükrözi a 3-as blokkot. Ennek eredményeképpen a fiókot négy blokkért számítják fel.
4. forgatókönyv
A 4. forgatókönyvben a jelenlegi verzió teljesen frissített, és egyetlen eredeti blokkját sem tartalmazza. Ennek eredményeként a fiók mind a nyolc egyedi blokkért fizet fel – a jelenlegi verzióban négy, az előző két verzióban pedig összesen négy. Ez a helyzet akkor fordulhat elő, ha a Put Blob művelettel írsz egy blobba, mert az a blob teljes tartalmát helyettesíti.
Számlázás, amikor kifejezetten beállítod a blob-hozzáférési szintet
Ha kifejezetten beállítod a blobszintet egy blob, verzió vagy pillanatkép számára, akkor az objektum új szinten tárolt teljes tartalomhosszáért fizetsz, függetlenül attól, hogy megoszt-e blokkokat az eredeti szinten lévő objektummal. Az eredeti szint legrégebbi verziójának teljes tartalma hosszáért is fizetsz. Az összes többi korábbi verzió vagy pillanatkép esetében, amely az eredeti szinten marad, az általuk megosztott egyedi blokkok után kell fizetni, a Számlázás, ha a blob szintje nincs kifejezetten beállítva című szakaszban leírtak szerint.
Blob áthelyezése új szintre
Az alábbi táblázat leírja a számlázási viselkedést egy folb vagy verzió esetén, amikor áthelyezed egy új szintre.
| Amikor beállítod a blob szintet... | Ezt követően kiszámlázzuk a... |
|---|---|
| Kifejezetten egy verzióra állítva, legyen az aktuális vagy korábbi | A verzió teljes tartalomhossza. Azok a verziók, amelyek nem rendelkeznek explicit módon beállított szinttel, csak egyedi blokkokért számlázunk.1 |
| Beállítás archívra | Az összes verzió és pillanatkép teljes tartalmi hossza. 1 |
1Ha vannak más korábbi verziók vagy pillanatképek, amelyeket nem helyeztél át az eredeti hozzáférési szintjükről, akkor ezekért a verziókért vagy pillanatképekért a bennük található egyedi blokkok száma alapján számítunk fel díjat, a Számlázás, amikor a blob hozzáférési szintje nincs kifejezetten beállítva című szakaszban leírtak szerint.
A következő diagram szemlélteti, hogyan számlázzák az objektumokat, amikor egy verziózott blobot áthelyezünk egy másik hozzáférési szintre.
Nem lehet visszavonni a blob, a verzió vagy a pillanatkép hozzáférési szintjének kifejezett beállítását. Ha egy blobot áthelyezel egy új szintre, majd visszaviszed az eredeti szintre, akkor az objektum teljes tartalmi hosszáért fizetsz, még akkor is, ha blokkokat oszt meg más objektumokkal az eredeti szinten.
Azok a műveletek, amelyek explicit módon beállítják egy blob, verzió vagy pillanatkép rétegét, a következők:
- Blob réteg beállítása
- Blob elhelyezése megadott rétegszinttel
- Blokklista elhelyezése megadott szinttel
- Blob másolása megadott réteggel
Blob törlése, ha a helyreállítható törlés engedélyezve van
Ha engedélyezi a blobok helyreállítható törlését, a helyreállítható törléssel törölt összes elemért ugyanazon a díjszabáson kell fizetnie, mint az aktív adatokért. Ha törlöd vagy felülírsz egy jelenlegi verziót, amelynek a szintjét kifejezetten beállítottad, akkor fizetsz a korábbi verziókért a lágyan törölt blobból, teljes tartalomhosszban. További információért arról, hogyan működik együtt a blobverziózás és a helyreállítható törlés, lásd: Funkcióinterakciók.
Figyelés és hibaelhárítás
Az LCM szabályzatom nem törli a verziókat, amikor elvárnám: Egy verzió kora attól függ, amikor eredetileg írtad az adatokat, nem attól, mikor vált korábbi verzióvá. Az óra a blob létrehozásánál kezdődik, nem annál a felülírásnál, ami a blobot a verzióelőzményekbe juttatta. Ennek eredményeként egy olyan blob, amely sokáig aktuális maradt, mielőtt felülírták, létrehozhat egy korábbi verziót, amely már a létrehozás pillanatában meghaladja a
daysAfterCreationGreaterThanküszöböt, így szinte azonnal törlődik. Ezzel szemben a nemrég létrehozott blobok verziói a vártnál tovább is fennmaradhatnak. A megerősítéshez nézd meg a verziók tényleges létrehozási időbélyegét, ne feltételezd, hogy egyezik a felülírás időpontjával. Ha a megtartást arra kell alapozni, amikor egy verzió már nem aktuális, vagy részletesebb kontrollt szeretnél, mint amit az életciklus-menedzsment napi küszöbértékei engednek, fontold meg az Azure Storage Actions használatát helyette. További információért lásd: Tárolási műveletek.A számla továbbra is magas a verziókezelés kikapcsolása után: A meglévő verziók mindaddig megmaradnak, amíg manuálisan nem törli őket.
Nem tudom letiltani a verziózást. Objektumreplikáció konfigurálható a fiókon. Először töröld az összes objektumreplikációs szabályzatot, majd kapcsold le a verziózást. Alternatív megoldásként egy konténeren vagy azon a fiókon is lehet Immutability (WORM) szabályzat, amelynél a verziózás nem tiltható le.