Időponthoz kötött visszaállítás blokkblobokhoz
Az időponthoz kötött visszaállítás védelmet nyújt a véletlen törlés vagy sérülés ellen azáltal, hogy lehetővé teszi a blokkblobadatok korábbi állapotba való visszaállítását. Az időponthoz kötött visszaállítás olyan esetekben hasznos, amikor egy felhasználó vagy alkalmazás véletlenül törli az adatokat, vagy amikor egy alkalmazáshiba az adatokat rontja. Az időponthoz kötött visszaállítás olyan tesztelési forgatókönyveket is lehetővé tesz, amelyek további tesztek futtatása előtt egy adathalmazt egy ismert állapotba szeretnének visszaállítani.
Az időponthoz kötött visszaállítás csak a standard teljesítményszinten lévő általános célú v2-tárfiókok esetében támogatott. Csak a gyakori és ritka elérésű hozzáférési szinteken lévő adatok állíthatók vissza időponthoz kötött visszaállítással. Az időponthoz kötött visszaállítás még nem támogatott a hierarchikus névtérrel rendelkező fiókokban.
A tárfiókok időponthoz kötött visszaállításának engedélyezéséről további információt a blokkblobadatok időponthoz kötött visszaállításának végrehajtása című témakörben talál.
Időponthoz kötött visszaállítás működése
Az időponthoz kötött visszaállítás engedélyezéséhez hozzon létre egy felügyeleti szabályzatot a tárfiókhoz, és adjon meg egy megőrzési időtartamot. A megőrzési időszak alatt visszaállíthatja a blokkblobokat a jelenlegi állapotból egy korábbi állapotba.
Időponthoz kötött visszaállítás indításához hívja meg a Blobtartományok visszaállítása műveletet, és adjon meg egy visszaállítási pontot UTC időpontban. Megadhatja a visszaállítandó tároló- és blobnevek lexikográfiai tartományait, vagy kihagyhatja a tartományt a tárfiók összes tárolójának visszaállításához. Visszaállítási műveletenként legfeljebb 10 lexikográfiai tartomány támogatott.
Az Azure Storage elemzi a megadott blobokon végrehajtott összes módosítást a kért visszaállítási pont és a jelen pillanatban megadott időpont között. A visszaállítási művelet atomi, így vagy teljesen sikerül visszaállítani az összes módosítást, vagy sikertelen. Ha vannak olyan blobok, amelyek nem állíthatók vissza, a művelet meghiúsul, és az érintett tárolók olvasási és írási műveletei folytatódnak.
Az alábbi ábra az időponthoz kötött visszaállítás működését mutatja be. A rendszer egy vagy több tárolót vagy blobtartományt állít vissza az n nappal ezelőtti állapotba, ahol n kisebb vagy egyenlő az időponthoz kötött visszaállításhoz meghatározott megőrzési időnél. Az megőrzési időszak alatt végrehajtott írási és törlési műveletek visszaállítása.
Egyszerre csak egy visszaállítási művelet futtatható egy tárfiókon. A visszaállítási műveletet nem lehet megszakítani, ha már folyamatban van, de egy második visszaállítási művelet is elvégezhető az első művelet visszavonásához.
A Blobtartományok visszaállítása művelet egy olyan visszaállítási azonosítót ad vissza, amely egyedileg azonosítja a műveletet. Az időponthoz kötött visszaállítás állapotának ellenőrzéséhez hívja meg a Visszaállítás állapotának lekérése műveletet a Blobtartományok visszaállítása műveletből visszaadott visszaállítási azonosítóval.
Fontos
Visszaállítási művelet végrehajtásakor az Azure Storage letiltja az adatműveleteket a visszaállítandó tartományokban lévő blobokon a művelet időtartama alatt. Az olvasási, írási és törlési műveletek le vannak tiltva az elsődleges helyen. Emiatt előfordulhat, hogy az Olyan műveletek, mint a tárolók listázása az Azure Portalon nem a várt módon futnak, amíg a visszaállítási művelet folyamatban van.
A másodlagos helyről történő olvasási műveletek a visszaállítási művelet során is folytatódhatnak, ha a tárfiók georeplikált.
Figyelemfelhívás
Az időponthoz kötött visszaállítás támogatja a csak blokkblobokon végrehajtott műveletek visszaállítását. A tárolókon végrehajtott műveletek nem állíthatók vissza. Ha például töröl egy tárolót a tárfiókból a Tároló törlése művelet meghívásával, az adott tároló nem állítható vissza időponthoz kötött visszaállítási művelettel. A teljes tároló törlése helyett törölje az egyes blobokat, ha később vissza szeretné állítani őket.
Időponthoz kötött visszaállítás előfeltételei
Az időponthoz kötött visszaállításhoz engedélyezni kell a következő Azure Storage-funkciókat, mielőtt engedélyezhető lenne az időponthoz kötött visszaállítás:
Ha többet szeretne megtudni a Microsoft adatvédelmi javaslatairól, tekintse meg az adatvédelem áttekintését.
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. Emiatt a blob verziószámozásának engedélyezése további költségekkel járhat. A költségek minimalizálása érdekében használjon életciklus-kezelési szabályzatot a régi verziók automatikus törléséhez. Az életciklus-kezeléssel kapcsolatos további információkért lásd : Költségek optimalizálása az Azure Blob Storage hozzáférési szintjeinek automatizálásával.
Az időponthoz kötött visszaállítás megőrzési időtartama
Ha engedélyezi a tárfiók időponthoz kötött visszaállítását, meg kell adnia egy megőrzési időtartamot. A tárfiókban lévő blokkblobok visszaállíthatók a megőrzési időszak alatt.
A megőrzési időszak néhány perccel az időponthoz kötött visszaállítás engedélyezése után kezdődik. Ne feledje, hogy a blobok nem állíthatók vissza állapotba a megőrzési időszak kezdete előtt. Ha például május 1-jén engedélyezte az időponthoz kötött visszaállítást 30 napos megőrzéssel, akkor május 15-én legfeljebb 15 napra állíthatja vissza a visszaállítást. Június 1-jén 1 és 30 nap között állíthatja vissza az adatokat.
Az időponthoz kötött visszaállítás megőrzési időszakának legalább egy nappal rövidebbnek kell lennie, mint a helyreállítható törléshez megadott megőrzési idő. Ha például a helyreállítható törlés megőrzési ideje hét napra van beállítva, akkor az időponthoz kötött visszaállítás megőrzési ideje 1 és 6 nap között lehet.
Feljegyzés
Az időponthoz kötött visszaállításhoz megadott megőrzési idő nincs hatással a blobverziók megőrzésére. A blobverziók mindaddig megmaradnak, amíg explicit módon nem törlődnek. A költségek optimalizálásához a régebbi verziók törlésével vagy rétegzésével hozzon létre egy életciklus-kezelési szabályzatot. További információ: Költségek optimalizálása az adatéletciklus automatikus kezelésével.
Az adathalmaz visszaállításához szükséges idő a visszaállítási időszakban végrehajtott írási és törlési műveletek számán alapul. Ha például egy millió blobot tartalmazó fiókhoz naponta 3000 blobot adnak hozzá, és naponta 1000 blobot törölnek, körülbelül két órát igényel, hogy a múltban 30 napra állítsa vissza a fiókot. A megőrzési időszak és a visszaállítás 90 napnál hosszabb ideje nem ajánlott egy ilyen mértékű változással rendelkező fiók számára.
Időponthoz kötött visszaállítás engedélyei
A visszaállítási művelet elindításához az ügyfélnek írási engedélyekkel kell rendelkeznie a tárfiók összes tárolójára. Ha engedélyt szeretne adni egy visszaállítási művelet Engedélyezéséhez a Microsoft Entra-azonosítóval, rendelje hozzá a tárfiók közreműködői szerepkörét a tárfiók, az erőforráscsoport vagy az előfizetés szintjén lévő biztonsági taghoz.
Korlátozások és ismert problémák
A blokkblobok időponthoz kötött visszaállítása a következő korlátozásokkal és ismert problémákkal rendelkezik:
- Egy időponthoz kötött visszaállítási művelet részeként csak a szabványos, általános célú v2-tárfiókban lévő blokkblobok állíthatók vissza. A hozzáfűző blobok, a lapblobok és a prémium szintű blokkblobok nem lesznek visszaállítva.
- Ha a megőrzési időszak alatt törölt egy tárolót, a tároló nem lesz visszaállítva az időponthoz kötött visszaállítási művelettel. Ha olyan blobtartományt próbál visszaállítani, amely egy törölt tárolóban található blobokat tartalmaz, az időponthoz kötött visszaállítási művelet meghiúsul. A tárolók törlés elleni védelméről további információt a tárolók helyreállítható törlése című témakörben talál.
- Ha állandó törléssel törli a blob helyreállíthatóan törölt verzióit az időponthoz kötött visszaállítási megőrzési időszak alatt, akkor előfordulhat, hogy egy visszaállítási művelet nem tudja megfelelően visszaállítani a blobot.
- Ha egy blob a jelenlegi pillanat és a visszaállítási pont közötti időszakban a gyakori és a ritka elérésű rétegek között mozog, a blob visszaáll az előző szintre.
- A blokkblobok visszaállítása az archív szinten nem támogatott. Ha például a gyakori elérésű rétegben lévő blobot két nappal ezelőtt áthelyezték az archív szintre, és egy visszaállítási művelet három nappal ezelőttre áll vissza, a blob nem lesz visszaállítva a gyakori elérésű szintre. Archivált blob visszaállításához először helyezze ki az archív rétegből. További információ: A blob rehidratációjának áttekintése az archív rétegből.
- A részleges visszaállítási műveletek nem támogatottak. Ezért ha egy tárolóban archivált blobok vannak, a teljes visszaállítási művelet meghiúsul, mert a blokkblobok visszaállítása az archív rétegben nem támogatott.
- Ha egy módosíthatatlansági szabályzat konfigurálva van, akkor a visszaállítási művelet kezdeményezhető, de a módosíthatatlansági szabályzat által védett blobok nem lesznek módosítva. Ebben az esetben a visszaállítási művelet nem eredményezi a konzisztens állapot visszaállítását a megadott dátumig és időpontig.
- Az URL-címről feltöltött, de a Put Block List használatával nem véglegesített blokk nem része egy blobnak, így a visszaállítási művelet részeként nem állítható vissza.
- Ha egy aktív bérlettel rendelkező blob szerepel a visszaállítandó tartományban, és ha a bérelt blob jelenlegi verziója eltér az előző verziótól a PITR-hez megadott időbélyegen, a visszaállítási művelet atomi módon meghiúsul. Javasoljuk, hogy a visszaállítási művelet megkezdése előtt szakítsa meg az aktív bérleteket.
- Ha ügyfél által felügyelt feladatátvételt hajt végre egy tárfiókon, a tárfiók lehető legkorábbi visszaállítási pontja alaphelyzetbe áll. További részletekért lásd az időponthoz kötött visszaállítást.
- A rendszer nem hozza létre vagy törli a pillanatképeket a visszaállítási művelet részeként. A rendszer csak az alapblobot állítja vissza az előző állapotba.
- Az időponthoz kötött visszaállítás nem támogatott hierarchikus névterek és műveletek esetében az Azure Data Lake Storage Gen2-n keresztül.
- Az időponthoz kötött visszaállítás nem támogatott, ha a tárfiók AllowedCopyScope tulajdonsága úgy van beállítva, hogy a másolási hatókört ugyanarra a Microsoft Entra-bérlőre vagy virtuális hálózatra korlátozza. További információ: A másolási műveletek engedélyezett hatóköre (előzetes verzió).
- Az időponthoz kötött visszaállítás nem támogatott, ha a verziószintű nem módosíthatóság engedélyezve van egy tárfiókban vagy egy fiókban lévő tárolóban. A verziószintű nem módosíthatóságról további információt a blobverziók nem módosíthatósági szabályzatainak konfigurálása című témakörben talál.
Fontos
Ha a blokkblobokat 2020. szeptember 22-nél korábbi pontra állítja vissza, az időponthoz kötött visszaállítás előzetes verziójának korlátozásai érvényben lesznek. A Microsoft azt javasolja, hogy válasszon egy olyan visszaállítási pontot, amely 2020. szeptember 22-ével egyenlő vagy későbbi, hogy kihasználhassa az általánosan elérhető időponthoz kötött visszaállítási funkciót.
Szolgáltatások támogatása
Ennek a funkciónak a támogatását befolyásolhatja a Data Lake Storage Gen2, a Network File System (NFS) 3.0 protokoll vagy az SSH File Transfer Protocol (SFTP) engedélyezése. Ha engedélyezte bármelyik funkciót, tekintse meg a Blob Storage szolgáltatástámogatását az Azure Storage-fiókokban a funkció támogatásának felméréséhez.
Árképzés és számlázás
Az időponthoz kötött visszaállítás engedélyezése díjmentes. Az időponthoz kötött visszaállítás engedélyezése azonban lehetővé teszi a blobok verziószámozását, a helyreállítható törlést és a változáscsatornát is, amelyek mindegyike további díjakat vonhat maga után.
Az időponthoz kötött visszaállítási műveletek végrehajtásának számlázása a visszaállításhoz feldolgozott változáscsatorna-adatok mennyiségén alapul. Emellett a visszaállítási folyamat során felmerülő tárolási tranzakciókért is fizetnie kell.
Az időponthoz kötött visszaállítás díjszabásáról további információt a Blobok díjszabásának blokkolása című témakörben talál.