Automatikus biztonsági mentések – Azure SQL Database & SQL Managed Instance

a következőkre vonatkozik: Azure SQL Database Azure SQL felügyelt példánya

Megjegyzés

Ez a cikk a személyes adatok eszközről vagy szolgáltatásból való törlésének lépéseit ismerteti, és a GDPR tartozó kötelezettségek támogatásához használható. A GDPR kapcsolatos általános információkért tekintse meg a Microsoft adatvédelmi központ GDPR szakaszát , valamint a szolgáltatás-megbízhatósági portál GDPR szakaszát.

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

Az adatbázis biztonsági másolatai elengedhetetlen részét képezik az üzletmenet-folytonossági és vészhelyreállítási stratégiáknak, mivel megvédik 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 visszaállítását a konfigurált megőrzési időszakon belül egy adott időpontra. Ha az adatvédelmi szabályok megkövetelik, hogy a biztonsági másolatok hosszabb ideig (legfeljebb 10 évig) elérhetők, konfigurálhatja a hosszú távú megőrzést az egy- és a készletbekészletett adatbázisokhoz is.

Biztonsági mentés gyakorisága

Az SQL Database és SQL Managed Instance is SQL Server technológiát használ a teljes biztonsági mentések hetente, különbségi biztonsági mentések 12–24 óránként, valamint a tranzakciónaplók 5–10 percenkénti biztonsági mentéséhez. A tranzakciós naplók 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.

Adatbázis visszaállításakor a szolgáltatás határozza meg, hogy mely teljes, különbözeti és tranzakciós naplók biztonsági másolatát kell visszaállítani.

Tárhely-redundancia biztonsági mentése

Alapértelmezés szerint a SQL Database és SQL Managed Instance georedundáns tárolóblobban tárolja az adatokat, amelyek egy párosított régióba vannak replikálva. Ez segít védekezni az elsődleges régióban található biztonsági mentési tárterületet kimaradásokkal szemben, és lehetővé teszi, hogy katasztrófa esetén egy másik régióba állítsa vissza a kiszolgálót.

A biztonsági másolatok tárhelyredundansának konfigurálása lehetővé teszi a helyileg redundáns, zónaredundáns vagy georedundáns tárolási blobok közötti választást egy SQL Managed Instance vagy egy SQL Database. Annak érdekében, hogy az adatok ugyanabban a régióban maradnak, ahol a felügyelt példány vagy az SQL-adatbázis üzembe van állítva, módosíthatja az alapértelmezett georedundáns biztonsági mentési tárhely-redundanciát, és konfigurálhatja a helyileg redundáns vagy zónaredundáns tárolóblobokat a biztonsági mentéshez. A tárhelyredundania mechanizmusai több másolatot tárolnak az adatokról, így védve vannak a tervezett és nem tervezett eseményektől, beleértve az átmeneti hardverhibákat, a hálózati vagy áramkimaradásokat, illetve a súlyos természeti katasztrófákat. A beállított biztonsági mentési tárhely-redundancia a biztonsági másolatok rövid távú megőrzési beállításaira is alkalmazva van, amelyek az időponthoz való visszaállításhoz (PITR) és a hosszú távú biztonsági mentések (LTR) hosszú távú megőrzési biztonsági mentéséhez használatosak.

A SQL Database biztonsági mentési tárhely-redundancia konfigurálható az adatbázis létrehozásakor, vagy frissíthető egy meglévő adatbázis esetében; a meglévő adatbázison végrehajtott módosítások csak a jövőbeli biztonsági mentések esetén érvényesek. Egy meglévő adatbázis biztonsági mentési tárhelyredundansának frissítése után a módosítások alkalmazása akár 48 órát is igénybe vehet. Vegye figyelembe, hogy a georedundáns visszaállítás az adatbázis helyi vagy zónaredundáns tárolás használatára való frissítése után le lesz tiltva.

Fontos

A biztonsági másolatok tárhelyredundansát úgy konfigurálhatja a felügyelt példány létrehozása során, hogy az erőforrás kiépítése után már nem lehet módosítani a tárhely-redundanciát.

Fontos

A zónaredundáns tárolás jelenleg csak bizonyos régiókban érhető el.

Megjegyzés

A biztonsági mentési tárhely redundanciának konfigurálható Azure SQL Database jelenleg nyilvános előzetes verzióban érhető el Dél-Brazília területén, és általánosan csak Délkelet-Ázsia Azure-régiójában érhető el. Ez a funkció a hyperscale szint esetében még nem érhető el.

Biztonsági másolat használata

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

  • Meglévő adatbázis időponthoz időben való visszaállítása - Meglévő adatbázis visszaállítása egy múltbeli időpontra a megőrzési időtartamon belül az Azure Portal, Azure PowerShell, az Azure CLI vagy a REST API. A SQL Database művelet létrehoz egy új adatbázist ugyanazon a kiszolgálón, mint az eredeti adatbázist, de más nevet használ az eredeti adatbázis felülírása érdekében. 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, majd átnevezheti a visszaállított adatbázist az eredeti adatbázis nevére. Hasonlóképpen, SQL Managed Instance művelet másolatot készít az adatbázisról ugyanazon vagy egy másik felügyelt példányon ugyanabban az előfizetésben és régióban.
  • Törölt adatbázis időponthoz időben való visszaállítása - Törölt adatbázis visszaállítása a törlési időpontra vagy a megőrzési időszakon belüli bármely időpontra. A törölt adatbázis csak arra a kiszolgálóra vagy felügyelt példányra állítható vissza, ahol az eredeti adatbázist létrehozták. Adatbázis törlésekor a szolgáltatás a tranzakciónapló végső biztonsági másolatát készíti el a törlés előtt az adatvesztés elkerülése érdekében.
  • Georedúnó-visszaállítás - Adatbázis visszaállítása egy másik földrajzi régióba. A földrajzi visszaállítás lehetővé teszi a helyreállítást egy földrajzi katasztrófa után, ha nem fér hozzá az elsődleges régióban található adatbázishoz vagy biztonsági másolathoz. Új adatbázist hoz létre bármely meglévő kiszolgálón vagy felügyelt példányon, bármely Azure-régióban.

    Fontos

    A georedundáns visszaállítás csak a georedundáns biztonsági mentési tárolással konfigurált SQL-adatbázisokhoz vagy felügyelt példányokhoz érhető el.

  • Visszaállítás hosszú távú biztonsági mentésből - Adatbázis visszaállítása egy adott hosszú távú biztonsági másolatból egyetlen adatbázisról vagy készletbe állítva, ha az adatbázis hosszú távú megőrzési szabályzattal (LTR) lett konfigurálva. A LTR lehetővé teszi az adatbázis egy régi verziójának visszaállítását a Azure Portal vagy Azure PowerShell használatával egy megfelelőségi kérés teljesítéséhez vagy az alkalmazás egy régi verziójának futtatásához. További információkért lásd: Hosszú távú megőrzés.

Visszaállítás végrehajtásához lásd: Adatbázis visszaállítása biztonsági másolatból.

Megjegyzés

Az Azure Storage-ban a replikáció kifejezés a blobok egyik helyről a másikra történő másolását jelenti. Az SQL-ban az adatbázis-replikáció különböző technológiákra utal, amelyek több másodlagos adatbázis elsődleges adatbázissal való szinkronizálását tartják.

Az alábbi példákkal kipróbálhatja a biztonsági mentési konfigurációt és a visszaállítási műveleteket:

Művelet Azure Portal Azure PowerShell
Biztonsági másolatok megőrzésének módosítása SQL Database
SQL Managed Instance
SQL Database
SQL Managed Instance
Biztonsági másolatok hosszú távú megőrzésének módosítása SQL Database
SQL Managed Instance – N/A
SQL Database
SQL Managed Instance
Adatbázis visszaállítása egy időpontból SQL Database
SQL Managed Instance
SQL Database
SQL Managed Instance
Törölt adatbázis visszaállítása SQL Database
SQL Managed Instance
SQL Database
SQL Managed Instance
Adatbázis visszaállítása az Azure Blob Storage-ból SQL Database – N/A
SQL Managed Instance – N/A
SQL Database – N/A
SQL Managed Instance

Biztonsági mentés ütemezése

Az első teljes biztonsági mentés az új adatbázis létrehozása vagy visszaállítása után azonnal ütemezve lesz. A biztonsági mentés általában 30 percen belül befejeződik, de hosszabb időt is igénybe vehet, ha az adatbázis nagy méretű. A kezdeti biztonsági mentés például hosszabb időt is igénybe vehet 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ést követően a további biztonsági mentések ütemezése és kezelése automatikusan megtörténik. Az összes adatbázis biztonsági mentésének pontos időzítését a SQL Database vagy SQL Managed Instance határozza meg, mivel ez kiegyensúlyozza a teljes rendszerterhelést. A biztonsági mentési feladatok ütemezése nem változtatható meg és nem tiltható le.

Fontos

Új, visszaállított vagy másolt adatbázishoz az időponthoz időben való 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.

Biztonsági másolatok tárhelyfelhasználása

Az SQL Server biztonsági mentési és visszaállítási technológiájával az adatbázisok adott időpontra való visszaállításához megszakítás nélküli biztonsági mentési láncra van szükség, amely 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. SQL Database és SQL Managed Instance biztonsági mentés ütemezése hetente egy teljes biztonsági mentést tartalmaz. Ezért ahhoz, hogy a PITR a teljes megőrzési időszakon belül engedélyezhető legyen, a rendszernek a konfigurált megőrzési időszaknál legfeljebb egy hétig kell tárolnia a további teljes, különbségi és tranzakciós naplók biztonsági mentését.

Ez azt jelenti, hogy a megőrzési időszak bármely pontján lennie kell egy teljes biztonsági mentésnek, amely a megőrzési időszak legrégebbi idejének régebbi, valamint a különbözeti és tranzakciós naplók biztonsági mentésének folyamatos láncolatát a teljes biztonsági mentésről a következő teljes biztonsági mentésig.

Megjegyzés

A PITR engedélyezéséhez a rendszer további biztonsági másolatokat tárol a beállított megőrzési időtartamnál legfeljebb egy hétig. A biztonsági másolatok tárolásáért az összes biztonsági másolatért azonos díjat kell fizetni.

A PITR funkcióhoz már nem szükséges biztonsági másolatok automatikusan törlődnek. Mivel a különbözeti és a naplók biztonsági mentéséhez egy korábbi teljes biztonsági mentés szükséges, mindhárom biztonsági mentési típust együtt, heti rendszerességgel kiüríti a rendszer.

Minden adatbázis, így a TDE-titkosítású adatbázisok is, a biztonsági másolatok tömörítve vannak a biztonsági másolatok tömörítésének és költségeinek csökkentése érdekében. Az átlagos biztonsági mentési tömörítési arány 3–4-szer nagyobb, de az adatok természetétől és az adatbázis adattömörítésétől függően jelentősen alacsonyabb vagy magasabb is lehet.

SQL Database és SQL Managed Instance összes felhasznált biztonsági mentési tárat összesítve számítja ki. A rendszer óránként jelenti ezt az értéket az Azure számlázási folyamatának, amely ennek az óránkénti használatnak az összesítéséért felelős, hogy kiszámítsa a felhasználást az egyes hónap végén. Az adatbázis törlése után a használat csökken, ahogy a biztonsági másolatok elavadnak, és törlődnek. Ha az összes biztonsági másolat 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 akkor is megmaradnak, ha az adatbázis törölve lett. Bár az adatbázisok törlése és újra létrehozása tárolási és számítási költségeket takaríthat meg, növelheti a biztonsági másolatok tárolási költségeit, mivel a szolgáltatás minden törléskor megőrzi az egyes törölt adatbázisok biztonsági másolatát.

Használat figyelése

A virtuálismag-alapú adatbázisoknál az egyes biztonsági mentések (teljes, különbségi és naplók) által felhasznált tárterület külön metrikaként van jelentve az adatbázis-figyelési panelen. Az alábbi ábra bemutatja, hogyan figyelheti egy adatbázis biztonsági másolatok tárhelyfelhasználását. Ez a funkció a felügyelt példányokhoz jelenleg nem érhető el.

Adatbázis biztonsági mentésének használatának figyelése a Azure Portal

Biztonsági mentési tárterület használatának finomhangolása

A biztonsági másolatok adatbázisonkénti maximális adatméretig való tárolása nem számít fel díjat. A biztonsági másolatok túlzott tárfelhasználása 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ákat a biztonsági másolatok tárhelyfelhasználásának csökkentéséhez:

  • Az igényeinek megfelelően csökkentse a biztonsági másolatok megőrzési időszakát a lehető legalacsonyabbra.
  • Kerülje a szükségesnél gyakoribb nagy írási műveleteket, például index-újraépítéseket.
  • Nagy adatbetöltési műveletek esetén fontolja meg a fürtözött oszlopcentrikus indexek és a kapcsolódó ajánlott eljárások alkalmazásával való használatot,és/vagy csökkentse a nem fürtözött indexek számát.
  • A á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 túl magasak a biztonsági másolatok tárolási költségei, érdemes lehet növelni az adattárolást, hogy pénzt takarítson meg a biztonsági másolatok tárolásához.
  • Ideiglenes eredmények és/vagy átmeneti adatok tárolására használja a TempDB-t állandó táblák helyett az alkalmazáslogikában.
  • Amikor csak lehetséges, használjon helyileg redundáns biztonsági mentési tárolót (például fejlesztési/tesztelési környezetekben)

Biztonsági mentés megőrzése

Minden új, visszaállított és másolt adatbázis esetén a Azure SQL Database és Azure SQL Managed Instance megőrzik a megfelelő biztonsági másolatokat ahhoz, hogy alapértelmezés szerint az elmúlt 7 napon belül engedélyezze a PITR-t. A hyperscale és az alapszintű adatbázisok kivételével a biztonsági másolatok megőrzési időtartama aktív adatbázisonként az 1 és 35 nap között változhat. A Biztonsági másolatok tárhely-használatánakleírásában leírtak szerint a PITR engedélyezéséhez tárolt biztonsági másolatok régebbiek lehetnek a megőrzési időtartamnál. Csak Azure SQL Managed Instance a PITR biztonsági másolatok megőrzési sebességét lehet beállítani, miután egy adatbázis törölve lett a 0–35 napos tartományban.

Ha töröl egy adatbázist, a rendszer ugyanúgy őrzi meg a biztonsági másolatokat, mint egy online adatbázisról, annak adott megőrzési időszakával. A törölt adatbázisok biztonsági másolatok megőrzési időszaka nem változtatható meg.

Fontos

Ha töröl egy kiszolgálót vagy egy felügyelt példányt, a kiszolgálón vagy a felügyelt példányon található összes adatbázis is törlődik, és nem állítható helyre. Törölt kiszolgálót vagy felügyelt példányt nem lehet visszaállítani. Ha azonban hosszú távú megőrzést (LTR) konfigurált egy adatbázishoz vagy felügyelt példányhoz, a hosszú távú megőrzési biztonsági másolatok nem törlődnek, és felhasználhatók adatbázisok visszaállítására egy másik kiszolgálón vagy felügyelt példányon ugyanabban az előfizetésben egy olyan időpontra, amikor hosszú távú megőrzési biztonsági mentés készült.

A biztonsági másolatok elmúlt 1–35 napban történő megőrzését a biztonsági másolatok rövid távú megőrzésének nevezik. Ha a biztonsági másolatokat a 35 napos maximális rövid távú megőrzési időtartamnál hosszabb ideig kell megtartania, engedélyezheti a Hosszú távú megőrzést.

Hosszú távú megőrzés

A SQL Database és SQL Managed Instance akár 10 évig is konfigurálhatja a teljes biztonsági mentés hosszú távú megőrzését (LTR) az Azure Blob Storage-ban. Az LTR-szabályzat konfigurálása után a teljes biztonsági másolatok automatikusan egy másik tárolóba kerülnek hetente. 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 a heti, havi és/vagy éves teljes biztonsági mentések számára. A tárhelyfelhasználás az LTR biztonsági mentések kiválasztott gyakoriságától és megőrzési időtartamától függ. Az LTR-díjkalkulátor használatával megbecsülheti az LTR-tárolás költségét.

Fontos

A biztonsági másolatok tárhely-redundanciának meglévő Azure SQL Database frissítése csak az adatbázis jövőbeli biztonsági másolataira vonatkozik. Az adatbázis meglévő LTR biztonsági másolatai továbbra is a meglévő tárolóblobban, az újak pedig a kért tárolóblobtípuson lesznek tárolva.

További információ a hosszú távú megőrzésről: Biztonsági másolatok hosszú távú megőrzése.

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

A biztonsági másolatok tárolásának díja változó, és a vásárlási modelltől (DTU vagy virtuális mag), a biztonsági mentési tárhely redundancia kiválasztott lehetőségétől, valamint az Ön régiójától függ. A biztonsági másolatok tárterülete felhasznált GB/hó szerint van felszámva. A díjszabási Azure SQL Database oldalon és a díjszabási Azure SQL Managed Instance oldalon található.

Megjegyzés

Az Azure-számla csak a felhasznált többlet biztonsági mentési tárterületet mutatja, a teljes biztonsági mentési tárfelhasználást nem. Ha például egy feltételezett forgatókönyvben 4TB adattárhelyet létesített, 4TB szabad tárhelyet kap a biztonsági másolatból. Ha felhasználta az összesen 5,8 TEB biztonsági mentési tárterületet, az Azure-számla csak 1,8 TEB-t fog mutatni, mivel csak a felhasznált felesleges biztonsági mentési tárterületet kell fizetnie.

DTU-modell

A DTU-modellben az adatbázisok és rugalmas készletek biztonsági mentési tárterülete díjmentes. A biztonsági másolatok tárolásának ára az adatbázis vagy a készlet árának része.

Virtuálismag-alapú modell

Az adatbázison SQL Database adatbázis maximális adattárolási méretének 100%-ával egyenlő biztonsági mentési tárterület díjmentes. Rugalmas készletek és felügyelt példányok esetén a készlet maximális adattárolásának 100%-ának megfelelő biztonsági mentési tárterület, illetve a példány maximális tárolóméretének 100%-a díjmentes.

Az egyedi adatbázisok esetén ez az egyenlet számítja ki a teljes számlázható biztonsági mentési tárhasználatot:

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

A készletbekészletett adatbázisoknál a rendszer a teljes számlázható biztonsági mentési tárterület méretét a készlet szintjén összesíti, és a számítása a következőképpen történik:

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

Felügyelt példányok esetén a rendszer a teljes számlázható biztonsági mentési tárméretet a példány szintjén összesíti, és az alábbiak szerint számítja ki:

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ület GB/hó díjban lesz kiszámlázva a felhasznált biztonsági mentési tárhely-redundancia sebességének megfelelő módon. A biztonsági másolatok tárhelyfelhasználása 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ómentésekkel is vannak, mivel a biztonsági másolatok mérete arányos az adatváltozások mennyiségével. Ezért az ilyen adatbázisok magasabb biztonsági mentési díjakat fognak fizetni.

SQL Database és SQL Managed Instance a teljes számlázható biztonsági mentési tárterületet az összes biztonsági mentési fájl összesített értékeként számítja ki. Ezt az értéket óránként jelenti a rendszer az Azure számlázási folyamatának, amely ezt az óránkénti használatot összesíti a biztonsági másolatok tárterület-használatának minden hónap végén való lekért érdekében. Egy adatbázis törlésekor a biztonsági másolatok tárhelyfelhasználása fokozatosan csökken, ahogy a régebbi biztonsági másolatok elavadnak és törlődnek. Mivel a különbözeti és a naplók biztonsági mentéséhez egy korábbi teljes biztonsági mentés szükséges, mindhárom biztonsági mentési típust együtt, heti rendszerességgel kiüríti a rendszer. Az összes biztonsági másolat törlése után a számlázás leáll.

Egyszerűsített példaként tegyük fel, hogy egy adatbázis 744 GB biztonsági mentési tárterületet gyűjtött össze, és ez az összeg állandó marad egy teljes hónapban, mivel az adatbázis teljesen tétlen. Az összesített tárterület-használat óránkénti használatra való átalakításához ossza el azt 744,0-s értéken (havonta 31 nap * naponta 24 óra). SQL Database az Azure számlázási folyamatnak, hogy az adatbázis óránként 1 GB PITR biztonsági mentést fogyasztott, állandó sebességgel. Az Azure-számlázás összesíti ezt a használatot, és 744 GB-os használatot mutat a teljes hónapra. A költség az adott régióban található összeg/GB/hónap alapján lesz felszámulva.

Most pedig egy összetettebb példa. Tegyük fel, hogy ugyanazon tétlen adatbázis megőrzési ideje 7 napról 14 napra nőtt a hónap közepén. Ez a növekedés a teljes biztonsági mentési tárterület 1488 GB-ra való duplálását teszi ki. SQL Database 1 GB használatot jelent az 1 és 372 óra (a hónap első felében) között. Ez 2 GB-os használatot jelent a 373 és 744 óra (a hónap második felében) között. A használatot egy havi 1116 GB-os végső számlán összesítjük.

A biztonsági mentés tényleges 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 idővel változó, az egyes különbségi és naplóbeli biztonsági mentések mérete is eltérő lesz, így a biztonsági másolatok óránkénti tárfelhasználása ennek megfelelően ingadozik. Emellett 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, így az összes különbségi biztonsági mentés teljes mérete egy hét alatt fokozatosan nő, majd meredeken csökken, ha egy régebbi, teljes, különbségi és naplóbeli biztonsági mentések elavadtak. Ha például egy nagy írási tevékenységet, például az index-újraépítést nem sokkal a teljes biztonsági mentés befejezése után futtattak, akkor az index újraépítése által végzett módosítások bekerülnek az újraépítés idejére készült tranzakciónapló-biztonsági mentésekbe, a következő különbségi biztonsági mentésbe és minden különbségi biztonsági mentésbe, amely a következő teljes biztonsági mentésig készült. Nagyobb adatbázisok esetén az optimalizálás a szolgáltatásban teljes biztonsági mentést hoz létre különbségi biztonsági mentés helyett, ha a különbségi biztonsági mentés egyébként túl 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ípusokkal (teljes, különbségi, tranzakciós napló) a biztonsági másolatok teljes tárterület-fogyasztását az adott időszakra vonatkozó figyelésről lásd: Használat figyelése.

Tárhely-redundancia biztonsági mentése

A biztonsági másolatok tárhelyredundansa a következő módon befolyásolja a biztonsági mentési költségeket:

  • helyileg redundáns ár = x
  • zónaredundáns ár = 1,25x
  • georedundáns ár = 2x

A Backup Storage díjszabására vonatkozó további részletekért Azure SQL Database és díjszabását Azure SQL Managed Instance oldalon talál.

Fontos

A felügyelt SQL-példányok konfigurálható biztonsági mentési tárhelyredundansa az összes Azure-régióban elérhető, és jelenleg csak Délkelet-Ázsia Azure-régiójában érhető el, SQL Database. Felügyelt példányok esetén csak a felügyelt példány létrehozása folyamat során lehet megadni. Az erőforrás kiépítése után nem módosíthatja a biztonsági mentési tárhely redundancia beállítását.

Költségek figyelése

A biztonsági másolatok tárolási költségeinek Cost Management + Billing a Azure Portal válassza a Cost Management, majd a Költségelemzés lehetőséget. Válassza ki a kívánt előfizetést Hatókörként, majd szűrjön arra az időszakra és szolgáltatásra, amely önt érdekli.

Adjon hozzá egy szűrőt a szolgáltatásnévhez, majd a legördülő listában válassza az sql database lehetőséget. A fogyasztásmérő alkategóriája szűrővel válassza ki a szolgáltatás számlázási számlálóját. Egyetlen adatbázishoz vagy rugalmas adatbáziskészlethez válassza az egy-/rugalmas készlet PITR biztonsági mentési tárolót. Felügyelt példányhoz válassza a mi PITR biztonsági mentési tárolót. A Storage és a Compute alkategóriák is érdekesek lehetnek, de ezek nem kapcsolódnak a biztonsági mentési tárolási költségekhez.

Biztonsági mentési tár költségelemzése

Megjegyzés

A mérők csak a jelenleg használatban lévő számlálók számára 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ányok számlálói például nem lesznek jelen az olyan ügyfelek számára, akik nem telepítettek felügyelt példányt. Hasonlóképpen, a tárolószámlálók nem láthatók a tárterületet nem felhasználó erőforrásoknál.

Titkosított biztonsági másolatok

Ha az adatbázis TDE-titkosítással van titkosítva, a biztonsági másolatok titkosítása automatikusan megtörténik, beleértve az LTR biztonsági mentéseket is. A TDE alapértelmezés szerint Azure SQL összes új adatbázist A TDE alapértelmezés szerint engedélyezve van. További információ a TDE-ről: transzparens adattitkosítás a SQL Database & SQL Managed Instance.

Biztonsági mentés integritása

A mérnöki csapat folyamatosan Azure SQL automatikus adatbázis-biztonsági mentések visszaállítását. (Ez a tesztelés jelenleg nem érhető el a SQL Managed Instance.) Az időponthoz időben történő visszaállításkor az adatbázisok a DBCC CHECKDB integritási ellenőrzéseit is megkapják.

Az integritás ellenőrzése során talált problémák riasztást eredményeznek a mérnöki csapatnak. További információ: Adatintegritás a SQL Database.

Az adatbázisok biztonsági mentése a CHECKSUM beállítással lehetséges a biztonsági mentés további integritásának biztosítása érdekében.

Megfelelőség

Amikor az adatbázist egy DTU-alapú szolgáltatási szintről egy virtuálismag-alapú szolgáltatási szintre MIM-re milagitálja, a PITR-megőrzés megmarad annak érdekében, hogy az alkalmazás adat-helyreállítási szabályzata ne sérülje. 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 megőrzési időszakot. További információ: A PITR biztonsági másolatok megőrzési időtartamának módosítása.

Megjegyzés

Ez a cikk a személyes adatok eszközről vagy szolgáltatásból való törlésének lépéseit ismerteti, és a GDPR tartozó kötelezettségek támogatásához használható. A GDPR kapcsolatos általános információkért tekintse meg a Microsoft adatvédelmi központ GDPR szakaszát , valamint a szolgáltatás-megbízhatósági portál GDPR szakaszát.

A PITR biztonsági másolat megőrzési időtartamának módosítása

A PITR biztonsági másolat alapértelmezett megőrzési időszakát a Azure Portal, a PowerShell vagy a REST API. Az alábbi példák bemutatják, hogyan lehet a PITR-megőrzést 28 napra módosítani.

Figyelmeztetés

Ha csökkenti az aktuális megőrzési megőrzési időszakot, akkor nem tud az új megőrzési időszaknál régebbi időpontra visszaállítani. Törlődnek azok a biztonsági másolatok, amelyekre már nincs szükség a PITR-nek az új megőrzési időszakon belül való megőrzéshez. Ha növeli az aktuális megőrzési időszakot, nem fog azonnal visszaállni a régebbi időpontra az új megőrzési időszakon belül. Ezt a képességet idővel meg is nyerheti, mivel a rendszer egyre hosszabb ideig őrzi meg a biztonsági másolatokat.

Megjegyzés

Ezek az API-k csak a PITR megőrzési időszakra vannak hatással. Ha konfigurálta az LTR-t az adatbázishoz, az nem lesz hatással rá. A hosszú távú megőrzési időtartamok változását lásd: Hosszú távú megőrzés.

A PITR biztonsági másolat megőrzési időszakának módosítása a Azure Portal

Az aktív adatbázisok PITR biztonsági mentésének megőrzési időszakának Azure Portal használatával úgy módosíthatja a kiszolgálót vagy a felügyelt példányt, hogy az adatbázisokat, amelyeknek a megőrzési időszakát módosítani szeretné. A bal oldali panelen válassza a Biztonsági mentések lehetőséget, majd a Megőrzési szabályzatok lapot. Válassza ki azokat az adatbázisokat, amelyekhez módosítani szeretné a PITR biztonsági másolatok megőrzését. Ezután a műveletsávon válassza a Megőrzés konfigurálása lehetőséget.

A PITR biztonsági másolat megőrzési időtartamának módosítása a PowerShell használatával

Megjegyzés

Ez a cikk frissült az Azure Az PowerShell-moduljának használatával. Mostantól az Az PowerShell-modul használatát javasoljuk az Azure-ral folytatott interakciókhoz. Az Az PowerShell-modul használatának megkezdéséhez lásd az Azure PowerShell telepítését ismertető szakaszt. Az Az PowerShell-modulra történő migrálás részleteiről lásd: Az Azure PowerShell migrálása az AzureRM modulból az Az modulba.

Fontos

A PowerShell AzureRM modult továbbra is támogatja a SQL Database és SQL Managed Instance, de minden jövőbeli fejlesztés az Az.Sql modulra lesz kitérve. További információ: AzureRM.Sql. Az Az modulban található parancsok argumentumai lényegesen megegyeznek az AzureRm-modulokban található argumentumokkal.

A PITR biztonsági másolatok megőrzésének az aktív Azure SQL az alábbi PowerShell-példával módosíthatja.

# SET new PITR backup retention period on an active individual database
# Valid backup retention must be between 1 and 35 days
Set-AzSqlDatabaseBackupShortTermRetentionPolicy -ResourceGroupName resourceGroup -ServerName testserver -DatabaseName testDatabase -RetentionDays 28

Módosítsa a PITR biztonsági másolatok megőrzési időszakát a REST API

Mintakérés

PUT https://management.azure.com/subscriptions/00000000-1111-2222-3333-444444444444/resourceGroups/resourceGroup/providers/Microsoft.Sql/servers/testserver/databases/testDatabase/backupShortTermRetentionPolicies/default?api-version=2017-10-01-preview

A kérés törzse

{
  "properties":{
    "retentionDays":28
  }
}

Mintaválasz

Állapotkód: 200

{
  "id": "/subscriptions/00000000-1111-2222-3333-444444444444/providers/Microsoft.Sql/resourceGroups/resourceGroup/servers/testserver/databases/testDatabase/backupShortTermRetentionPolicies/default",
  "name": "default",
  "type": "Microsoft.Sql/resourceGroups/servers/databases/backupShortTermRetentionPolicies",
  "properties": {
    "retentionDays": 28
  }
}

További információ: Biztonsági másolatok megőrzése REST API.

Mintakérés

PUT https://management.azure.com/subscriptions/00000000-1111-2222-3333-444444444444/resourceGroups/resourceGroup/providers/Microsoft.Sql/servers/testserver/databases/testDatabase/backupShortTermRetentionPolicies/default?api-version=2017-10-01-preview

A kérés törzse

{
  "properties":{
    "retentionDays":28
  }
}

Mintaválasz

Állapotkód: 200

{
  "id": "/subscriptions/00000000-1111-2222-3333-444444444444/providers/Microsoft.Sql/resourceGroups/resourceGroup/servers/testserver/databases/testDatabase/backupShortTermRetentionPolicies/default",
  "name": "default",
  "type": "Microsoft.Sql/resourceGroups/servers/databases/backupShortTermRetentionPolicies",
  "properties": {
    "retentionDays": 28
  }
}

További információ: Biztonsági másolatok megőrzése REST API.

Biztonsági másolatok tárhely-redundanciának konfigurálása

Megjegyzés

A felügyelt példányok biztonsági SQL Managed Instance konfigurálható tárhelyredundansát csak a felügyelt példány létrehozása során lehet megadni. Az erőforrás kiépítése után nem módosíthatja a biztonsági mentési tárhely redundancia beállítását. A SQL Database a funkció nyilvános előzetes verziója jelenleg Dél-Brazília régióban érhető el, és általánosan elérhető Délkelet-Ázsia Azure-régiójában.

A felügyelt példányok biztonsági mentési tárhelyredundansát csak a példány létrehozása során lehet beállítani. A SQL Database az adatbázis létrehozásakor beállítható, vagy frissíthető egy meglévő adatbázishoz. Az alapértelmezett érték a georedundáns tárolás. A helyileg redundáns, zónaredundáns és georedundáns biztonsági mentési tárterület díjszabásának eltéréseiért látogasson el a felügyelt példányok díjszabási oldalára.

A biztonsági mentési tárhely redundanciának konfigurálása a Azure Portal

A Azure Portal a biztonsági mentési tárhely redundanciát a Biztonsági másolat létrehozása SQL Database konfigurálhatja. A beállítás a Backup Storage Redundancy (Biztonsági mentési tárredundania) szakaszban érhető el. Nyissa meg a Create SQL Database (SQL Database létrehozása) panelt

Biztonsági mentési tárhely redundanciának konfigurálása a PowerShell használatával

Új adatbázis létrehozásakor a biztonsági mentési tárhely redundanciának konfigurálásához megadhatja a -BackupStoageRedundancy paramétert. Lehetséges értékek: Geo, Zóna és Helyi. Alapértelmezés szerint minden SQL-adatbázis georedundáns tárolást használ a biztonsági mentéshez. A georedundáns visszaállítás le van tiltva, ha helyi vagy zónaredundáns biztonsági mentési tárolóval hoz létre adatbázist.

# Create a new database with geo-redundant backup storage.  
New-AzSqlDatabase -ResourceGroupName "ResourceGroup01" -ServerName "Server01" -DatabaseName "Database03" -Edition "GeneralPurpose" -Vcore 2 -ComputeGeneration "Gen5" -BackupStorageRedundancy Geo

Részletekért látogasson el a New-AzSqlDatabase webhelyre.

Egy meglévő adatbázis biztonsági mentési tárhelyredundansának frissítéséhez használhatja a -BackupStorageRedundancy paramétert. Lehetséges értékek: Geo, Zóna és Helyi. Vegye figyelembe, hogy akár 48 órát is igénybe vehet, hogy a rendszer alkalmazza a módosításokat az adatbázison. A georedundáns biztonsági mentési tárhelyről a helyi vagy zónaredundáns tárolásra való váltás letiltja a georedundáns visszaállítást.

# Change the backup storage redundancy for Database01 to zone-redundant. 
Set-AzSqlDatabase -ResourceGroupName "ResourceGroup01" -DatabaseName "Database01" -ServerName "Server01" -BackupStorageRedundancy Zone

Részletekért látogasson el a Set-AzSqlDatabase webhelyre.

Megjegyzés

A -BackupStorageRedundancy paraméter adatbázis-visszaállítással, adatbázis-másolással vagy másodlagos műveletekkel való létrehozásához használja Azure PowerShell Az.Sql 2.11.0-s verzióját.

Biztonsági Azure Policy biztonsági mentési tárhely redundanciának kikényszerítéséhez használja a biztonsági másolatokat

Ha olyan adatredundáns követelményekkel rendelkezik, amelyek megkövetelik, hogy az összes adatot egyetlen Azure-régióban tárolja, akkor a SQL Database vagy a felügyelt példány zónaredundáns vagy helyileg redundáns biztonsági mentését a Azure Policy. Azure Policy egy olyan szolgáltatás, amely az Azure-erőforrásokra szabályokat vonatkozó szabályzatok létrehozására, hozzárendelésére és kezelésére használható. Azure Policy segít, hogy ezek az erőforrások megfeleljenek a vállalati szabványoknak és szolgáltatói szerződéseknek. További információ: Overview of Azure Policy.

Beépített biztonsági mentési tárhelyredundania-szabályzatok

Az új beépített szabályzatok hozzáadása után az előfizetés vagy az erőforráscsoport szintjén lehet hozzárendelni az új adatbázisok vagy példányok georedundáns biztonsági mentési tárolóval való létrehozásának blokkolásához.

SQL Database grS biztonsági mentési redundancia használatának elkerülése

A felügyelt SQL-példányok ne használjanak GRS biztonsági mentési redundanciát

A felügyelt és felügyelt példány beépített szabályzatdefinícióinak teljes SQL Database itt található.

Az adatelhellyel kapcsolatos követelmények szervezeti szinten való érvényesítéséhez ezek a szabályzatok hozzárendelhetőek egy előfizetéshez. Miután ezek hozzá vannak rendelve az előfizetés szintjén, az adott előfizetés felhasználói nem hozhatnak létre adatbázist vagy felügyelt példányt georedundáns biztonsági mentési tárterülettel az Azure Portal vagy Azure PowerShell.

Fontos

Az Azure-szabályzatok nem érvényesítve vannak, amikor T-SQL-en keresztül hoz létre adatbázist. Ha az adatbázis T-SQL használatával való létrehozásakor meg kell kényszerítenie az adatrezidencia-adatokat, használja a "LOCAL" vagy a "ZONE"bemenetként BACKUP_STORAGE_REDUNDANCY paramétert a CREATE DATABASE utasításban.

Megtudhatja, hogyan rendelhet hozzá szabályzatokat a Azure Portal vagy Azure PowerShell

Következő lépések

  • Az adatbázis biztonsági másolatai elengedhetetlen részét képezik az üzletmenet-folytonossági és vészhelyreállítási stratégiáknak, mivel megvédik az adatokat a véletlen sérüléstől vagy törléstől. Az üzletmenet-folytonossági megoldások SQL Database az Üzletmenet-folytonosság áttekintése témakörben talál további információt.
  • További információ az adatbázisok időponthoz való visszaállításáról a következő Azure Portal.
  • További információ arról, hogyan állítható vissza egy adatbázis egy időpontra a PowerShell használatával.
  • Az Azure Blob Storage-beli automatikus biztonsági mentések hosszú távú megőrzésének az Azure Portal használatával történő konfigurálásával, kezelésével és visszaállításával kapcsolatos információkért lásd: Abiztonsági másolatok hosszú távú megőrzésének kezelése a Azure Portal.
  • Az Automatikus biztonsági másolatok hosszú távú megőrzésének konfigurálása, kezelése és visszaállítása az Azure Blob Storage-ban a PowerShell használatával: A biztonsági másolatok hosszú távú megőrzésének kezelése a PowerShellhasználatával.
  • A biztonsági másolatok tárhelyfelhasználásának részletes Azure SQL Managed Instance A felügyelt példányok tárhelyfelhasználásának magyarázata.
  • A biztonsági másolatok tárolási megőrzésének és költségeinek finomhangolásával kapcsolatos Azure SQL Managed Instance a felügyelt példányok biztonsági mentési tárolási költségeinek finomhangolásával kapcsolatos cikkből megtudhatja.