Automatikus biztonsági mentések az Azure SQL Database-ben

A következőkre vonatkozik:Azure SQL Database

• Azure SQL-adatbázis
• Felügyelt Azure SQL-példány

Ez a cikk az Azure SQL Database automatikus biztonsági mentési funkcióját ismerteti.

A biztonsági mentési beállítások módosításáról a Beállítások módosításacímű témakörben olvashat. A biztonsági mentés visszaállításának módjáról az automatikus adatbázis-biztonsági másolatok használatával a ésszakaszokban olvashat.

Mi az az adatbázis biztonsági mentése?

Az adatbázis-biztonsági mentések elengedhetetlen részei az üzletmenet-folytonossági és vészhelyreállítási stratégiának, mivel segítenek megvédeni az adatokat a sérüléstől vagy a törléstől. Ezek a biztonsági másolatok lehetővé teszik az adatbázis egy adott időpontra való visszaállítását a konfigurált megőrzési időszakon belül. Ha az adatvédelmi szabályok megkövetelik, hogy a biztonsági másolatok hosszabb ideig (legfeljebb 10 évig) elérhetők legyenek, konfigurálhatja hosszú távú adatmegőrzési (LTR) az önálló és a készletezett adatbázisokhoz is.

A rugalmas skálázástól eltérő szolgáltatási szintek esetében az Azure SQL Database SQL Server-motortechnológiát használ az adatok biztonsági mentéséhez és visszaállításához. A rugalmas skálázású adatbázisok biztonsági mentést és visszaállítást használnak tárolási pillanatképekalapján. A hagyományos SQL Server biztonsági mentési technológiával a nagyobb adatbázisoknak hosszú mentési és visszaállítási ideje van. A snapshotok használatával a Hyperscale azonnali mentési és gyors visszaállítási lehetőségeket biztosít az adatbázis méretétől függetlenül. További információ: rugalmas skálázású biztonsági másolatok.

Biztonsági mentés gyakorisága

Az Azure SQL Database a következőket hozza létre:

• Teljes biztonsági mentés minden héten.
• Inkrementális biztonsági mentések 12 vagy 24 óránként.
• A tranzakciónaplók biztonsági mentése körülbelül 10 percenként történik.

A tranzakciónapló mentéseinek pontos gyakorisága a számítási mérettől és az adatbázis aktivitásának mértékétől függ. Amikor egy adatbázist visszaállítasz, az Azure SQL Database dönti el, mely teljes, differenciális és tranzakciós naplókat kell visszaállítani.

A Hyperscale architektúra nem igényel teljes, differenciális vagy naplómentést. További információ: rugalmas skálázású biztonsági másolatok.

Biztonsági mentési tárhely redundancia

A tároló redundancia mechanizmus több példányt tárol az adataidból, így védve van a tervezett és nem tervezett eseményektől. Ezek az események lehetnek átmeneti hardverhibák, hálózati vagy áramkimaradások, vagy súlyos természeti katasztrófák.

Alapértelmezés szerint az Azure SQL Database-ben lévő új adatbázisok biztonsági mentéseiket georedundáns tárolóblobokban tárolják, amelyeket egy párosított régióba replikálnak. A georedundancia segít megvédeni az elsődleges régióban lévő biztonsági mentési tárterületet érintő kimaradások ellen. Emellett lehetővé teszi az adatbázisok visszaállítását egy másik régióban regionális leállás esetén.

Az Azure portal egy munka környezet lehetőséget biztosít, amely segít előre beállítani bizonyos konfigurációs beállításokat. Felülírhatod ezeket a beállításokat. Ez az opció csak a SQL Database létrehozása portáloldalra vonatkozik.

• A fejlesztési számítási feladatok környezetének kiválasztásával a Backup storage redundancia beállítást állítja be helyileg redundáns tárolás használatára. A helyileg redundáns tárolás kevesebb költséggel jár, és olyan előgyártás előtti környezetekhez megfelelő, amelyek nem igénylik a zóna- vagy georeplikált tárolás redundanciát.
• Éles terheléses környezet kiválasztásakor a biztonsági mentés tárhely redundanciája georedundáns tárolásként van beállítva, ami az alapértelmezett érték.
• A Workload környezet opció megváltoztatja a számítási kezdeti beállítást is, bár ezt felülírhatod. Ellenkező esetben a Munkaterhelés környezet beállítás nincs hatással a licencelésre vagy más adatbázis-konfigurációs beállításokra.

Annak érdekében, hogy a biztonsági mentések ugyanabban a régióban maradjanak, ahol az adatbázis telepítve van, változtasd a biztonsági mentési tároló redundanciáját az alapértelmezett georedundáns tárolóról más típusú tárolókra, amelyek az adataidat a régióban tárolják. A konfigurált biztonsági mentési tárredundancia a rövid távú adatmegőrzési (STR) és az LTR biztonsági mentésekre egyaránt érvényes. A tárolóredundanciáról további információt az Adatredundanciacímű témakörben talál.

A biztonsági mentési tároló redundanciáját beállíthatod, amikor létrehozod az adatbázisodat, és később frissítheted. A meglévő adatbázisban végrehajtott változtatások csak a jövőbeli mentésekre vonatkoznak. Egy meglévő adatbázis biztonsági mentési tárterületének frissítése után a módosítások alkalmazása akár 48 órát is igénybe vehet.

A biztonsági mentésekhez a következő tárolási redundanciák közül választhat:

• Helyileg redundáns tárolás (LRS): A biztonsági másolatokat szinkron módon háromszor másolja az elsődleges régió egyetlen fizikai helyére. Az LRS a legolcsóbb tárolási lehetőség, de nem ajánlott olyan alkalmazásokhoz, amelyek regionális kimaradásokkal ellenállóvá vagy magas adattartósságra való garanciát igényelnek.

  

• zónaredundáns tárolás (ZRS): A biztonsági másolatokat szinkron módon másolja át az elsődleges régió három Azure rendelkezésre állási zónájában. Jelenleg csak bizonyos régiókban érhető el.

  

• georedundáns tárolás (GRS): A biztonsági másolatokat szinkronizálva háromszor másolja az elsődleges régió egyetlen fizikai helyére az LRS használatával. Ezután az adatokat aszinkron módon háromszor másolja egyetlen fizikai helyre a párosított másodlagos régióban.

  Az eredmény a következő:

  • Három szinkron másolat az elsődleges régióban.
  • Három szinkron példány a párosított régióban, amelyeket aszinkron módon másoltak át az elsődleges régióból a másodlagos régióba.

  

• Geo-Zone redundáns tárolás (GZRS):: A geozónaredundáns tárolás (GZRS) egyesíti a rendelkezésre állási zónák közötti redundancia által biztosított magas rendelkezésre állást a georeplikálás (GRS) által biztosított regionális kimaradások elleni védelemmel. A GZRS-ben az Azure szinkronban másolja a biztonsági mentéseket három Azure elérhetőségi zónában az elsődleges régióban, és aszinkron módon háromszor egyetlen fizikai helyre a páros másodlagos régióban.

  A Microsoft a GZRS használatát javasolja olyan alkalmazásokhoz, amelyek maximális konzisztenciát, tartósságot és rendelkezésre állást, kiváló teljesítményt és rugalmasságot igényelnek a vészhelyreállításhoz.

  Az eredmény a következő:

  • Három szinkron példány az elsődleges régió rendelkezésre állási zónáiban.

  • Három szinkron példány a párosított régióban, aszinkron módon átmásolva az elsődleges régióból a másodlagos régióba.

    Az alábbi diagram bemutatja, hogyan replikálja az adatokat a GZRS vagy az RA-GZRS használatával:

  

Figyelmeztetés

• A földrajzi visszaállítás le lesz tiltva, amint az adatbázis helyileg redundáns vagy zónaredundáns tárolást kezd használni.
• A tárterületredundancia-diagramok mindegyike több rendelkezésre állási zónával (multi-az) rendelkező régiókat jelenít meg. Azonban egyes régiók csak egyetlen elérhetőségi zónát biztosítanak, és nem támogatják a ZRS-t.
• A Hyperscale adatbázisok biztonsági mentési redundanciáját csak a létrehozás során állíthatod be. Ezt a beállítást az erőforrás kiépítése után nem módosíthatja. A meglévő Hyperscale adatbázis biztonsági mentési redundanciabeállításainak frissítéséhez minimális állásidővel használja az aktív georeplikációt. Alternatívaként használhatja a adatbázis-másolatát. További információ rugalmas skálázású biztonsági mentésekről és a tárolóredundanciákról.

Biztonsági mentés használata

Használj automatikusan létrehozott biztonsági mentéseket az alábbi helyzetekben:

• Meglévő adatbázis visszaállítása a megőrzési időszakon belül időpontra az Azure Portal, az Azure PowerShell, az Azure CLI vagy a REST API használatával. Ez a művelet egy új adatbázist hoz létre ugyanazon a kiszolgálón, mint az eredeti adatbázis, de más nevet használ az eredeti adatbázis felülírásának elkerülése érdekében.

  A visszaállítás befejezése után szükség esetén törölheti az eredeti adatbázist, és átnevezheti a visszaállított adatbázist az eredeti adatbázis nevére. Másik lehetőségként az eredeti adatbázis törlése helyett átnevezheti, majd átnevezheti a visszaállított adatbázist az eredeti adatbázisnévre.

• Törölt adatbázis visszaállítása a megőrzési időszakon belül időpontra, beleértve a törlés időpontját is. A törölt adatbázist csak azon a szerveren tudod visszaállítani, ahol az eredeti adatbázist létrehoztad. Mielőtt törölnél egy adatbázist, az Azure SQL Database készít egy végső tranzakciónapló mentést, hogy megakadályozza az adatvesztést.

• Adatbázis visszaállítása egy másik földrajzi régióba. A Geo-Restore segít egy regionális kimaradásból való helyreállításban, amikor nem tudsz hozzáférni az adatbázisodhoz vagy a biztonsági mentésedhez az elsődleges régióban. Létrehoz egy új adatbázist bármely Azure-régió meglévő kiszolgálóján.

  Fontos

  A földrajzi visszaállítás csak azokhoz az adatbázisokhoz érhető el, amelyek georedundáns biztonsági mentési tárolóval vannak konfigurálva. Ha jelenleg nem használsz geo-replikált biztonsági mentéseket adatbázishoz, ezt a beállítást módosíthatod a biztonsági mentés redundanciájának konfigurálásával.

• Állítsd vissza az adatbázist egy specifikus, hosszú távú biztonsági mentésből egyetlen vagy csoportos adatbázisról, ha az adatbázis LTR szabályzattal van konfigurálva. Az LTR lehetővé teszi az adatbázis egy régebbi verziójának visszaállítását az Azure Portal, az Azure CLI vagy az Azure PowerShell használatával a megfelelőségi kérések teljesítéséhez vagy az alkalmazás egy régebbi verziójának futtatásához. További információ: Hosszú távú megőrzés.

Figyelmeztetés

Amikor egy adatbázist visszaállítanak, és a forrás biztonsági mentési tároló redundanciája Geo-Zone Redundáns Tárolás (GZRS) módjára van konfigurálva, az új adatbázis örökli a forrás biztonsági mentési tároló konfigurációját, ha nem határozzuk meg kifejezetten a biztonsági mentési tároló redundancia-konfigurációját. Ez az öröklődés bármely helyreállítási műveletre vonatkozik, például adott időpontra történő helyreállításra, adatbázis másolására, geográfiai helyreállításra és hosszú távú biztonsági mentésből történő helyreállításra. Ezen művelet során, ha a cél Azure régió nem támogatja a konkrét biztonsági mentési tároló redundanciáját, a visszaállítási művelet megfelelő hibaüzenettel bukik meg. Ezt a hibát úgy mérsékelheted, hogy kifejezetten megadod a régió elérhető tárolólehetőségeit.

Automatikus biztonsági mentések másodlagos replikákon

A Business Critical szolgáltatási szint automatikus mentéseket vesz fel egy másodlagos replikáról. Mivel az adatok az egyes csomópontokon futó SQL Server-folyamatok között replikálódnak, a biztonsági mentési szolgáltatás a nem olvasható másodlagos replikákról készít biztonsági másolatot. Ez a kialakítás biztosítja, hogy az elsődleges replika a fő terhelés számára legyen dedikált, az olvasható másodlagos replika pedig olvasási feladatok számára legyen dedikált. Az üzletileg kritikus szolgáltatási szint automatikus biztonsági mentései általában egy másodlagos replikából származnak. Ha egy automatikus mentés meghibásodik egy másodlagos replikán, a biztonsági mentés szolgáltatás átveszi a mentést az elsődleges másolattól.

Automatikus biztonsági mentések másodlagos replikákon:

• Alapértelmezés szerint engedélyezve van.
• A szolgáltatási szint árán túl nem járnak további költségek.
• Jobb teljesítmény és kiszámíthatóság biztosítása az üzletileg kritikus szolgáltatási szinten.

Jegyzet

Hozzon létre egy hibajegyet a Microsoft támogatási rendszerében a funkció letiltásához az ön példányán.

Képességek és funkciók visszaállítása

Ez a táblázat az időponthoz kötött visszaállítás (PITR), georestoreés hosszú távú megőrzésiképességeit és funkcióit foglalja össze.

A helyreállítási időkről szóló információért lásd a RTO és RPO.

A biztonsági mentés tulajdonsága	PITR	Geográfiai helyreállítás	LTR
SQL biztonsági mentési típusai	Teljes, differenciális, napló.	A PITR biztonsági másolatainak legutóbbi georeplikált másolatai.	Csak a teljes biztonsági másolatok.
Megőrzés	Alapértelmezés szerint 7 nap, 1 és 35 nap között konfigurálható (kivéve az alapszintű adatbázisokat, amelyek 1 és 7 nap között konfigurálhatók).	Alapértelmezés szerint engedélyezve van, ugyanaz, mint a forrás.2	Alapértelmezés szerint nincs engedélyezve. A megőrzés legfeljebb 10 év.
Azure Storage	Alapértelmezés szerint georedundáns. Igény szerint zónaredundáns vagy helyileg redundáns tárolást is konfigurálhat.	Akkor érhető el, ha a PITR biztonsági mentési tárhelyredundancia georedundáns vagy georégió redundáns (GZRS) értékre van állítva. Nem érhető el, ha a PITR biztonsági mentési tároló zónaredundáns vagy helyileg redundáns.	Alapértelmezés szerint georedundáns. Zónaredundáns vagy helyileg redundáns tárolást is konfigurálhat.
Biztonsági másolatok konfigurálása nem módosítható	Nem támogatott	Nem támogatott	Supported
Ugyanabban a régióban lévő új adatbázis visszaállítása	Támogatott	Támogatott	Támogatott
Új adatbázis visszaállítása egy másik régióban	Nem támogatott	Bármely Azure-régióban támogatott	Bármely Azure-régióban támogatott
új adatbázis visszaállítása egy másik előfizetésben	Nem támogatott	Nem támogatott3	Nem támogatott3
Visszaállítás az Azure portálon	Igen	Igen	Igen
A visszaállítás a PowerShell segítségével	Igen	Igen	Igen
A visszaállítás az Azure CLI-vel	Igen	Igen	Igen

¹ Olyan üzletileg kritikus fontosságú alkalmazásokhoz, amelyek nagy adatbázisokat igényelnek, és biztosítaniuk kell az üzletmenet folytonosságát, használja feladatátvételi csoportokat.
² Az összes PITR-biztonsági mentés alapértelmezés szerint georedundáns tárolón van tárolva, így a georedundáns visszaállítás alapértelmezés szerint engedélyezve van.
³ A megoldás az, hogy a kiszolgálót visszaállítja egy új szerverre, majd az Erőforrás-áthelyezés funkcióval áthelyezi egy másik előfizetésbe, vagy használ egy előfizetések közötti adatbázis-másolatot.

Adatbázis visszaállítása biztonsági másolatból

További információért az adatbázis visszaállításáról lásd: Adatbázis visszaállítása biztonsági mentésekből. A biztonsági mentés konfigurációjának és helyreállítási műveletek felfedezéséhez használja az alábbi példákat.

Művelet	Azure Portal	Azure CLI (Az Azure parancssori felülete)	Azure PowerShell
Biztonsági mentés megőrzésének módosítása	SQL-adatbázis Felügyelt SQL-példány	SQL-adatbázis Felügyelt SQL-példány	SQL-adatbázis Felügyelt SQL-példány
Biztonsági másolatok hosszú távú megőrzésének módosítása	SQL-adatbázis Felügyelt SQL-példány	SQL-adatbázis Felügyelt SQL-példány	SQL-adatbázis Felügyelt SQL-példány
Adatbázis visszaállítása egy adott időpontra	SQL-adatbázis Felügyelt SQL-példány	SQL-adatbázis Felügyelt SQL-példány	SQL-adatbázis Felügyelt SQL-példány
Törölt adatbázis visszaállítása	SQL-adatbázis Felügyelt SQL-példány	SQL-adatbázis Felügyelt SQL-példány	SQL-adatbázis Felügyelt SQL-példány

Jegyzet

A rugalmas skálázású szolgáltatási szint és a Azure SQL Database egyéb szolgáltatási szintjei közötti adatbázisok visszaállítása jelenleg nem támogatott.

Adatbázis exportálása

Nem lehet letölteni vagy közvetlenül hozzáférni az Azure szolgáltatás által készített automatikus biztonsági mentésekhez. Az Azure csak ezeket a biztonsági mentéseket használja helyreállítási műveletekhez.

Azure SQL Database exportálásához fontold meg más alternatívákat.

• Ha exportálni kell egy adatbázist archiválás vagy másik platformra áthelyezéshez, exportáld az adatbázis sémáját és adatait egy BACPAC fájlba. A BACPAC-fájlok olyan ZIP-fájlok, amelyek a BACPAC kiterjesztésével tartalmazzák az adatbázis metaadatait és adatait. Tárolhatsz BACPAC fájlt Azure Blob tárolóban vagy helyi tárolóban egy helyi helyen. Később visszaimportálhatod az Azure SQL Database-ba, Azure SQL Managed Instance-ba vagy egy SQL Server instance-ba.
• Az Azure SQL Database importálását vagy exportálását is elvégezheti privát hivatkozással, vagy úgy importálhat vagy exportálhat Azure SQL Database-adatbázist, hogy az Azure-szolgáltatások nem férhetnek hozzá a kiszolgálóhoz.

Biztonsági mentés ütemezése

Az első teljes mentést közvetlenül azután ütemezik, hogy létrehozol vagy visszaállítasz egy új adatbázist. Ez a biztonsági mentés általában 30 percen belül befejeződik, de az adatbázis nagy méretű példánya hosszabb időt vehet igénybe. Például az első mentés tovább tarthat egy visszaállított adatbázisban vagy egy adatbázis másolatán.

Az első teljes mentés után az Azure automatikusan ütemezi és kezeli az összes további mentést. Az SQL Database szolgáltatás határozza meg az összes adatbázis-biztonsági mentés pontos időzítését, mivel kiegyensúlyozza az egész rendszerterhelést. Nem módosíthatja a biztonsági mentési feladatok ütemezését, és nem tilthatja le őket.

Fontos

• Új, helyreállított vagy másolt adatbázis esetén az időpont szerinti visszaállítási lehetőség akkor válik elérhetővé, amikor a kezdeti teljes biztonsági mentést követően létrejön az első tranzakciónapló-mentés.
• A rugalmas skálázású adatbázisok közvetlenül a létrehozás után védettek, ellentétben más adatbázisokkal, ahol a kezdeti biztonsági mentés időt vesz igénybe. A védelem azonnali akkor is, ha a hiperskála adatbázist nagy mennyiségű adattal hozták létre másolás vagy visszaállítás útján. További információért lásd: Hyperscale automatizált mentések.

Biztonsági mentés tárhely felhasználása

Az SQL Server biztonsági mentési és visszaállítási technológiájával az adatbázisok időben történő visszaállítása megszakítás nélküli biztonsági mentési láncot igényel. Ez a lánc egy teljes biztonsági mentésből, opcionálisan egy különbségi biztonsági mentésből és egy vagy több tranzakciónapló-biztonsági mentésből áll.

Az Azure SQL Database hetente egy teljes biztonsági mentést ütemez. Ahhoz, hogy a teljes megőrzési időszak alatt biztosítható legyen a PITR, az Azure-nak további teljes, differenciális és tranzakciónapló-mentéseket kell tárolnia a konfigurált megőrzési időszaknál legfeljebb egy héttel hosszabb ideig.

Más szóval, a megőrzési időszak bármely pontján teljes biztonsági mentésnek kell lennie, amely régebbi, mint a megőrzési időszak legrégebbi időpontja. Különbségi napló- és tranzakciónapló-mentések megszakítás nélküli láncolatának kell lennie a teljes biztonsági mentéstől a következő teljes biztonsági mentésig.

A rugalmas skálázású adatbázisok más biztonsági mentésütemezési mechanizmust használnak. További információ: Rugalmas skálázású biztonsági mentés ütemezése.

Az Azure automatikusan törli azokat a biztonsági mentéseket, amelyekre már nincs szükség a PITR funkciók biztosításához. Mivel a differenciális mentések és naplómentések egy korábbi teljes mentést igényelnek a visszaállításhoz, az Azure heti készletekben töröli mindhárom biztonsági mentési típust.

Minden adatbázisnál, beleértve a TDE-kódolt adatbázisokat is, az Azure tömöríti az összes teljes és differenciális biztonsági mentést, hogy csökkentse a biztonsági mentés tárolási tömörítését és költségeit. A biztonsági mentés átlagos tömörítési aránya három-négyszeres. Az adatok jellegétől és az adatbázis adattömörítésétől függően azonban alacsonyabb vagy magasabb is lehet.

Fontos

TDE-titkosított adatbázisok esetén az Azure teljesítmény miatt nem tömöríti a napló biztonsági mentéseket. A nem TDE-titkosított adatbázisok esetén a naplómentések tömörítettek.

Az Azure SQL Database összegző értékként számítja ki a teljes felhasznált biztonsági mentési tárterületet. Az Azure óránként jelenti ezt az értéket a számlázási csővezetéknek. Az adatfolyam felelős az óránkénti fogyasztási adatok összesítéséért, hogy minden hónap végén kiszámítsa a fogyasztást. Miután törölsz egy adatbázist, a fogyasztás csökken, ahogy a mentések elörülnek és törlődnek. Miután az összes biztonsági mentés törölve lett, és a PITR már nem lehetséges, a számlázás leáll.

Fontos

Az Azure megőrzi az adatbázis biztonsági mentését, hogy PITR biztosítsa, még akkor is, ha törlöd az adatbázist. Bár az adatbázisok törlése és újra létrehozása tárolási és számítási költségeket takaríthat meg, növelheti a biztonsági mentés tárolási költségeit. Ennek oka, hogy az Azure minden törölt adatbázishoz minden törléskor megőrzi a biztonsági mentéseket.

Fogyasztás figyelése

Az Azure SQL Database vCore adatbázisainál az adatbázis-monitorozó panel külön metrikaként jelenti azt a tárolót, amelyet minden biztonsági mentéstípus (teljes, differenciális és napló) fogyaszt. Az alábbi képernyőkép bemutatja, hogyan monitorozhat biztonsági mentési tárterület-felhasználást egyetlen adatbázis esetében.

A Hyperscale fogyasztás monitorozásával kapcsolatos utasításokért lásd Hyperscale biztonsági mentési fogyasztás figyelése.

A biztonsági másolatok tárolási felhasználásának finomhangolása

Az adatbázis maximális méretéig nem számítunk fel díjat a biztonsági mentések tárolásáért. A biztonsági mentések tárhelyhasználatának csökkentése érdekében érdemes megfontolni az alábbi finomhangolási technikák közül néhányat:

• Csökkentse a biztonsági mentés megőrzési időtartamát a minimálisra az igényeinek megfelelően.
• A szükségesnél gyakrabban kerülje a nagy írási műveleteket, például az indexek újraépítését.
• Nagy adatbetöltési műveletek esetén fontolja meg csoportosított oszlopcentrikus indexek használatát, és kövesse a kapcsolódó ajánlott eljárásokat. Fontolja meg a nem klaszterelt indexek számának csökkentését is.
• Az általános célú szolgáltatási szinten a kiépített adattárolás olcsóbb, mint a biztonsági mentési tár ára. Ha folyamatosan magas a többletes biztonsági mentési tárolási költség, fontold meg az adattárolás növelését, hogy spórolj a biztonsági mentésen.
• Az alkalmazáslogikában állandó táblák helyett tempdb használjon ideiglenes eredmények vagy átmeneti adatok tárolására.
• Ha lehetséges, helyileg redundáns biztonsági mentési tárolót használjon (például fejlesztői/tesztelési környezetek).

Biztonsági mentés megőrzés

Az Azure SQL Database a biztonsági másolatok rövid és hosszú távú megőrzését is biztosítja. A rövid távú megőrzés lehetővé teszi a PITR-t az adatbázis megőrzési időszakán belül. A hosszú távú megőrzés biztonsági másolatokat biztosít a különböző megfelelőségi követelményekhez.

Rövid távú megtartás

Minden új, visszaállított és másolt adatbázis esetén az Azure SQL Database elegendő biztonsági mentést tart fenn ahhoz, hogy alapértelmezés szerint az utolsó hét napban engedélyezze a PITR futtatását. Az Azure SQL Database rendszeres, teljes, differenciális és napló mentéseket készít annak érdekében, hogy az adatbázisok bármely időpontban visszaállíthatók legyenek az adatbázis megőrzési időszakán belül.

Be lehet állítani a differenciális mentéseket 12 óránként, vagy akár 24 óránként. A 24 órás különbségi biztonsági mentés gyakorisága növelheti az adatbázis visszaállításához szükséges időt, szemben a 12 órás gyakorisággal. A virtuális mag modellben a különbségi biztonsági mentések alapértelmezett gyakorisága 12 órán belül egyszer történik. A DTU-modellben az alapértelmezett gyakoriság 24 órán belül egyszer lesz.

Megadhatod a biztonsági mentési tároló redundancia opciót az STR-re, amikor létrehozod az adatbázist, majd később módosíthatod. Ha megváltoztatod a biztonsági mentés redundancia opcióját egy meglévő adatbázison, az új biztonsági mentések az új redundancia opciót használják. Az Azure nem mozgatja vagy másolja a korábbi rövid távú redundancia opcióval készült biztonsági mentéseket. Az Azure az eredeti tárolófiókban hagyja őket, amíg a megtartási időszak lejár, ami 1-től 35 napig terjedhet.

Az alapszintű adatbázisok kivételével 1 és 35 nap között módosíthatja az egyes aktív adatbázisok biztonsági mentési megőrzési időtartamát, kivéve az alapszintű adatbázisokat, amelyek 1 és 7 nap között konfigurálhatók. Az biztonsági mentési tárhasználatileírtak szerint a PITR engedélyezéséhez tárolt biztonsági másolatok régebbiek lehetnek a megőrzési időszaknál. Ha a biztonsági másolatokat a 35 napos maximális rövid távú megőrzési időtartamnál hosszabb ideig kell megőriznie, a hosszú távú megőrzést engedélyezheti.

Ha törlök egy adatbázist, az Azure ugyanúgy tartja meg a biztonsági mentéseket egy adott online adatbázisnál, amelynek megőrzési ideje van. A törölt adatbázisok biztonsági mentési megőrzési idejét nem módosíthatja.

Fontos

Ha törlök egy logikai Azure SQL szervert, akkor az összes logikai szerveren lévő adatbázist is törölöd. Nem lehet visszaállítani törölt adatbázisokat. Nem lehet visszaállítani egy törölt logikai szervert. De ha hosszú távú megőrzést konfiguráltál egy adatbázishoz, az LTR biztonsági mentések nem törülnek. Ezt követően ezeket a biztonsági mentéseket felhasználhatja adatbázisok visszaállítására egy másik logikai kiszolgálón, ugyanabban az előfizetésben, arra az időpontra, amikor az LTR biztonsági mentés készült. További információért lásd: Hosszú távú mentés visszaállítása.

Hosszú távú megőrzés

Az SQL Database esetében akár 10 évig is konfigurálhat teljes hosszú távú adatmegőrzési (LTR) biztonsági mentéseket az Azure Blob Storage-ban. Miután beállítottad az LTR szabályzatot, az Azure heti rendszerességgel másolja a teljes biztonsági mentéseket egy másik tárolótárolóba.

A különböző megfelelőségi követelmények teljesítéséhez válasszon különböző megtartási időszakokat a heti, havi és éves teljes biztonsági mentésekhez. A gyakoriság a szabályzattól függ. Például a beállítás W=0, M=1 havonta létrehoz egy LTR másolatot. További információ az LTR-ről, lásd: Hosszú távú megőrzés.

A meglévő adatbázis biztonsági mentési redundanciájának frissítése csak a jövőben készült biztonsági mentésekre vonatkozik, nem a meglévő biztonsági mentésekre. Az adatbázis összes meglévő LTR-biztonsági mentése továbbra is a meglévő tárolóblobban található. Az új biztonsági másolatok replikálása a biztonsági mentési tár konfigurált redundancián alapul.

A tárterület-felhasználás az LTR-biztonsági mentések kiválasztott gyakoriságától és megőrzési idejétől függ. Használd az LTR árkalkulátort az LTR tárolás költségének becslésére.

Ha rugalmas skálázású adatbázist állít vissza egy LTR biztonsági másolatból, az olvasási skálázási tulajdonság le van tiltva. Az engedélyezéshez olvassa el a skálázást a visszaállított adatbázison, majd a létrehozás után frissítse az adatbázist. Az LTR biztonsági mentésből való visszaállításhoz meg kell adnia a cél szolgáltatási szint célkitűzését.

Hosszú távú megtartást engedélyezhetsz a Hyperscale adatbázisok esetében, amelyeket más szolgáltatási szintekről hoztak létre vagy migráltak. Ha olyan rugalmas skálázású adatbázisok esetében próbálja engedélyezni az LTR-t, amely még nem támogatott, a következő hibaüzenet jelenik meg: "Hiba történt az adatbázis hosszú távú biztonsági mentésének engedélyezése során. Kérjük, vegye fel a kapcsolatot a Microsoft ügyfélszolgálatával, hogy hosszú távú biztonsági mentést tegyen lehetővé." Ebben az esetben vegye fel a kapcsolatot a Microsoft ügyfélszolgálatával, és hozzon létre egy támogatási jegyet a megoldáshoz.

A biztonsági mentés tárolási költségei

A biztonsági mentési tár ára a vásárlási modelltől (DTU vagy virtuális mag), a választott biztonsági mentési tár redundancia lehetőségétől és régiójától függ. A biztonsági mentési tárhelyért a havonta felhasznált gigabájtok alapján fizet, minden biztonsági mentés esetén azonos díjszabással.

A díjszabást az Azure SQL Database díjszabási oldalán talál.

Jegyzet

Az Azure-számlák csak a túlzott biztonsági mentési tárterület-felhasználást jelenítik meg, a teljes biztonsági mentési tárterület-felhasználást nem. Például egy hipotetikus esetben, ha 4 TB adattárhelyet biztosítasz, 4 TB szabad biztonsági mentési helyet kapsz. Ha összesen 5,8 TB biztonsági mentési tárhelyet használsz, az Azure számlája csak 1,8 TB-ot mutat, mert csak a felesleges biztonsági mentésért fizetsz.

DTU-modell

A DTU modellben adatbázisok és rugalmas poolok esetén nincs plusz díj a PITR biztonsági mentésért az alapértelmezett hét napos vagy annál tovább tartó megőrzés esetén. A PITR biztonságimentés-tárolás ára az adatbázis vagy a pool árának része.

A DTU-modellben az adatbázisok és az elasztikus készletek LTR biztonsági mentési tárhelyéért az LTR biztonsági másolatok által ténylegesen felhasznált tárterület alapján fizet.

vCore modell

Az Azure SQL Database a teljes számlázható biztonsági mentési tárolót összegző értékként számolja ki minden biztonsági mentési fájl között. Az Azure óránként elküldi ezt az értéket a számlázási csővezetéknek. A pipeline ezt az óránként történő felhasználást aggregálja, hogy meghatározza a biztonsági mentés tárolási fogyasztását minden hónap végén.

Ha töröl egy adatbázist, a biztonsági mentések által használt tárterület fokozatosan csökken, ahogy a régebbi biztonsági mentések megőrzési ideje lejár, és törlődnek. Mivel a differenciális mentések és naplómentések egy korábbi teljes mentést igényelnek a visszaállításhoz, az Azure heti készletekben töröli mindhárom biztonsági mentési típust. Az összes biztonsági mentés törlése után a számlázás leáll.

A hiperskálázású adatbázisok más módszert használnak a biztonsági mentési tárolási költségek számítására. További információ: rugalmas skálázású biztonsági mentés tárolási költségei.

Egyetlen adatbázisok esetén a biztonsági mentési kapacitás megegyezik az adatbázis maximális adattároló méretével, plusz költség nélkül. A következő egyenlet számolja ki a teljes számlázható tartalék tároló felhasználását:

Total billable backup storage size = (size of full backups + size of differential backups + size of log backups) – maximum data storage

Rugalmas medencék esetén egy biztonsági mentési kapacitást kapsz, ami megegyezik a pool tároló maximális adattárhelyével, plusz díj nélkül. A készletezett adatbázisok esetében a számlázható biztonsági mentési tár teljes mérete a készlet szintjén összesítve lesz, és a következőképpen lesz kiszámítva:

Total billable backup storage size = (total size of all full backups + total size of all differential backups + total size of all log backups) - maximum pool data storage

A teljes számlázható biztonsági mentésért havi gigabájtban fizeted a tartalék redundanciától függően. Ez a biztonsági mentési tárterület-felhasználás az egyes adatbázisok, rugalmas készletek és felügyelt példányok számítási feladatától és méretétől függ. Az erősen módosított adatbázisok nagyobb különbségi és naplóbeli biztonsági mentésekkel rendelkeznek, mivel ezeknek a biztonsági másolatoknak a mérete arányos a módosított adatok mennyiségével. Ezért az ilyen adatbázisok magasabb biztonsági mentési díjakkal rendelkeznek.

Egyszerűsített példaként tegyük fel, hogy egy adatbázis 744 GB biztonsági mentést halmoz fel, és ez az összeg egy egész hónapon át állandó marad, mert az adatbázis teljesen üres. Ha ezt az összesített tárterület-felhasználást óránkénti használatra szeretné konvertálni, ossza el 744,0-ra (havonta 31 nappal, naponta 24 órával). Az SQL Database jelenti az Azure számlázási folyamatának, hogy az adatbázis óránként 1 GB PITR biztonsági mentést használt fel állandó sebességgel. Az Azure számlázás összesíti ezt a fogyasztást, és az egész hónapban 744 GB felhasználást mutat. A költség a régióban havi gigabájtonkénti díjszabáson alapul.

Íme egy másik példa. Tegyük fel, hogy ugyanannak az inaktív adatbázisnak a megőrzési ideje 7 napról 14 napra nőtt a hónap közepén. Ez a növekedés azt eredményezi, hogy a teljes biztonsági mentési tárterület 1488 GB-ra megduplázható. Az SQL Database az 1-től 372-ig terjedő órákra 1 GB használatot jelez (a hónap első felében). A használatot 2 GB-nak jelzi 373-tól 744-ig (a hónap második felében). Ez a felhasználás összegződik a havi 1 116 GB végső számlához.

A tényleges biztonsági mentés számlázási forgatókönyvei összetettebbek. Mivel az adatbázis változásainak üteme a terheléstől függ és idővel változik, a differenciálok és naplómentések mérete is változik. A biztonsági mentési tár óránkénti felhasználása ennek megfelelően ingadozik.

Minden különbségi biztonsági mentés tartalmazza az adatbázisban az utolsó teljes biztonsági mentés óta végrehajtott összes módosítást is. Így az összes különbségi biztonsági mentés teljes mérete fokozatosan növekszik egy hét alatt. Ezután élesen csökken, amikor egy régebbi teljes, különbségi és naplóbiztonsági másolatok készlete elavul.

Tegyük fel például, hogy egy erős írási tevékenység, például egy index újraépítése közvetlenül a teljes biztonsági mentés befejezése után fut. Az index újjáépítése által végrehajtott módosítások a következők:

• A tranzakciónapló biztonsági másolatait az újraépítés időtartama alatt készítették.
• A következő differenciális biztonsági mentésben.
• Minden különbségi biztonsági mentésben, amelyet a következő teljes biztonsági mentésig készítenek.

Az utóbbi esetben nagyobb adatbázisokban az Azure-ban végzett optimalizáció teljes mentést hoz létre a differenciális mentés helyett, ha egyébként túl nagy lenne. Ez az optimalizáció csökkenti az összes differenciális biztonsági mentés méretét egészen a következő teljes mentésig.

Az egyes biztonsági mentési típusok (teljes, különbözeti, tranzakciónaplók) teljes biztonsági mentési tárhely-fogyasztását idővel figyelheti meg, ahogyan az a Fogyasztás figyelésecímű cikkben le van írva.

Költségek figyelése

A biztonsági mentés tárolási költségeinek megismeréséhez lépjen be a Cost Management + Billing az Azure portálon. Válassza Cost Management, majd a Költségelemzéslehetőséget. Válassza ki a kívánt előfizetést Hatókör, majd szűrjön a kívánt időszakra és szolgáltatásra az alábbiak szerint:

1. Szűrő hozzáadása szolgáltatás neve.

2. A legördülő listában válassza sql database egyetlen adatbázishoz vagy rugalmas adatbáziskészlethez.

3. Adjon hozzá egy másik szűrőt a Mérő alkategóriához.

4. A PITR biztonsági mentési költségeinek figyeléséhez a legördülő listában válassza a egyetlen vagy rugalmas készlet pitr biztonsági mentési tárhely opciót egy egyedi adatbázishoz vagy egy rugalmas adatbáziskészlethez. Csak akkor láthatók a mérőszámok, ha van biztonsági mentési tárhelyhasználat.

   Az LTR biztonsági mentési költségeinek monitorozásához a legördülő listában válassza ltr biztonsági mentési tár egyetlen adatbázishoz vagy rugalmas adatbáziskészlethez. Csak akkor láthatók a mérőszámok, ha van biztonsági mentési tárhelyhasználat.

A Storage és számítási alkategóriák szintén érdekelhetik Önt, de ezek nincsenek társítva a biztonsági mentési tárolási költségekkel.

Fontos

A mérőszámok csak a jelenleg használatban lévő számlálók esetében láthatók. Ha egy számláló nem érhető el, akkor valószínű, hogy a kategória jelenleg nincs használatban. Például a tárolószámlálók nem láthatóak azoknál az erőforrásoknál, amelyek nem fogyasztanak tárolást. Ha nincs PITR vagy LTR tartalék tárolófogyasztás, ezek a mérők nem láthatók.

További információért lásd: az Azure SQL Database költségkezelés.

Titkosított biztonsági másolatok

Ha az adatbázisodat TDE használatával titkosítod, a biztonsági mentések automatikusan titkosítva vannak nyugalmi állapotban, beleértve az LTR mentéseket is. Az Azure SQL minden új adatbázisán alapértelmezés szerint engedélyezve van a TDE. További információért a TDE-ről lásd: Az SQL-adatbázis átlátszó adatvédelme.

Biztonsági mentés integritása

Az Azure SQL Database automatikusan kezeli bizonyos típusú adatkorrupciókat, szükség esetén beépített technikákat alkalmazva, adatvesztés nélkül. Az Azure SQL Database-ben az SQL Database Engine oldalellenőrzést végez a szolgáltatás által menedzselt biztonsági mentések során és minden helyreállítási művelet során. Az integritás-ellenőrzés során észlelt problémák riasztást eredményeznek a mérnöki csapatnak.

További védelmi rétegként tesztelheted a biztonsági mentés visszaállítását és az integritás-ellenőrzéseket. További információért lásd: Data integrity in Azure SQL Database.

Minden adatbázis-biztonsági mentés ezt CHECKSUM a lehetőséget használja, hogy extra biztonsági mentést biztosítson.

Biztonsági másolatok védelme

A Microsoft tulajdonában lévő Azure előfizetések biztonságos, belső Azure Storage fiókok használatával kezelik az Azure SQL Database biztonsági mentéseit. Ezekre a biztonsági mentésekre külsőleg nem férsz hozzá, így erős adatszigetelést és védelmet nyújtanak. A Microsoft-on belül csak a háttérszolgáltatások férhetnek hozzá, létrehozhatnak, másolhatnak vagy visszaállíthatják ezeket a biztonsági mentéseket. A Microsoft mérnökei, beleértve a fejlesztőket, nem rendelkeznek állandó hozzáféréssel. Az expozíció minimalizálása és a biztonság maximalizálása érdekében a Microsoft csak akkor szerezhet be Just-In-Time (JIT) hozzáférést szigorú naplózási vezérlők mellett, ha az adott ügyfélproblémák elhárításához feltétlenül szükséges.

A mentések automatikusan törlődnek a megőrzési idő lejártakor.

Megfelelőség a biztonsági másolatok megőrzésén keresztül

Ha az alapértelmezett megtartás nem felel meg a megfelelőségi követelményeknek, változtasd meg a PITR megtartási időszakát. További információ: A PITR biztonsági mentési megőrzési idejének módosítása.

Amikor az adatbázisodat DTU-alapú szolgáltatási szintről vCore alapú szolgáltatási szintre migrálod, a migráció megőrzi a PITR megőrzését, hogy biztosítsa, hogy az alkalmazásod adathelyreállítási politikája ne sérüljön meg.

Jegyzet

Az Azure SQL Database biztonsági mentéseiből való személyes adatok törlésének lépéseiért a GDPR szerinti kötelezettségeid támogatására lásd: Automatikus mentési beállítások módosítása. Az általános GDPR-információkért lásd a Microsoft Megbízhatósági Központ GDPR szakaszát, valamint a Szolgáltatások Megbízhatósági Portálja GDPR szakaszát.

A biztonsági mentési tár redundanciának kényszerítése az Azure Policy használatával

Ha adatrezidencia követelményei vannak, amelyek miatt minden adatodat egyetlen Azure régióban kell tárolnod, akkor az SQL adatbázisodhoz az Azure Policy segítségével kényszerítheted a zónaredundáns vagy helyben redundáns biztonsági mentéseket.

Az Azure Policy olyan szolgáltatás, amellyel szabályokat alkalmazó szabályzatokat hozhat létre, rendelhet hozzá és kezelhet az Azure-erőforrásokra. Az Azure Policy segít abban, hogy ezek az erőforrások megfeleljenek a vállalati szabványainak és szolgáltatási megállapodásainak. További információ: Az Azure Policyáttekintése.

Beépített tárolási redundanciát biztosító biztonsági mentési szabályzatok

Az adatrezidencia követelmények érvényesítéséhez szervezeti szinten rendelj szabályzatokat előfizetéshez az Azure portál vagy az Azure PowerShell használatával.

Például, ha engedélyezed a "Azure SQL DB kerüli a GRS biztonsági mentést" irányelvet, a felhasználók nem hozhatnak létre adatbázisokat az alapértelmezett tárolóval, mint globálisan redundáns tároló. A házirend megakadályozza a felhasználókat a GRS használatában, és a következő hibaüzenetet adja vissza: „A biztonsági mentési tárfiók típusának 'Standard_RAGRS' értékre állítása sikertelen volt az adatbázis létrehozása vagy frissítése során.”

Az SQL Database beépített szabályzatdefinícióinak teljes listájáért lásd a szabályzati hivatkozást.

Fontos

Az Azure szabályzatokat nem érvényesítik, amikor T-SQL-en keresztül adatbázist hozol létre. Az adatrezidencia megadásához, amikor T-SQL segítségével létrehozol adatbázist, használd a LOCAL vagy ZONE bemenetet a BACKUP_STORAGE_REDUNDANCY paraméterhez a CREATE DATABASE utasításban.

Kapcsolódó tartalom

• Az SQL Database üzletmenet-folytonossági megoldásairól további információt megtudhat az Üzletmenet-folytonosság áttekintésecímű részben.
• A biztonsági mentési beállítások módosításáról a Beállítások módosításacímű témakörben olvashat.
• A biztonsági mentés visszaállításához tekintse meg a Helyreállítás biztonsági másolatokkal vagy a Adatbázis visszaállítása egy korábbi időpontra a PowerShellhasználatával.
• Az Azure Blob Storage-beli automatikus biztonsági másolatok hosszú távú megőrzésének konfigurálásáról, kezeléséről és visszaállításáról további információt A hosszú távú biztonsági mentések megőrzésikezelése című témakörben talál.
• Felügyelt Azure SQL-példány esetén lásd: Felügyelt SQL-példányok automatikus biztonsági mentései.