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

Automatikus biztonsági mentések rugalmas skálázású adatbázisokhoz

  • Cikk

A következőre vonatkozik: Azure SQL Database

Ez a cikk az Azure SQL Database rugalmas skálázású adatbázisaival rendelkező automatikus biztonsági mentési funkciót ismerteti.

A rugalmas skálázású adatbázisok egyedi architektúrát használnak, magas skálázható tárolási és számítási teljesítményszintekkel. A rugalmas skálázású biztonsági mentések pillanatképalapúak, és szinte azonnal elérhetők. A naplók biztonsági mentései hosszú távú Azure-tárolóban vannak tárolva a biztonsági mentés megőrzési ideje alatt.

A rugalmas skálázású architektúra nem igényel teljes, különbségi vagy napló biztonsági mentést. Így a biztonsági mentés gyakorisága, a tárolási költségek, az ütemezés, a tárolóredundancia és a visszaállítási képességek eltérnek az Azure SQL Database többi adatbázisától.

Biztonsági mentési és visszaállítási teljesítmény

A tárolás és a számítási elkülönítés lehetővé teszi, hogy a rugalmas skálázás leküldje a biztonsági mentési és visszaállítási műveleteket a tárolási rétegbe, hogy kiküszöbölje a számítási replikák erőforrás-felhasználását. Az adatbázis biztonsági mentései nem befolyásolják sem az elsődleges, sem a másodlagos számítási replikák teljesítményét.

A rugalmas skálázású adatbázisok biztonsági mentési és visszaállítási műveletei az adatmérettől függetlenül gyorsak, mivel tárolási pillanatképeket használnak. A biztonsági mentés gyakorlatilag azonnali.

Az adatbázist a biztonsági mentés megőrzési időszakán belül bármikor visszaállíthatja a következő módon:

  1. Visszaállítás a vonatkozó fájlpillanatképekre.
  2. Tranzakciónaplók alkalmazása a visszaállított adatbázis tranzakciós konzisztenssé tétele érdekében.

Így a visszaállítás nem adatméretű művelet, amely változatlan marad. A rugalmas skálázású adatbázisok visszaállítása ugyanabban az Azure-régióban órák vagy napok helyett percekben fejeződik be, még több terabájtos adatbázisok esetében is.

A tárterület redundanciának módosítása a visszaállítás kiadásakor hosszabb visszaállítási időt eredményezhet, mivel a visszaállítás az adatok mérete, ezért az idő arányos az adatbázis méretével.

Az új adatbázisok létrehozása meglévő biztonsági mentés visszaállításával vagy az adatbázis másolásával szintén kihasználja a rugalmas skálázású számítási és tárolási elkülönítés előnyeit. Ha ugyanazt a tártípust használja, percek alatt létrehozhat másolatokat fejlesztési vagy tesztelési célokra, akár több terabájtos adatbázisokból is.

Biztonsági mentés megőrzése

A rugalmas skálázású adatbázisok biztonsági másolatainak alapértelmezett rövid távú megőrzése 7 nap.

A biztonsági másolatok rövid távú megőrzése 1 és 35 nap között, valamint a rugalmas skálázású adatbázisok hosszú távú biztonsági mentés-megőrzési (LTR) képessége 2023 szeptemberétől általánosan elérhető. További információ: Hosszú távú megőrzés – Azure SQL Database és Felügyelt Azure SQL-példány.

Biztonsági mentés ütemezése

A rugalmas skálázású adatbázisok esetén nincs hagyományos teljes, különbségi és tranzakciónapló-alapú biztonsági mentés. Ehelyett rendszeres tároló-pillanatképek készülnek az adatfájlokról.

A létrehozott tranzakciónaplók a konfigurált megőrzési időszakhoz hasonlóan megmaradnak. A visszaállításkor a rendszer a vonatkozó tranzakciónapló-rekordokat alkalmazza a visszaállított tárolási pillanatképre. Az eredmény egy tranzakciós konzisztens adatbázis, amely a megőrzési időszakon belül a megadott időponttól kezdve adatvesztés nélkül működik.

Biztonsági másolatok tárolási felhasználásának monitorozása

Rugalmas skálázás esetén az Azure Monitor-metrikák a következő használati adatokat jelentik:

  • Adatmentési tárterület mérete (pillanatkép biztonsági mentésének mérete)
  • Adattárolás mérete (lefoglalt adatbázis mérete)
  • Napló biztonsági mentési tárhelyének mérete (tranzakciónapló biztonsági mentési mérete)

A biztonsági mentési és adattárolási metrikák az Azure Portalon való megtekintéséhez kövesse az alábbi lépéseket:

  1. Nyissa meg azt a rugalmas skálázású adatbázist, amelynek biztonsági mentési és adattárolási metrikáit figyelni szeretné.
  2. A Figyelés szakaszban válassza a Metrikák lapot.
  3. A Metrika legördülő listában válassza ki az adatmentési tárolót, az adattárolás méretét és a napló biztonsági mentésének tárolási metrikáját egy megfelelő összesítési szabálysal.

Screenshot of the Azure portal that shows selections for viewing Hyperscale backup storage consumption.

A biztonsági másolatok tárolási felhasználásának csökkentése

A rugalmas skálázású adatbázisok biztonsági mentési tárterület-felhasználása a megőrzési időszaktól, a régió kiválasztásától, a biztonsági mentési tár redundanciától és a számítási feladatok típusától függ. Fontolja meg az alábbi hangolási technikákat a rugalmas skálázású adatbázisok biztonsági mentési tárterület-felhasználásának csökkentéséhez:

  • Csökkentse a biztonsági mentések 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 indexkarbantartást. Az indexkarbantartási javaslatokért lásd : Indexkarbantartás optimalizálása a lekérdezési teljesítmény javítása és az erőforrás-felhasználás csökkentése érdekében.
  • Nagy adatbetöltési műveletek esetén érdemes lehet szükség esetén adattömörítést használni.
  • Az alkalmazáslogikában lévő állandó táblák helyett használja az tempdb adatbázist ideiglenes eredmények és/vagy átmeneti adatok tárolására.
  • Helyileg redundáns vagy zónaredundáns biztonsági mentési tárolót használjon, ha a georedundáns visszaállítási képesség szükségtelen (például fejlesztési/tesztelési környezetek).

Backup-tárhellyel kapcsolatos díjak

A rugalmas skálázású adatbázisok biztonsági másolatainak tárolási költsége a régiótól és a biztonsági mentési tároló redundanciájától függ. A számítási feladat típusától is függ.

Az írásigényes számítási feladatok gyakrabban módosítják az adatoldalakat, ami nagyobb tároló-pillanatképeket eredményez. Az ilyen számítási feladatok további tranzakciónaplókat is létrehoznak, ami hozzájárul a biztonsági mentés általános költségeihez. A biztonsági mentési tárterület díja a havonta felhasznált gigabájt alapján történik. A díjszabás részleteiért tekintse meg az Azure SQL Database díjszabási oldalát.

Rugalmas skálázás esetén a számlázható biztonsági mentési tár a következőképpen lesz kiszámítva:

Total billable backup storage size = (data backup storage size + log backup storage size)

Az adattárolás mérete nem szerepel a számlázható biztonsági másolatban, mert már lefoglalt adatbázis-tárolóként van számlázva.

A törölt rugalmas skálázású adatbázisok biztonsági mentési költségekkel járnak a törlés előtti időpontig történő helyreállítás támogatásához. Törölt rugalmas skálázású adatbázisok esetén a rendszer a következő módon számítja ki a számlázható biztonsági mentési tárterületet:

Total billable backup storage size for deleted Hyperscale database = (data storage size + data backup size + log backup storage size) * (remaining backup retention period after deletion / configured backup retention period)

Az adattárolás mérete szerepel a képletben, mert a lefoglalt adatbázis-tárterületet nem külön számlázzák a törölt adatbázisokért. Törölt adatbázisok esetén a rendszer a törlés után tárolja az adatokat, hogy lehetővé tegye a helyreállítást a biztonsági másolatok konfigurált megőrzési ideje alatt.

A törölt adatbázisok számlázható biztonsági mentési tárhelye a törlés után fokozatosan csökken. Nullává válik, ha a biztonsági másolatok már nem őrződnek meg, és a helyreállítás már nem lehetséges. Ha végleges törlésről van szó, és már nincs szüksége biztonsági másolatokra, optimalizálhatja a költségeket az adatbázis törlése előtt a megőrzés csökkentésével.

Biztonsági mentés költségeinek monitorozása

A biztonsági mentés tárolási költségeinek megismerése:

  1. Lépjen a Költségkezelés + Számlázás menüponthoz az Azure Portalon.

  2. Válassza a Cost Management>Cost Analysis lehetőséget.

  3. A Hatókör mezőben válassza ki a kívánt előfizetést.

  4. Az alábbi lépések végrehajtásával szűrheti a kívánt időtartamot és szolgáltatást:

    1. Adjon hozzá egy szűrőt a szolgáltatásnévhez.
    2. Válassza ki az SQL-adatbázist a legördülő listából.
    3. Adjon hozzá egy másik szűrőt a Meterhez.
    4. Az időponthoz kötött helyreállítás biztonsági mentési költségeinek monitorozásához válassza a legördülő listából a Tárolt adatok – Biztonsági mentés – RA lehetőséget.

Az alábbi képernyőképen egy példa költségelemzés látható.

Screenshot of the Azure portal that shows Hyperscale Backup storage costs.

Adat- és biztonsági mentési tár redundancia

A rugalmas skálázás támogatja a konfigurálható tárolóredundanciát. Rugalmas skálázású adatbázis létrehozásakor kiválaszthatja a kívánt tárolási típust: olvasási hozzáférésű georedundáns tárolás (RA-GZRS), olvasási hozzáférésű georedundáns tárolás (RA-GRS), zónaredundáns tárolás (ZRS) vagy helyileg redundáns tárolás (LRS).

  • Geozónaredundáns tárolás: 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. a zónaredundáns tároláshoz (ZRS) hasonló. Emellett aszinkron módon másolja az adatokat a párosított másodlagos régió egyetlen fizikai helyére. Jelenleg csak bizonyos régiókban érhető el.

A biztonsági másolatok más tárolótípusokra való replikálásáról további információt a biztonsági mentési tár redundanciájával kapcsolatban talál.

Mivel a rugalmas skálázás tárolási pillanatképeket használ a biztonsági mentésekhez, az adatok és a biztonsági másolatok ugyanazt a tárfiókot használják. Ennek eredményeképpen a kiválasztott biztonsági mentési tár redundancia mind az adatokra, mind a biztonsági mentésekre alkalmazható.

Megjegyzés:

Ha rugalmas skálázású adatbázist hoz létre, körültekintően készítsen biztonsági másolatot a tárterületről, mert csak az adatbázis létrehozásakor állíthatja be. Ezt a beállítást az erőforrás kiépítése után nem módosíthatja.

Az aktív georeplikálással frissítheti egy meglévő rugalmas skálázású adatbázis biztonsági másolatainak redundanciabeállítását minimális állásidővel. Másik lehetőségként használhatja az adatbázis-másolást is.

Figyelmeztetés:

Rugalmas skálázású adatbázis visszaállítása másik régióba

Előfordulhat, hogy vissza kell állítania a rugalmas skálázású adatbázist az aktuális régiótól eltérő régióba. A gyakori okok közé tartozik a vészhelyreállítási művelet, a részletezés vagy az áthelyezés. Az elsődleges módszer az adatbázis georeduktúra-visszaállítása. Ugyanazokat a lépéseket kell végrehajtania, mint az Azure SQL Database bármely más adatbázisának egy másik régióba való visszaállításához:

  1. Hozzon létre egy kiszolgálót a célrégióban, ha még nem rendelkezik megfelelő kiszolgálóval. Ennek a kiszolgálónak ugyanazzal az előfizetéssel kell rendelkeznie, mint az eredeti (forrás)kiszolgálónak.
  2. Kövesse a lap georedukciós szakaszában található utasításokat egy adatbázis azure SQL Database-ben történő automatikus biztonsági mentésből való visszaállításáról.

Megjegyzés:

Mivel a forrás és a cél külön régiókban található, az adatbázis nem oszthatja meg a pillanatkép-tárolót a forrásadatbázissal, ahogy a nem földrajzi visszaállításokban is. A nem földrajzi visszaállítások az adatbázis méretétől függetlenül gyorsan befejeződnek.

A rugalmas skálázású adatbázisok georedundáns visszaállítása adatméretű művelet, még akkor is, ha a cél a georeplikált tároló párosított régiójában található. A georedundáns visszaállítás ezért jelentősen hosszabb időt vesz igénybe, mint az ugyanabban a régióban lévő időponthoz kötött visszaállítás.

Ha a cél a párosított régióban van, az adatátvitel egy régión belül lesz. Ez az átvitel jelentősen gyorsabb lesz, mint a régiók közötti adatátvitel. Ez azonban továbbra is adatméretű művelet lesz.

Tetszés szerint másik régióba másolhatja az adatbázist. Ezt a módszert akkor használja, ha a georedundáns visszaállítás nem érhető el, mert a kiválasztott tárterület-redundanciatípus nem támogatja. További részletekért tekintse meg a rugalmas skálázás adatbázismásolatát.

Kapcsolódó tartalom

Az adatbázis-biztonsági másolatok 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 véletlen sérüléstől vagy törléstől.