Automatizált biztonsági mentések felügyelt Azure SQL-példányban

  • Cikk

A következőre vonatkozik: Felügyelt Azure SQL-példány

Ez a cikk a felügyelt Azure SQL-példány 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.

Mik azok az automatikus adatbázis-biztonsági mentések?

Az adatbázis-biztonsági mentések alapvető részét képezik 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. A felügyelt Azure SQL-példány teljes mértékben felügyelt és automatizált SQL Server-adatbázismotor biztonsági mentéseket biztosít. Ezek a biztonsági másolatok lehetővé teszik az adatbázis adott időpontra való visszaállítását a konfigurált megőrzési időszakon belül, legfeljebb 35 napig. Ha azonban az adatvédelmi szabályok megkövetelik, hogy a biztonsági másolatok hosszabb ideig (akár 10 évig) elérhetők legyenek, adatbázisonként konfigurálhat hosszú távú adatmegőrzési (LTR) szabályzatokat.

Biztonsági mentés gyakorisága

A felügyelt Azure SQL-példány a következőket hozza létre:

A tranzakciónapló biztonsági mentésének gyakorisága a számítási mérettől és az adatbázis-tevékenység mennyiségétől függ. A tranzakciónaplók körülbelül 10 percenként készülnek, de változhatnak. Adatbázis visszaállításakor a szolgáltatás határozza meg, hogy mely teljes, különbségi és tranzakciónapló-biztonsági mentéseket kell visszaállítani a megfelelő sorrendben.

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

Alapértelmezés szerint a felügyelt Azure SQL-példány georedundáns tárolóblobokban tárolja az adatokat, amelyek egy párosított régióba vannak replikálva. 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. Azt is lehetővé teszi, hogy egy katasztrófa esetén a példányt egy másik régióba állítsa vissza.

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.

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 tárolási redundanciáról további információt az Adatredundancia című témakörben talál.

A példány létrehozásakor konfigurálhatja a biztonsági mentési tár redundanciát, és később frissítheti a példány szintjén. A meglévő példányon végrehajtott módosítások csak a jövőbeli biztonsági másolatokra vonatkoznak. Egy meglévő példány biztonsági mentési tár redundanciájának frissítése után akár 24 órát is igénybe vehet a módosítások alkalmazása. A biztonsági mentési tár redundanciájával kapcsolatos módosítások csak a rövid távú biztonsági mentésekre vonatkoznak. A hosszú távú adatmegőrzési szabályzatok öröklik a rövid távú biztonsági mentések redundanciabeállítását a szabályzat létrehozásakor. A redundancia beállítás akkor is megmarad a hosszú távú biztonsági mentések esetében, ha a rövid távú biztonsági mentések redundanciabeállítása később megváltozik.

Megjegyzés:

Vegye figyelembe, hogy a Biztonsági másolat redundancia módosítása olyan frissítési lépést okoz, amely feladatátvételt kezdeményez.

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 replikációs lehetőség, de magas rendelkezésre állást vagy tartósságot igénylő alkalmazásokhoz nem javasoljuk.

    Diagram showing the locally redundant storage (LRS) option.

  • 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 bizonyos régiókban érhető el.

    Diagram showing the zone-redundant storage (ZRS) option.

  • 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 egyetlen rendelkezésre állási zónán belül.
    • A párosított régió három szinkron példánya egyetlen rendelkezésre állási zónán belül, amelyeket aszinkron módon másoltak át az elsődleges régióból a másodlagos régióba.

    Diagram showing the geo-redundant storage (GRS) option.

  • 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 által biztosított regionális kimaradások elleni védelemmel. A GZRS-fiók adatai az elsődleges régió három Azure-rendelkezésre állási zónájában lesznek átmásolva. Az adatok egy másodlagos földrajzi régióba is replikálódnak a regionális katasztrófák elleni védelem érdekében. Ebben a régióban három szinkron példánya is van egyetlen rendelkezésre állási zónában, amelyeket aszinkron módon másolt át az elsődleges régióból a másodlagos régióba.

    Diagram showing the geo-zone-redundant storage (GZRS) option.

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 vagy a GZRS-t.

Biztonsági másolat használata

A biztonsági másolatokat a következő célokra használhatja:

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 másolat tulajdonságai  PITR Geo-restore LTR
Az SQL biztonsági mentési típusai Teljes, különbségi és tranzakciónaplós biztonsági másolatok. A PITR biztonsági másolatok replikált példányai. Csak teljes biztonsági másolatok.
Helyreállítási időkorlát (RPO)  Körülbelül 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. 1    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 1-35 nap.  Alapértelmezés szerint engedélyezve van, a forrással egyezően. 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á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 Supported Nem támogatott 3 Nem támogatott 3
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

1 A nagy adatbázisokat igénylő és az üzletmenet folytonosságát biztosító üzletileg kritikus fontosságú alkalmazások esetében lásd a feladatátvételi csoportokat.

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

3 A kerülő megoldás az, ha 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.

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. Az alábbi példák segítségével megpróbálhatja a biztonsági mentési konfigurációt és a visszaállítási műveleteket.

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
Adatbázis visszaállítása az Azure Blob Storage-ból Felügyelt SQL-példány

Automatikus biztonsági mentések ütemezése

A felügyelt Azure SQL-példány automatikusan kezeli a biztonsági mentéseket teljes, különbségi és tranzakciónaplós biztonsági mentések létrehozásával. Ezt a folyamatot egy belső ütemezés szabályozza.

Kezdeti biztonsági mentés

  • Új adatbázisok: Közvetlenül az adatbázis létrehozása, visszaállítása vagy a biztonsági mentés redundanciáinak módosítása után a rendszer elindítja az első teljes biztonsági mentést. Ez a biztonsági mentés általában 30 percen belül befejeződik, de nagyobb adatbázisok esetében hosszabb időt is igénybe vehet.

  • Visszaállított adatbázisok: A visszaállított adatbázisok kezdeti biztonsági mentésének időtartama változó, és az adatbázis méretétől függ. A visszaállított adatbázisok vagy adatbázismásolatok, amelyek gyakran nagyobbak, több időt igényelhetnek a kezdeti biztonsági mentéshez.

Ütemezett teljes biztonsági mentések

  • Heti ütemezés: A rendszer heti teljes biztonsági mentési időszakot állít be a teljes példányhoz.
  • Teljes biztonsági mentési időszak: Ez a teljes biztonsági mentés végrehajtásának kijelölt időszaka. Bár a rendszer teljes biztonsági mentéseket kíván végrehajtani ebben az ablakban, szükség esetén a biztonsági mentés az ütemezett idő után is folytatódhat, amíg befejeződik.
  • Adaptív ütemezés: A biztonsági mentési algoritmus körülbelül hetente egyszer értékeli ki a biztonsági mentési ablak hatását a számítási feladatra, és a processzorhasználatot és az I/O-átviteli sebességet használja mutatóként. Az előző heti számítási feladattól függően a teljes biztonsági mentési időszak módosítható.
  • Felhasználói konfiguráció: Fontos megjegyezni, hogy a felhasználók nem tudják módosítani vagy letiltani a biztonsági mentés ütemezését.

Fontos

Új, visszaállított vagy másolt adatbázis esetén az időponthoz kötött visszaállítási (PITR) 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.

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 Managed Instance biztonsági mentési ütemezései hetente egy teljes biztonsági mentést tartalmaznak. 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 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.

A felügyelt Azure SQL-példány ö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

A törölt adatbázisok biztonsági másolatait az időponthoz kötött visszaállítás (PITR) tárolja, ami növelheti a tárolási költségeket, mivel a biztonsági másolatok az adatbázis törlése ellenére is megmaradnak. A költségek csökkentése érdekében a biztonsági mentés megőrzési időtartamát 0 napra állíthatja be, de csak a törölt adatbázisok esetében. Normál adatbázisok esetén a minimális megőrzési idő 1 nap.

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 az adatbázis biztonsági mentésének megőrzési időtartamát az igényeinek megfelelő minimálisra.
  • Kerülje a szükségesnél gyakrabban végzett 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

A felügyelt Azure SQL-példány 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 Managed Instance megőrzi a megfelelő biztonsági másolatokat ahhoz, hogy alapértelmezés szerint az elmúlt 7 napon belül engedélyezhesse a PITR-t. Ez a konfiguráció 1 és 35 nap között módosítható . A szolgáltatás rendszeres teljes, differenciált és naplóalapú biztonsági mentéseket készít annak érdekében, hogy az adatbázisok bármikor visszaállíthatók legyenek az adatbázishoz vagy felügyelt példányhoz meghatározott megőrzési időn belül.

A példány 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 a példány 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, amíg a megőrzési időszak el nem jár. 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 a pontos adat-visszaállítás érdekében.

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 esetében azonban a megőrzési időtartam 1–35 napról 0–35 napra frissül, így manuálisan törölhetők a biztonsági másolatok. 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.

Fontos

If you delete a managed instance, all databases on that managed instance are also deleted and can't be recovered. You can't restore a deleted managed instance. Ha azonban egy felügyelt példány hosszú távú megőrzését konfigurálta, az LTR biztonsági másolatai nem törlődnek. Ezeket a biztonsági másolatokat ezután visszaállíthatja az adatbázisok egy másik felügyelt példányra ugyanabban az előfizetésben, egy olyan időpontig, amikor LTR biztonsági mentést készítettek. 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 (LTR)

A felügyelt SQL-példányokkal akár 10 évig is konfigurálhatja a teljes LTR-biztonsági mentések tárolását az Azure Blob Storage-ban. Az LTR-szabályzat konfigurálása után a rendszer 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, Y=0 például havi LTR-példányt hozna létre. További információ az LTR-ről: Hosszú távú megőrzés.

A felügyelt Azure SQL-példány LTR biztonsági mentési tárolási redundanciájával az STR által az LTR-szabályzat definiálásakor használt biztonsági mentési tárredundancia öröklődik. Nem módosíthatja, még akkor sem, ha az STR biztonsági mentési tár redundanciájával a jövőben változik.

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.

Backup-tárhellyel kapcsolatos díjak

Az Azure SQL Managed Instance 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ési tár ára eltérő. Ez a választott biztonsági mentési tár redundanciá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
  • Geo-zone-redundant price = published price x 3.4

A díjszabásért tekintse át az Azure SQL Managed Instance díjszabási oldalát.

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.

Felügyelt példányok esetén a számlázható biztonsági mentési tár teljes mérete a példány szintjén összesítve lesz, és a következőképpen lesz kiszámítva:

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

Ha van ilyen, a teljes számlázható biztonsági mentési tárterületet gigabájtban számítjuk fel minden régió esetében a használt biztonsági mentési tár redundanciája alapján. A biztonsági mentési tárterület-használat az egyes adatbázisok é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íjakat fognak fizetni.

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). A felügyelt SQL-példány 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ó. A felügyelt SQL-példány 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 megőrzési költségek nem növekednek azonnal. Naponta fokozatosan növekednek, mivel a biztonsági mentések addig nőnek, amíg el nem érik a 14 napos maximális megőrzési időtartamot.

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

Az összes különbségi biztonsági mentés méretének csökkentése érdekében a rendszer előlépteti a túlzottan nagy, 750 GB-ot meghaladó és az adatbázis méretének 75%-át egyenlő különbségi biztonsági másolatokat teljes biztonsági mentéssé, ha az utolsó teljes biztonsági mentést több mint 24 órával ezelőtt készítették.

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 a felügyelt sql-példányt .

  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 a felügyelt példány pitr biztonsági mentési tárát. 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 a felügyelt SQL-példányt – ltr backup storage. 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.

Screenshot that shows an analysis of backup storage costs.

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 felügyelt példányszámlálók például nem lesznek jelen azoknak az ügyfeleknek, akik nem telepítettek felügyelt példányt. Hasonlóképpen, a tárolószámlálók nem lesznek 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.

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 : Transzparens adattitkosítás felügyelt SQL-példányokkal.

Biztonsági mentés integritása

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. Az Azure SQL mérnöki csapata által készített automatikus adatbázis-biztonsági mentések automatikus tesztelése jelenleg nem érhető el a felügyelt Azure SQL-példányhoz. Ütemezze a biztonsági mentés visszaállítását és a DBCC CHECKDB-t a felügyelt SQL-példányban lévő adatbázisokon a számítási feladat köré.

Bár a rendszer nem ellenőrzi a biztonsági másolatok integritását, a biztonsági másolatok beépített védelme továbbra is figyelmezteti a Microsoftot, ha probléma merül fel a biztonsági mentési szolgáltatással kapcsolatban. Emellett a Microsoft támogatja önt, ha biztonsági mentéssel kapcsolatos probléma merül fel, például ha nem készít teljes biztonsági másolatot, a biztonsági mentési szolgáltatás elakadt, a napló biztonsági mentése ki van adva az SLA-ból, vagy ha a biztonsági mentés hardvere vagy szoftvere sérült.

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 a felügyelt SQL-példányhoz 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 vagy az erőforráscsoport szintjén, az előfizetés felhasználói nem fognak tudni georedundáns biztonsági mentési tárterülettel rendelkező felügyelt példányt létrehozni az Azure Portalon vagy az Azure PowerShellen keresztül: a felügyelt SQL-példányoknak kerülnie kell a GRS biztonsági mentési redundanciát.

A felügyelt SQL-példány 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 t-SQL használatával szeretne adattárolást kényszeríteni egy adatbázis létrehozásakor, 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.

Megfelelőség

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.

További lépések