Megosztás a következőn keresztül:


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

A következőkre vonatkozik:Azure SQL Database

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ázisok hosszú biztonsági mentési/visszaállítási idővel rendelkeznek. A pillanatképek használatával a rugalmas skálázás azonnali biztonsági mentési és gyors visszaállítási képessé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:

A tranzakciónaplók biztonsági mentésének pontos gyakorisága a számítási méreten és az adatbázis-tevékenység mennyiségén alapul. Adatbázis visszaállításakor a szolgáltatás határozza meg, hogy mely teljes, differenciális és napló biztonsági mentéseket 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ási redundancia mechanizmus több másolatot tárol az adatokról, hogy azok védve legyen 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 georedundáns tárolóblobokban, 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. Ezeket a beállításokat felül lehet bírálni. 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.
  • A Éles számítási feladat környezetének kiválasztásakor a Backup storage redundancia georedundáns tárolásra állítja, az alapértelmezett értékre.
  • A számítási feladatok környezete beállítás is módosítja a számítás kezdeti beállítását, bár ez felülírható. 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 másolatok ugyanabban a régióban maradjanak, ahol az adatbázis telepítve van, módosíthatja a biztonsági mentési tár redundanciát az alapértelmezett georedundáns tárolásról más típusú tárolókra, amelyek az adatokat a régión belül tartjá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.

Az adatbázis létrehozásakor konfigurálhatja a biztonsági mentési tár redundanciát, és később frissítheti. A meglévő adatbázis módosításai csak a jövőbeli biztonsági 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 legkevésbé költséges tárolási lehetőség, de nem ajánljuk olyan alkalmazásokhoz, amelyek rugalmasságot igényelnek a regionális kimaradásokkal szemben, vagy garantálják a magas adatmegőrzést.

    Helyileg redundáns tárolás (LRS) beállítást bemutató diagram.

  • 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.

    Diagram a zónaredundáns tárolás (ZRS) beállításról.

  • 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 háromszor másolja az adatokat aszinkron módon egyetlen fizikai helyre a párosított másodlagos régióban.

    Az eredmény a következő:

    • Három szinkron példány 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.

    Diagram a georedundáns tárolás (GRS) beállításról.

  • Geo-Zone redundáns tárolás (GZRS): A georedundáns tárolás (GZRS) egyesíti a rendelkezésre állási zónák (ZRS) 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 biztonsági másolatokat szinkron módon másolja az elsődleges régió három Azure rendelkezésre állási zónájában, és aszinkron módon háromszor egyetlen fizikai helyre a párosított 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:

    A diagram a geozónára redundáns tárolási (GZRS) opcióról.

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. Vannak azonban olyan régiók, amelyek csak egyetlen rendelkezésre állási zónát biztosítanak, és nem támogatják a ZRS-t.
  • A rugalmas skálázású adatbázisok biztonsági mentési tárterület-redundanciái csak a létrehozás során állíthatók 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

Az automatikusan létrehozott biztonsági másolatokat a következő esetekben használhatja:

  • 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ázis csak azon a kiszolgálón állítható vissza, ahol az eredeti adatbázist létrehozta. Mielőtt töröl egy adatbázist, a szolgáltatás végleges tranzakciónapló-biztonsági mentést készít az adatvesztés elkerülése érdekében.

  • Adatbázis visszaállítása egy másik földrajzi régióba. A geo-helyreállítás lehetővé teszi a helyreállítást regionális kimaradások esetén, ha nem tud hozzáférni az adatbázishoz vagy a biztonsági másolatokhoz 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ál georeplikált biztonsági mentéseket egy adatbázishoz, ezt módosíthatja a biztonsági mentési tár redundanciakonfigurálásával.

  • Egy egyetlen vagy készletezett adatbázist visszaállítani egy meghatározott hosszú távú biztonsági mentésből, ha az adatbázis egy LTR-szabályzattal lett 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

Az adatbázis visszaállításakor, ha a forrás biztonsági mentési tár redundanciája Geo-Zone Redundáns tárolásként (GZRS) van beállítva, az új adatbázis örökli a forrás biztonsági mentési tár konfigurációját, feltéve, hogy a céladatbázis redundanciakonfigurációja nincs kifejezetten megadva. Ez magában foglal minden visszaállítási műveletet, például időponthoz kötött visszaállítást, adatbázis-másolást, georedukciót, hosszú távú biztonsági mentésből történő visszaállítást. Ebben a műveletben, ha a cél Azure-régió nem támogatja a biztonsági mentési tár adott redundanciát, a visszaállítási művelet megfelelő hibaüzenettel meghiúsul. Ez enyhíthető a régióhoz elérhető tárolási lehetőségek explicit megadásával.

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

Az automatikus biztonsági mentések mostantól egy másodlagos replikából származnak az Üzleti szempontból kritikus szolgáltatásszinten. 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 másodlagos replikán sikertelen az automatikus biztonsági mentés, akkor a biztonsági mentési szolgáltatás az elsődleges replikából veszi át a biztonsági másolatot.

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

  • Alapértelmezés szerint engedélyezve van.
  • A szolgáltatások a szolgáltatási szint árán túl semmilyen további költséggel nem járnak.
  • 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 Microsoft-támogatási jegyet a példány funkciójának letiltásához.

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ár redundanciája georedundánsan van beá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 Nem támogatott
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

1 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.
2 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.
3 A kerülő megoldás az, ha a kiszolgálót egy új kiszolgálóra állítja vissza, majd az Erőforrás áthelyezésével egy másik előfizetésbe helyezi, 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

A visszaállítás végrehajtásához lásd: Adatbázis visszaállítása biztonsági másolatokból. A biztonsági mentés konfigurációját és a visszaállítási műveleteket az alábbi példák segítségével ismerheti meg.

Művelet Azure Portal Azure CLI Azure PowerShell
Biztonsági mentés megőrzésének módosítása SQL Database
felügyelt SQL-példány
SQL adatbázis
SQL-felügyelt példány
Az SQL Database
felügyelt SQL-példány
Biztonsági másolatok hosszú távú megőrzésének módosítása SQL Database
felügyelt SQL-példány
SQL Database
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 Database
felügyelt SQL-példány
SQL Database
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 Database
felügyelt SQL-példány
SQL Adatbázis
Menedzselt SQL-példány

Adatbázis exportálása

Az Azure-szolgáltatás által készített automatikus biztonsági másolatok nem tölthetők le vagy érhetők el közvetlenül. Ezek csak az Azure-on keresztüli visszaállítási műveletekhez használhatók.

Az Azure SQL Database exportálása többféleképpen is lehetséges. Ha archiváláshoz vagy másik platformra való áthelyezéshez szeretne adatbázist exportálni, exportálhatja az adatbázisséma és az adatok 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. A BACPAC-fájlok tárolhatók az Azure Blob Storage-ban vagy a helyi tárolóban egy helyszíni helyen, majd később újra importálhatók Azure SQL Database, Felügyelt Azure SQL-példány, vagy egy SQL Server-példány.

Az Azure SQL Database importálását vagy exportálását is privát hivatkozással vagy Importálhat vagy exportálhat Azure SQL Database-adatbázist anélkül, hogy az Azure-szolgáltatások hozzáférhetnek a kiszolgáló.

Biztonsági mentés ütemezése

Az első teljes biztonsági mentést közvetlenül az új adatbázis létrehozása vagy visszaállítása után ütemezi a rendszer. 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. A kezdeti biztonsági mentés például hosszabb időt vehet igénybe egy visszaállított adatbázison vagy adatbázis-másolaton, amely általában nagyobb, mint egy új adatbázis.

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

Fontos

  • Új, visszaállított vagy másolt adatbázis esetén az időpont szerinti visszaállítási képessé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ó-biztonsági 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 akkor is azonnali, ha a rugalmas skálázású adatbázis nagy mennyiségű adattal lett létrehozva másolással vagy visszaállítással. További információért tekintse át rugalmas skálázású automatikus biztonsági mentéseket.

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 PITR biztosítva legyen a teljes megőrzési időszakon belül, a rendszernek további teljes, differenciális és tranzakciónapló-biztonsági mentéseket kell tárolnia, akár egy héttel a konfigurált megőrzési időszakon túl is.

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 és tranzakciónapló-biztonsági 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.

A PITR-funkciók biztosításához már nem szükséges biztonsági másolatok automatikusan törlődnek. Mivel a különbségi biztonsági mentésekhez és a naplók biztonsági mentéséhez egy korábbi teljes biztonsági mentést kell visszaállítani, a három biztonsági mentési típus heti bontásban lesz eltávolítva.

Az összes adatbázis esetében, beleértve a TDE-titkosítású adatbázisokat is, az összes teljes és különbségi biztonsági mentés tömörítve van, így csökkentve a biztonsági mentések tárolási tömörítését és költségeit. A biztonsági mentések átlagos tömörítési aránya 3–4-szeres. 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

A TDE-titkosított adatbázisok esetében a napló biztonsági mentési fájljai teljesítménybeli okokból nem lesznek tömörítve. A nem TDE-titkosított adatbázisok naplóinak biztonsági mentései tömörítve vannak.

Az Azure SQL Database összegző értékként számítja ki a teljes felhasznált biztonsági mentési tárterületet. Ez az érték óránként megjelenik az Azure számlázási folyamatában. 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. Az adatbázis törlése után a használat csökken, mivel a biztonsági másolatok elavultak é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 adatbázis biztonsági másolatai megmaradnak, hogy a PITR-t akkor is biztosítsák, ha az adatbázist törölték. Bár egy adatbázis törlése és újbóli 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 az az oka, hogy a szolgáltatás minden törölt adatbázishoz megőrzi a biztonsági másolatokat minden törléskor.

Fogyasztás figyelése

Az Azure SQL Database vCore adatbázisok esetében az egyes biztonsági mentési típusok (teljes, különbségi és napló) által használt tárolás külön metrikaként jelenik meg az adatbázis-figyelési panelen. 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.

Képernyőkép, amely az azure portalon az adatbázis biztonsági mentési felhasználásának figyelésére szolgáló kijelöléseket jeleníti meg.

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 adatméretéig történő biztonsági mentési tárhelyhasználatért nem számítanak fel díjat. A túlzott biztonsági mentési tárterület-használat az egyes adatbázisok számítási feladatától és maximális méretétől függ. Fontolja meg az alábbi hangolási technikák némelyikét a biztonsági mentési tárhasználat csökkentése érdekében:

  • 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 a biztonsági mentési tárterület folyamatosan magas költségei vannak, érdemes lehet növelni az adattárolást, hogy csökkentse a biztonsági mentés tárolási költségeit.
  • 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

Az összes új, visszaállított és másolt adatbázis esetében az Azure SQL Database megőrzi a megfelelő biztonsági másolatokat, hogy alapértelmezés szerint engedélyezhesse a PITR-t az elmúlt 7 napon belül. A szolgáltatás rendszeres teljes, különbségi és napló biztonsági mentéseket készít annak érdekében, hogy az adatbázisok bármikor visszaállíthatók legyenek az adatbázishoz meghatározott megőrzési időn belül.

A különbségi biztonsági mentések konfigurálhatók úgy, hogy 12 órán belül egyszer vagy 24 órán belül egyszer történjenek. 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.

Az adatbázis létrehozásakor megadhatja a biztonsági mentési tár redundancia beállítását az STR-hez, majd később módosíthatja azt. Ha az adatbázis létrehozása után módosítja a biztonsági mentés redundancia beállítását, az új biztonsági másolatok az új redundancia lehetőséget használják. Az előző STR-redundancia beállítással készített biztonsági másolatok nem lesznek áthelyezve vagy másolva. Az eredeti tárfiókban maradnak a megőrzési időszak lejártáig, ami 1–35 nap is lehet.

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öröl egy adatbázist, a rendszer ugyanúgy őrzi meg a biztonsági másolatokat egy online adatbázis esetében, annak adott megőrzési időtartamával. A törölt adatbázisok biztonsági mentési megőrzési idejét nem módosíthatja.

Fontos

Ha töröl egy kiszolgálót, a kiszolgálón lévő összes adatbázis is törlődik, és nem állítható helyre. Törölt kiszolgáló nem állítható vissza. Ha azonban hosszú távú adatmegőrzést konfigurált egy adatbázishoz, az LTR biztonsági másolatai nem törlődnek. Ezeket a biztonsági másolatokat ezután egy másik kiszolgálón, ugyanabban az előfizetésben lévő adatbázisok visszaállítására használhatja, egészen addig az időpontig, amikor LTR-biztonsági mentés készült. További információ: Hosszú távú biztonsági 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. Az LTR-szabályzat konfigurálása után a rendszer hetente automatikusan átmásolja a teljes biztonsági másolatokat egy másik tárolóba.

A különböző megfelelőségi követelmények teljesítéséhez különböző megőrzési időtartamokat választhat heti, havi és/vagy éves teljes biztonsági mentésekhez. A gyakoriság a szabályzattól függ. A W=0, M=1 beállítás például 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ázisok biztonsági mentési tárterületének redundanciáinak frissítése csak a későbbi biztonsági mentésekre vonatkozik, a meglévő biztonsági másolatokra nem. 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. A LTR díjszabási kalkulátorát használhatja az LTR-tárterület költségeinek becsléséhez.

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áskor meg kell adnia a célszolgáltatásszint-célkitűzést.

A hosszú távú megőrzés engedélyezhető más szolgáltatási szintekről létrehozott vagy migrált rugalmas skálázású adatbázisokhoz. 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. Forduljon a Microsoft ügyfélszolgálatához a biztonsági mentés hosszú távú megőrzésének engedélyezéséhez." Ebben az esetben lépjen kapcsolatba 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árterület díja a havonta felhasznált gigabájt alapján történik, az összes biztonsági mentés esetében azonos sebességgel.

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. Hipotetikus forgatókönyv esetén például, ha 4 TB adattárolót létesített, 4 TB ingyenes biztonsági mentési tárterületet kap. Ha összesen 5,8 TB biztonsági mentési tárterületet használ, az Azure-számla csak 1,8 TB-ot jelenít meg, mivel csak a felhasznált felesleges biztonsági mentési tárterületért kell fizetnie.

DTU-modell

A DTU-modellben az adatbázisok és rugalmas készletek esetében a PITR biztonsági mentési tárterülete nem számít fel további díjat az alapértelmezett 7 napos és annál újabb megőrzési időért. A PITR biztonsági mentési tárhely ára az adatbázis vagy a készlet árának része.

Fontos

A DTU-modellben az adatbázisok és a rugalmas készletek a LTR biztonsági mentési tárterületért kerülnek felszámításra az LTR-biztonsági mentések által felhasznált tényleges tárterület alapján.

vCore modell

Az Azure SQL Database a teljes számlázható biztonsági mentési tárterületet összegző értékként számítja ki az összes biztonsági mentési fájlban. Ez az érték óránként megjelenik az Azure számlázási folyamatában. A csővezeték összesíti ezt az óránkénti használatot, hogy minden hónap végén meghatározza a biztonsági mentési tárhely fogyasztását.

Ha töröl egy adatbázist, a biztonsági másolatok tárolási felhasználása fokozatosan csökken, ahogy a régebbi biztonsági másolatok elavultak, és törlődnek. Mivel a különbségi biztonsági mentésekhez és a naplók biztonsági mentéséhez egy korábbi teljes biztonsági mentést kell visszaállítani, a három biztonsági mentési típus heti bontásban lesz eltávolítva. Az összes biztonsági mentés törlése után a számlázás leáll.

A biztonsági mentés tárolási költségei a rugalmas skálázású adatbázisok esetében eltérően lesznek kiszámítva. További információ: rugalmas skálázású biztonsági mentés tárolási költségei.

Önálló adatbázisok esetén az adatbázis maximális adattárolási méretének 100%-ának megfelelő biztonsági mentési tárterületet díjmentesen biztosítunk. A rendszer a következő egyenletet használja a teljes számlázható biztonsági mentési tárterület-használat kiszámításához:

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

Rugalmas készletek esetén a készlet tárterületének maximális adattárolójának 100%-ának megfelelő biztonsági mentési tárterületet díjmentesen biztosítunk. 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

Ha van ilyen, a teljes számlázható biztonsági mentési tárterületet gigabájtban számítjuk fel havonta a használt biztonsági mentési tár redundanciája alapján. 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ési tárterületet halmozott fel, és ez az összeg egész hónapban állandó marad, mivel az adatbázis teljesen tétlen. 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 felhasználást, és a teljes hónapra vonatkozóan 744 GB-os használatot jelenít meg. 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 1 GB használatot jelent az 1–372. órában (a hónap első felében). A használatot 2 GB-ként jelenti a 373 és 744 óra között (a hónap második felében). Ez a használat egy havi 1116 GB-os végső számlára lesz összesítve.

A tényleges biztonsági mentés számlázási forgatókönyvei összetettebbek. Mivel az adatbázis változásainak sebessége a számítási feladattól függ, és az idő függvényében változó, az egyes különbségi és napló biztonsági mentések mérete is eltérő lesz. 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 újraépítése során a módosítások majd be lesznek építve.

  • A tranzakciónapló biztonsági másolatait az újraépítés időtartama alatt készítették el.
  • A következő különbségi 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.

A nagyobb adatbázisok utolsó forgatókönyvében a szolgáltatás optimalizálása a különbségi biztonsági mentés helyett egy teljes biztonsági mentést hoz létre, ha a különbségi biztonsági mentés egyébként túlzottan nagy lenne. Ez csökkenti az összes különbségi biztonsági mentés méretét a következő teljes biztonsági 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ásnév.

  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 jelennek meg a mérőszámok, ha van biztonsági mentési tárterület-haszná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. A mérőszámok csak akkor jelennek meg, ha létezik biztonsági mentési tárterület-haszná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.

Képernyőkép a biztonsági mentés tárolási költségeinek elemzéséről.

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, valószínű, hogy a kategória jelenleg nincs használatban. A tárolószámlálók például nem láthatók a tárterületet nem használó erőforrások esetében. Ha nincs PITR- vagy LTR-biztonsági mentési tárhely-felhasználás, ezek a mérőszámok nem lesznek 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ázis TDE-vel van titkosítva, a biztonsági másolatok inaktív állapotban automatikusan titkosítva lesznek, beleértve az LTR biztonsági 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 mérnöki csapata folyamatosan automatikusan teszteli az automatikus adatbázis-biztonsági mentések visszaállítását. Az időponthoz kötött visszaállításkor az adatbázisok a DBCC CHECKDB integritási ellenőrzését is megkapják.

Az integritás-ellenőrzés során észlelt problémák riasztást eredményeznek a mérnöki csapatnak. További információkért lásd: Adatintegritás az SQL-adatbázisban.

A rendszer minden adatbázis biztonsági mentését a CHECKSUM beállítással készíti el, hogy további biztonsági mentési integritást biztosítson.

Engedékenység

Ha az adatbázist egy DTU-alapú szolgáltatási szintről egy vCore-alapú szolgáltatási szintre migrálja, a PITR-adatmegőrzés megmarad, hogy az alkalmazás adat-helyreállítási politikája ne sérüljön. Ha az alapértelmezett megőrzés nem felel meg a megfelelőségi követelményeknek, módosíthatja a PITR megőrzési időtartamát. További információ: A PITR biztonsági mentési megőrzési idejének módosítása.

Jegyzet

Az Automatikus biztonsági mentési beállítások módosítása cikk ismerteti a személyes adatok eszközről vagy szolgáltatásból való törlésének lépéseit, és a GDPR szerinti kötelezettségek támogatására használható. 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 olyan adattárolási követelményekkel rendelkezik, amelyek megkövetelik, hogy az összes adat egyetlen Azure-régióban maradjon, érdemes lehet zónaredundáns vagy helyileg redundáns biztonsági mentéseket kényszeríteni az SQL-adatbázishoz az Azure Policy használatával.

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 ezeknek az erőforrásoknak a vállalati szabványoknak és szolgáltatási szintű szerződéseknek való megfelelésében. További információ: Az Azure Policyáttekintése.

Beépített biztonsági mentési tárolási redundanciaszabályzatok

Az adattárolási követelmények vállalati szinten történő érvényesítéséhez szabályzatokat rendelhet egy előfizetéshez az Azure Portal vagy az Azure PowerShell használatával.

Ha például engedélyezi az "Azure SQL DB-nek kerülnie kell a GRS biztonsági mentés használatát" szabályzatot, az adatbázisok nem hozhatók létre az alapértelmezett tárolóval globálisan redundáns tárolóként, és a felhasználók nem használhatják a GRS-t a "Biztonsági mentési tárfiók típusának konfigurálása Standard_RAGRS" hibaüzenettel 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 tekintse át a házirend-referencia.

Fontos

Az Azure-szabályzatok nem érvényesülnek, amikor T-SQL-en keresztül hoz létre adatbázist. Ha az adatbázis T-SQL használatával történő létrehozásakor meg szeretné adni az adatok tartózkodási helyét, a CREATE DATABASE utasításBACKUP_STORAGE_REDUNDANCY paraméterének bemeneteként használja a LOCAL vagy a ZONE paramétert.