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

A következőkre vonatkozik:Azure SQL felügyelt példány

• Azure SQL-adatbázis
• 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 felügyelt Azure SQL-példány automatikus biztonsági mentési beállításainak módosítása című témakörben olvashat. A biztonsági mentés visszaállításához lásd: Adatbázis visszaállítása biztonsági másolatból felügyelt Azure SQL-példányban.

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. Felügyelt Azure SQL-példány esetén az SQL Server adatbázismotor biztonsági mentéseit a Microsoft automatikusan felügyeli, és a Microsoft által felügyelt Azure Storage-fiókokban tárolja.

Ezekkel a biztonsági másolatokkal visszaállíthatja az adatbázist egy adott időpontra 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, minden adatbázisra vonatkozóan 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:

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

A tranzakciónapló 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, differenciális és tranzakciónapló mentéseket kell visszaállítani a megfelelő sorrendben.

Figyelem

Az automatikus teljes biztonsági mentések hetente egyszer indulnak el a Microsoft által meghatározott ütemezés alapján. felhasználó által kezdeményezett biztonsági mentések elsőbbséget élveznek az automatikus teljes biztonsági mentésekkel szemben, így a hosszú ideig futó, csak másolásra készült biztonsági másolatok hatással lehetnek a következő automatikus teljes biztonsági mentés időzítésére.

Egy tail log biztonsági másolatot készítenek minden alkalommal, mielőtt egy adatbázist vagy SQL felügyelt példányt törölnének.

A rendszer automatikusan biztonsági másolatot készít a rendszer adatbázisairól (a fizikai master adatbázis kivételével), de ezek a biztonsági másolatok jelenleg nincsenek bejelentkezve msdb.

Biztonsági mentési tároló redundancia

Alapértelmezés szerint a felügyelt Azure SQL-példány georedundáns tárolóblobokban tárolja a biztonsági mentéseket,, 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. 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óredundanciáról további információt az Adatredundanciací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.

Jegyzet

A biztonsági mentési redundancia módosítása egy frissítéskezelési művelet,, 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.

  

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

  

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

  

• geozónára redundáns tárolás (GZRS): Egyesíti a rendelkezésre állási zónák redundanciái á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. Abban a régióban három szinkron példány van egyetlen rendelkezésre állási zónában, amelyek az elsődleges régióból a másodlagos régióba másolódtak át aszinkron módon.

  

Figyelmeztetés

• A georedundáns visszaállítás akkor lesz letiltva, amikor az adatbázis helyi redundancia vagy zónális redundancia tárhelyet 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 vagy a GZRS-t.

A biztonsági mentés használata

Ezeket a biztonsági másolatokat a következőkre használhatja:

• Meglévő adatbázis visszaállítása egy múltbéli időpontra, amely a megőrzési időszakon belül van, az Azure portál, 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 példányon, mint az eredeti adatbázis, vagy egy másik példányt ugyanabban az előfizetésben és régióban. Más nevet használ az eredeti adatbázis felülírásának elkerülése érdekében. Az Azure Portal használatával is visszaállíthatja az időponthoz kötött adatbázis biztonsági mentését egy, a forráspéldánytól eltérő előfizetésben lévő példányra.

  A visszaállítás befejezése után törölheti az eredeti adatbázist. Másik lehetőségként átnevezheti az eredeti adatbázist, és átnevezheti a visszaállított adatbázist az eredeti adatbázis nevére.

• Törölt adatbázis visszaállítása a megőrzési időszakon belül időpontra, beleértve a törlés időpontját is. A törölt adatbázist visszaállíthatja ugyanarra a felügyelt példányra, ahol a biztonsági mentés készült, vagy egy másik példányra ugyanabban az előfizetésben, vagy egy másik példányra egy eltérő előfizetésben a forráspéldányhoz képest. 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 georedundáns visszaállítás lehetővé teszi a földrajzi katasztrófák 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ő felügyelt példányán.

  Fontos

  A geo-visszaállítás csak georedundáns biztonsági mentési tárolóval konfigurált adatbázisokhoz érhető el. 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 adatbázis visszaállítása egy hosszú távú biztonsági mentésből, ha az adatbázishoz konfigurált LTR-szabályzat tartozik. 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égi verziójának futtatásához. További információ: Hosszú távú adatmegőrzési biztonsági másolatok – Azure SQL Database és Felügyelt Azure SQL-példány.

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 üzletileg kritikus szolgáltatási szinten. Mivel az adatok replikálva lesznek az SQL Database Engine-folyamatok között az egyes csomópontokon, a biztonsági mentési szolgáltatás a nem olvasható másodlagos replikákról veszi át a 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 Azure ügyfélszolgálati kérést, hogy letiltsa ezt a funkciót az Ön példányán.

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

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

Biztonsági mentés tulajdonságai	PITR	Földrajzi visszaállítás	LTR
SQL biztonsági mentési típusai	Teljes, differenciális és tranzakciónaplós biztonsági másolatok.	A PITR biztonsági másolatainak replikált másolatai.	Csak teljes biztonsági másolatok.
Helyreállítási Pont Célkitűzése (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őkorlát (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, ugyanaz, mint a forrás. 2	Alapértelmezés szerint nincs engedélyezve. A megőrzés legfeljebb 10 év.
Azure tárhely	Alapértelmezés szerint georedundáns. Igény szerint zónaredundáns vagy helyileg redundáns tárolást is konfigurálhat.	Akkor érhető el, ha a PITR biztonsági mentési tárhelyredundancia georedundáns vagy georégió redundáns (GZRS) értékre van állítva. Nem érhető el, ha a PITR biztonsági mentési tároló zónaredundáns vagy helyileg redundáns.	Alapértelmezés szerint georedundáns. Zónaredundáns vagy helyileg redundáns tárolást is konfigurálhat.
Biztonsági másolatok konfigurálása nem módosítható	Nem támogatott	Nem támogatott	Nem támogatott
Szabályzat frissítése3	Meg kell egyeznie vagy frissítenie kell	Meg kell egyeznie vagy frissítenie kell	Meg kell egyeznie vagy frissítenie kell
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	Támogatott	Nem támogatott 4	Nem támogatott 4
Visszaállítás az Azure Portalon	Igen	Igen	Igen
Visszaállítás a PowerShell segítségével	Igen	Igen	Igen
Az Azure CLI használatával végzett visszaállítás	Igen	Igen	Igen

¹ A nagy adatbázisokat igénylő, üzletmenet-folytonosságot biztosító, üzleti szempontból kritikus fontosságú alkalmazások esetében lásd feladatátvételi csoportokat.
² 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.
³ Az adatbázis biztonsági másolatai csak az egyező frissítési szabályzatokkal rendelkező példányokra vagy az SQL Server egy magasabb verziójának frissítési szabályzatára állíthatók vissza. Az SQL Server 2022 frissítési szabályzattal rendelkező példányból készített adatbázis-biztonsági mentés például visszaállítható egy SQL Server 2022, SQL Server 2025 vagy mindig naprakész frissítési szabályzattal rendelkező példányra.
⁴ 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ásolatból felügyelt Azure SQL-példányban. 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.

Művelet	Azure Portal	Azure CLI (Az Azure parancssori felülete)	Azure PowerShell
Biztonsági mentés megőrzésének módosítása	SQL 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 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 Database / felügyelt SQL-példány
Adatbázis visszaállítása egy adott időpontró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

Közvetlenül az adatbázis létrehozása, visszaállítása vagy a biztonsági mentés redundancia módosításainak végrehajtá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, bár hosszabb ideig is eltarthat. 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 nagyobb visszaállított adatbázisok vagy adatbázismásolatok több időt igényelhetnek a kezdeti biztonsági mentéshez.

Fontos

Egy új-adatbázis első teljes biztonsági mentése elsőbbséget élvez a többi adatbázis biztonsági mentésével szemben, ezért ez az első biztonsági mentés az első teljes biztonsági mentési időszakban. Ha a teljes biztonsági mentési időszak már aktív, és más adatbázisokról is készül biztonsági másolat, az új adatbázis első teljes biztonsági mentése közvetlenül egy másik adatbázis teljes biztonsági mentése után történik.

Ü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ányra.
• teljes biztonsági mentési ablak: Ez a teljes biztonsági mentések végrehajtásának kijelölt időszaka. Bár a rendszer célja a teljes biztonsági mentések elvégzése ebben az ablakban, ha szükséges, a biztonsági mentés az ütemezett idő után is folytatódhat, amíg befejeződik.
• Adaptív ütemezési: 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ó: 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 a kezdeti teljes biztonsági mentést követően, és miután a kezdeti tranzakciónapló mentése befejeződött, válik elérhetővé.

Biztonsági mentési tárterület fogyasztá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 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 álljon, a rendszernek a konfigurált megőrzési időszaknál akár egy héttel tovább további teljes, differenciális és tranzakciónapló-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 megszakítás nélküli 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 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 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ók biztonsági mentései teljesítménybeli okokból nem tömöríthetők. 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. Az adatcsatorna felelős az óránkénti használat összesítéséért, hogy minden hónap végén kiszámítsa az Ön fogyasztását. 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 másolatok tárolási felhasználásának finomhangolása

Az adatbázis maximális méretéig terjedő 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 az adatbázis biztonsági mentés megőrzési időtartamát a minimálisra az igényeinek megfelelően.
• 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 csoportosított oszlopcentrikus indexek használatát, és kövesse a kapcsolódó ajánlott eljárásokat. Fontolja meg a nem klaszterezett indexek számának csökkentését is.
• Az általános célú szolgáltatási szinten a kiépített adattárolás olcsóbb, mint a biztonsági mentési tár ára. Ha folyamatosan magas többletköltségei vannak a biztonsági mentési tárterület miatt, érdemes lehet növelni az adattárolási kapacitást a költségek csökkentése érdekében.
• 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

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ú megtartá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. 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, mint a megőrzési idő, így biztosítva a pontos adat-visszaállítá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 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 hosszú távú megőrzési.

Fontos

Ha véletlenül törölt felügyelt SQL-példányból kell visszaállítania az adatbázisokat, a törlési művelettől számított 5 napon belül lépjen kapcsolatba a Microsoft támogatási csapatával.

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 W=0, M=1, Y=0 beállítása például havi LTR-példányt hozna létre. További információ az LTR-ről: Hosszú távú adatmegőrzési biztonsági másolatok – Azure SQL Database és Felügyelt Azure SQL-példány.

Az Azure SQL Felügyelt Példány LTR biztonsági mentési tárredundanciáját az STR által annak idején használt biztonsági mentési tárhely redundanciája határozza meg, amikor az LTR-szabályzatot definiálják. Nem módosíthatja, még akkor sem, ha a jövőben megváltozik az STR biztonsági mentési tároló redundanciája.

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.

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

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 csővezeték összesíti ezt az óránkénti használatot, hogy a hónap végén megkapja 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é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 (LRS) = Zone-redundant price (ZRS) = published price
• Geo-redundant price (GRS) = Geo-zone-redundant price (GZRS) = published price x 2

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

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.

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, differenciális és napló biztonsági másolatkészlet elavult.

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 során végrehajtott módosítások ezt követően be lesznek építve.

• Az újraépítés időtartama alatt készült tranzakciónapló-mentések.
• A következő differenciális biztonsági mentésben.
• Minden különbségi biztonsági mentés során, amely a következő teljes biztonsági mentésig megtö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% egyenlő különbségi biztonsági mentéseket 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.

Költségek figyelése

A biztonsági mentés tárolási költségeinek megismeréséhez lépjen Cost Management + Billing az Azure Portalon. 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őt adjon hozzá a szolgáltatásnévhez.

2. A legördülő listában válassza ki a SQL-felügyelt példányt egy felügyelt példányhoz.

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 monitorozásához a legördülő listában válassza ki a felügyelt példány PITR biztonsági mentés tárhelyét. A mérőszámok csak akkor jelennek meg, ha van használatban biztonsági mentési tárhely.

   Az LTR biztonsági mentési költségeinek monitorozásához a legördülő listában válassza felügyelt SQL-példányt – ltr backup storage. A mérőszámok csak akkor jelennek meg, ha van használatban biztonsági mentési tárhely.

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

Fontos

A mérőszámok csak a jelenleg használatban lévő számlálók esetében láthatók. Ha egy számláló nem érhető el, akkor valószínű, hogy a kategória jelenleg nincs használatban. Például a felügyelt példány számlálók nem állnak rendelkezésre azoknál az ügyfeleknél, 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 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-ben az összes új adatbázis alapértelmezés szerint a TDE-vel engedélyezetten van konfigurálva. A TDE-ről további információért lásd: Felügyelt SQL-példány transzparens adattitkosítása.

A Microsoft teljes mértékben felelős a szolgáltatás által felügyelt kulcsokkal (SMK) rendelkező adatbázisok kulcsainak megőrzéséért és elforgatásáért. A Microsoft visszaállíthatja azokat a biztonsági másolatokat, amelyek pitr vagy LTR típusúak, és olyan példányokról származnak, amelyeken engedélyezve van az SMK-t engedélyező TDE.

Az Azure által felügyelt tárfiókokban tárolt automatikus biztonsági mentéseket az Azure Storage automatikusan titkosítja. További információ a nyugalmi adatokat védő Azure Storage titkosításról .

Az automatikus biztonsági mentésekkel kapcsolatos gyakori problémák az ügyfélműveletek miatt

Míg a felügyelt Azure SQL-példány automatizált biztonsági mentéseket biztosít az adatvédelem és a helyreállítás biztosítása érdekében, bizonyos ügyféloldali konfigurációk vagy műveletek biztonsági mentési hibákhoz vezethetnek. Gyakori forgatókönyvek a következők:

• Nincs elegendő tárterület a felügyelt SQL-példányhoz. Ha a példány számára lefoglalt tárterület megtelt, a rendszer nem készít automatikus biztonsági másolatot.
• A rendszerfolyamatokat megszakító, felhasználó által definiált feladatok vagy szkriptek leállíthatják az automatikus biztonsági mentési műveleteket.
• A helytelen DNS-beállítások megakadályozhatják, hogy a felügyelt SQL-példány hozzáférjen a szükséges Azure-végpontokhoz, beleértve a biztonsági mentésekhez használtakat is, ami biztonsági mentési hibákhoz vezethet.
• A tranzakciónapló megtelhet, ha a csonkolást hibásan konfigurált replikáció, CDC vagy teljes tárterület megakadályozta (a példány szintjén). Ha a tranzakciónapló megtelt, és nem lehet csonkítani, a teljes és a differenciális biztonsági mentések sikertelenek, de a napló biztonsági mentései csonkítás nélkül továbbra is sikeresek.

A megbízható biztonsági mentések biztosítása érdekében fontos figyelni a rendszererőforrásokat, ellenőrizni a konfigurációs beállításokat, és elkerülni a beépített szolgáltatásműveletek megzavarását. Győződjön meg arról, hogy figyeli a lefoglalt tárterületet, rendelkezik a megfelelő DNS-beállításokkal, és áttekinti az egyéni feladatokat és a replikációs konfigurációkat.

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 az SQL-kezelői példányban lévő saját adatbázisaira a számítási feladatok figyelembevételével.

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ások redundanciára vonatkozó szabályai

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 PowerShellhaszná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: felügyelt SQL-példányoknak kerülnie kell a GRS biztonsági mentési redundanciahasználatát.

A felügyelt SQL-példány beépített szabályzatdefinícióinak teljes listájáért tekintse át a házirend-referenciát.

Fontos

Az Azure-szabályzatok nem kerülnek érvényesítésre, ha T-SQL-en keresztül hoz létre adatbázist. Ha az adatok tárolóhelyét szeretné kikényszeríteni, amikor T-SQL használatával hoz létre adatbázist, a CREATE DATABASE utasításBACKUP_STORAGE_REDUNDANCY paraméterének bemeneteként használja a LOCAL vagy a ZONE paramétert.

Biztonsági másolatok védelme

A felügyelt Azure SQL-példányok biztonsági mentései teljes egészében a Microsoft tulajdonában lévő Azure-előfizetéseken belül, biztonságos, belső Azure Storage-fiókok használatával kezelhetők. Ezek a biztonsági másolatok külsőleg nem érhetők el, így erős adatelkülönítést és védelmet nyújtanak. A Microsofton belül csak a háttérszolgáltatásoknak, például a Backup-Restore szolgáltatásnak van hozzáférése a biztonsági másolatok létrehozásához, másolásához vagy visszaállításához. A Microsoft mérnökei, beleértve a fejlesztőket, nem rendelkeznek állandó hozzáféréssel. Az expozíció minimalizálása és a biztonság maximalizálása érdekében a Microsoft csak akkor szerezhet be Just-In-Time (JIT) hozzáférést szigorú naplózási vezérlők mellett, ha az adott ügyfélproblémák elhárításához feltétlenül szükséges.

A biztonsági másolatok a megőrzés lejárta után automatikusan törlődnek.

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

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 Azure SQL Managed Instance automatikus biztonsági mentési beállításainak 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-ról a Microsoft Adatvédelmi központ GDPR-szakaszában, valamint a Szolgáltatásmegbízhatósági portál GDPR szakaszábantájékozódhat.

Kapcsolódó tartalom

• Az Azure SQL Managed Instance üzletmenet folytonosságának áttekintése
• Felügyelt Azure SQL-példány hosszú távú biztonsági mentési megőrzésének kezelése
• Adatbázis visszaállítása biztonsági másolatból felügyelt Azure SQL-példányban
• Biztonsági mentési tárhely felhasználása a felügyelt SQL-példány esetében
• Biztonsági másolatok tárolási költségeinek finomhangolása felügyelt SQL-példányon