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

A következőre vonatkozik: Azure SQL Database

• Azure SQL Database
• 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ása című témakörben olvashat. A biztonsági mentés visszaállításához tekintse meg a Helyreállítás automatizált adatbázis biztonsági másolatokkal című témakört.

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 (akár 10 évig) elérhetők legyenek, konfigurálhatja a hosszú távú adatmegőrzést (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 a tárolási pillanatképek alapjá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:

• Minden héten teljes biztonsági másolatok .
• Különbségi 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ó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. Az adatbázis visszaállításakor a szolgáltatás határozza meg, hogy melyik teljes, különbségi és tranzakciónapló-biztonsági mentést kell visszaállítani.

A rugalmas skálázású architektúra nem igényel teljes, különbségi vagy napló biztonsági mentést. További információ: Rugalmas skálázású biztonsági másolatok.

A biztonsági mentési tár redundanciája

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 új adatbázisai georedundáns tárolóblobokban tárolják a biztonsági mentéseket, amelyeket 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 számítási feladatkörnyezeti beállítást 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 a beállítás csak az SQL Database portál létrehozása lapra vonatkozik.

• A fejlesztési számítási feladatok környezetének kiválasztásával a Backup storage redundancia beállítását helyileg redundáns tárolás használatára állítja be. 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.
• Az éles számítási feladatok környezetének kiválasztásakor a Backup storage redundanciát georedundáns tárolásra állítja, az alapértelmezett értékre.
• A Számítási feladatok környezete beállítás a számítás kezdeti beállítását is módosítja, de ez felülírható. Ellenkező esetben a Számítási feladat környezet beállításának nincs hatása a licencelési vagy egyéb 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ási redundanciáról további információt az Adatredundancia cí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.

  

• 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 aszinkron módon háromszor másolja az adatokat 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.

  

Figyelmeztetés

• A georedundáns visszaállítás a helyileg redundáns vagy zónaredundáns tárolás használatára való frissítés után azonnal le lesz tiltva.
• 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. Ha minimális állásidővel szeretné frissíteni egy meglévő rugalmas skálázású adatbázis biztonsági mentési tárhelyredundancia-beállításait, használja az aktív georeplikálást. Másik lehetőségként használhatja az adatbázis-másolást is. További információ a rugalmas skálázású biztonsági mentésekről és a tárolóredundanciákról.

Biztonsági másolat használata

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

• Állítsa vissza a meglévő adatbázist a megőrzési időszakon belüli 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.

• A törölt adatbázis visszaállítása a megőrzési időszakon belüli 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óban A georedundáns visszaállítás lehetővé teszi a regionális kimaradások utáni helyreállítást, ha nem fér hozzá 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 georedundáns visszaállítás csak georedundáns biztonsági mentési tárolóval konfigurált adatbázisokhoz érhető el. Ha Ön jelenleg nem georeplikált biztonsági másolatokat használ az adatbázishoz, ezt a biztonsági mentési tár redundanciájának konfigurálásával módosíthatja.

• Adatbázis visszaállítása egyetlen vagy készletezett adatbázis adott hosszú távú biztonsági mentéséből , ha az adatbázis 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 egy megfelelőségi kérés teljesítéséhez vagy az alkalmazás egy régebbi verziójának futtatásához. További információkért lásd: Hosszú távú megőrzés.

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), a georedukció és a hosszú távú megőrzés képességeit és funkcióit foglalja össze.

Biztonsági mentés tulajdonság	PITR	Geo-restore	LTR
SQL biztonsági mentés típusai	Teljes, különbség, napló.	A PITR biztonsági másolatainak legutóbbi georeplikált másolatai.	Csak teljes biztonsági másolatok.
Helyreállítási időkorlát (RPO)	10 perc, a számítási méret és az adatbázis-tevékenység mennyisége alapján.	Georeplikációs adatok alapján legfeljebb 1 óra.*	Egy hét (vagy felhasználói szabályzat).
Helyreállítási időre vonatkozó célkitűzés (RTO)	A visszaállítás általában kevesebb, mint 12 órát vesz igénybe, de a mérettől és a tevékenységtől függően hosszabb időt is igénybe vehet. Lásd: Helyreállítás.	A visszaállítás általában kevesebb, mint 12 órát vesz igénybe, de a mérettől és a tevékenységtől függően hosszabb időt is igénybe vehet. Lásd: Helyreállítás.	A visszaállítás általában kevesebb, mint 12 órát vesz igénybe, de a mérettől és a tevékenységtől függően hosszabb időt is igénybe vehet. Lásd: Helyreállítás.
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, a forrással egyezően.**	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ánsra 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.
A biztonsági mentések nem módosíthatóként való konfigurálása	Nem támogatott	Nem támogatott	Nem támogatott
Új adatbázis visszaállítása ugyanabban a régióban	Támogatott	Támogatott	Támogatott
Új adatbázis visszaállítása egy másik régióban	Not supported	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	Not supported	Nem támogatott***	Nem támogatott***
Visszaállítás az Azure Portalon	Igen	Yes	Igen
Visszaállítás PowerShell-lel	Igen	Yes	Igen
Visszaállítás az Azure CLI-vel	Igen	Yes	Igen

* Az üzletileg kritikus fontosságú alkalmazásokhoz, amelyek nagy adatbázisokat igényelnek, és biztosítaniuk kell az üzletmenet folytonosságát, használjon feladatátvételi csoportokat.

** Az összes PITR-biztonsági mentés alapértelmezés szerint georedundáns tárolóban van tárolva, így a georedundáns visszaállítás alapértelmezés szerint engedélyezve van.

A megkerülő megoldás az, hogy egy új kiszolgálóra állítja vissza a kiszolgálót, és a Resource Move használatával áthelyezi a kiszolgálót egy másik előfizetésbe, vagy előfizetések közötti adatbázis-példányt használ.

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.

Operation	Azure Portal	Azure CLI	Azure PowerShell
Biztonsági másolat 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 Database Felügyelt SQL-példány
A biztonsági mentés 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 Database Felügyelt SQL-példány
Adatbázis visszaállítása egy adott időpontból	SQL Database 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 Database Felügyelt SQL-példány	SQL Database Felügyelt SQL-példány	SQL Database Felügyelt SQL-példány

Biztonsági mentés ütemezése

The first full backup is scheduled immediately after a new database is created or restored. 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 adatbázis-mentések pontos időzítését az SQL Database szolgáltatás határozza meg a teljes rendszer terhelésének kiegyensúlyozásával. 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őponthoz kötött visszaállítási képesség akkor válik elérhetővé, amikor létrejön a kezdeti teljes biztonsági mentést követő kezdeti 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ókért tekintse át a rugalmas skálázású automatikus biztonsági mentéseket.

Tárterület-felhasználás biztonsági mentése

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 a teljes megőrzési időszakon belül rendelkezésre lásson, a rendszernek a konfigurált megőrzési időszaknál akár egy hétig további teljes, különbségi és tranzakciónapló-biztonsági mentéseket kell tárolnia.

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. A különbségi és tranzakciónapló-biztonsági mentések folyamatos láncá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, beleértve a TDE-titkosított adatbázisokat is, az összes teljes és különbségi biztonsági mentés tömörítve van a biztonsági mentések tárolási tömörítésének és költségeinek csökkentése érdekében. A biztonsági mentések átlagos tömörítési aránya 3–4-szeres. Az adatok jellegétől és attól függően, hogy az adattömörítést használják-e az adatbázisban, jelentősen alacsonyabb vagy magasabb 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. A folyamat felelős az óránkénti használat ö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.

Használat monitorozása

Az Azure SQL Database-ben lévő virtuálismag-adatbázisok esetében az egyes biztonsági mentési (teljes, különbségi és napló) típusú 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.

A rugalmas skálázásban történő felhasználás monitorozásával kapcsolatos utasításokért lásd : Rugalmas skálázású biztonsági mentések felhasználásának figyelése.

A biztonsági mentési tároló használatának finomhangolása

Az adatbázis maximális adatméretének maximális adatméretig történő biztonsági mentési tárterület-használat nem számít 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ések megőrzési időtartamát az igényeinek megfelelő minimálisra.
• 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 a fürtözött oszlopcentrikus indexek használatát és a kapcsolódó ajánlott eljárásokat. Fontolja meg a nemclustered 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 többletköltséggel rendelkezik, érdemes lehet növelni az adattárolást a biztonsági mentési tárterületen való mentéshez.
• Az alkalmazáslogikában állandó táblák helyett ideiglenes eredmények vagy átmeneti adatok tárolására használható tempdb .
• 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ése

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ú megőrzé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 egyes aktív adatbázisok biztonsági mentési megőrzési idejét 1–35 nap között módosíthatja, kivéve az alapszintű adatbázisokat, amelyek 1 és 7 nap között konfigurálhatók. A biztonsági mentési tárterület használatában leí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, engedélyezheti a hosszú távú megőrzést.

Ha töröl egy adatbázist, a rendszer ugyanúgy őrzi meg a biztonsági másolatokat, mint egy online adatbázis esetében, amelynek az adott 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ö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óért tekintse át a hosszú távú biztonsági mentés visszaállítását.

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 beállítás W=0, M=1 például havonta hoz létre LTR-példányt. További információ az LTR-ről: 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.

Storage consumption depends on the selected frequency and retention periods of LTR backups. Az LTR díjkalkulátorral megbecsülheti az LTR tárolás költségét.

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 forduljon a Microsoft ügyfélszolgálatához, és hozzon létre egy támogatási jegyet a probléma megoldásához.

Backup-tárhellyel kapcsolatos díjak

A biztonsági mentési tár ára változó, és 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 a régió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 biztonsági mentési tár redundancia a következő módon befolyásolja a biztonsági mentés költségeit:

• Locally redundant price = published price
• Zone-redundant price = published price x 1.25
• Geo-redundant price = published price x 2

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

Megjegyzés:

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 az LTR biztonsági mentési tárterületéért az LTR-biztonsági mentések által felhasznált tényleges tárterület alapján kerülnek felszámításra.

Virtuálismag-alapú 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 folyamat összesíti ezt az óránkénti használatot, hogy minden hónap végén lekérje a biztonsági mentési tárterület használatá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, miután egy régebbi, teljes, különbségi és napló biztonsági másolatok elavultak.

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és által a következő módosításokat fogja tartalmazni:

• A tranzakciónapló biztonsági másolatai átvették az újraépítés időtartamát.
• A következő különbségi biztonsági mentésben.
• Minden különbségi biztonsági mentésben, amely a következő teljes biztonsági mentésig történik.

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árterület-felhasználását az idő függvényében figyelheti, a monitorozási használatban leírtak szerint.

Monitor costs

A biztonsági mentés tárolási költségeinek megismeréséhez lépjen a Cost Management + Számlázás elemre az Azure Portalon. Válassza a Cost Management, majd a Költségelemzés lehetőséget. Válassza ki a kívánt előfizetést a Hatókörhöz, majd szűrje ki a kívánt időtartamot és szolgáltatást az alábbiak szerint:

1. Adjon hozzá egy szűrőt a szolgáltatásnévhez.

2. A legördülő listában válassza ki az SQL-adatbázist egyetlen adatbázishoz vagy rugalmas adatbáziskészlethez.

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

4. A PITR biztonsági mentési költségeinek monitorozásához a legördülő listában válassza ki az egyetlen vagy rugalmas készlet pitr biztonsági mentési tárát 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.

   Az LTR biztonsági mentési költségeinek monitorozásához a legördülő listában válassza ki az LTR biztonsági mentési tárterületet 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 Tárolási és számítási alkategóriák szintén érdekelhetik Önt, de ezek nincsenek társítva a biztonsági másolatok tárolási költségeivel.

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árterület-használat, ezek a mérőszámok nem lesznek láthatók.

További információkért tekintse meg az Azure SQL Database költségkezelését.

Titkosított biztonsági mentések

Ha az adatbázis TDE-vel van titkosítva, a rendszer automatikusan titkosítja az inaktív biztonsági másolatokat, beleértve az LTR biztonsági másolatokat is. Az Azure SQL összes új adatbázisa alapértelmezés szerint TDE-vel van konfigurálva. A TDE-vel kapcsolatos további információkért lásd az SQL Database transzparens adattitkosítását.

Biztonsági mentés integritása

Az Azure SQL mérnöki csapata folyamatosan automatikusan teszteli az adatbázisok automatizált biztonsági mentéseinek 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ó: Adatintegritás az SQL Database-ben.

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.

Megfelelőség

Ha DTU-alapú szolgáltatási szintről virtuálismag-alapú szolgáltatási szintre migrálja az adatbázist, a PITR-megőrzés megmarad, hogy az alkalmazás adathelyreállítási szabályzata semmiképpen se 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és megőrzési idejének módosítása.

Megjegyzés:

Az automatikus biztonsági mentési beállítások módosítása című cikk lépésekkel ismerteti a személyes adatok eszközről vagy szolgáltatásból való törlését, és a GDPR szerinti kötelezettségek támogatására használható. A GDPR-rel kapcsolatos általános információkért tekintse meg a Microsoft Adatvédelmi központ GDPR szakaszát és a Szolgáltatás megbízhatósági portáljának 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 hozzá egy előfizetéshez az Azure Portal vagy az Azure PowerShell használatával. Ha például a következő beépített szabályzatot rendeli hozzá, az előfizetés felhasználói nem hozhatnak létre georedundáns biztonsági mentési tárolóval rendelkező adatbázist az Azure Portalon vagy az Azure PowerShellen keresztül: Az SQL Database-nek kerülnie kell a GRS biztonsági mentési redundancia használatát.

Az SQL Database beépített szabályzatdefinícióinak teljes listájáért tekintse át a szabályzatreferenciát.

Fontos

Az Azure-szabályzatok nem lesznek kényszerítve, 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, használja a LOCAL vagy a ZONE paramétert a CREATE DATABA Standard kiadás utasítás BACKUP_STORAGE_REDUNDANCY paraméterének bemeneteként.

Kapcsolódó tartalom

• Az SQL Database üzletmenet-folytonossági megoldásairól az üzletmenet-folytonosság áttekintésében olvashat.
• A biztonsági mentési beállítások módosításáról a Beállítások módosítása cí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 egy adatbázis visszaállítása időpontra a PowerShell használatával című témakört.
• Az automatikus biztonsági másolatok Azure Blob Storage-beli 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ésének kezelése című témakörben talál.
• Felügyelt Azure SQL-példány esetén lásd a felügyelt SQL-példányok automatikus biztonsági mentéseit.