Hosszú távú adatmegőrzési biztonsági másolatok – Azure SQL Database és Azure SQL Managed Instance

A következőre vonatkozik: :Azure SQL DatabaseAzure SQL Managed Instance

Ez a cikk az Azure SQL Database és Azure SQL Managed Instance hosszú távú megőrzési (LTR) biztonsági mentéseinek fogalmi áttekintését tartalmazza. A hosszú távú megőrzés akár 10 évig is beállítható a biztonsági mentéseken az Azure SQL Database-hez (beleértve a hiperskálázási szolgáltatási szintet is) és az Azure SQL Managed Instance-hoz.

A hosszú távú adatmegőrzési biztonsági mentési funkció használatának megkezdéséhez lásd:

Fontos

A hosszú távú adatmegőrzési (LTR) biztonsági mentési műveletekhez használt régebbi API-k elavultak, és már nem támogatottak. Kerülje a régi PowerShell-parancsmagok, például Copy-AzSqlDatabaseLongTermRetentionBackup használatát. Ehelyett használja a cikkben ismertetett támogatott visszaállítási módszereket.

A hosszú távú megőrzés működése

Számos alkalmazás rendelkezik olyan jogszabályi, megfelelőségi vagy egyéb üzleti okkal, amelyek miatt az automatikus biztonsági mentések rövid távú megőrzési időszaka által biztosított 1–35 napon túl is meg kell őriznie az adatbázis biztonsági mentéseit. A hosszú távú biztonsági mentési megőrzés (LTR) a Azure SQL szolgáltatás által automatikusan létrehozott teljes adatbázis-biztonsági mentésekre támaszkodik. További információért lásd: Az Automatizált biztonsági mentések az Azure SQL Database-ben vagy Az Automatizált biztonsági mentések az Azure SQL Managed Instance-ban.

Az LTR funkcióval a megadott teljes SQL Database-adatbázist és SQL Managed Instance biztonsági mentéseket redundáns Azure Blob Storage-ban tárolhatja, akár 10 éves konfigurálható adatmegőrzési szabályzattal. Az LTR biztonsági mentések új adatbázisként állíthatók helyre. Ha egy LTR-szabályzat van konfigurálva, az automatikus biztonsági mentések különböző blobokra lesznek másolva a hosszú távú tároláshoz, amelyek segítségével visszaállíthatja az adatbázist egy adott időpontra. A másolási folyamat olyan háttérfeladat, amely nem befolyásolja az adatbázis számítási feladatainak teljesítményét. Az egyes adatbázisok LTR-szabályzata azt is megadhatja, hogy milyen gyakran jönnek létre az LTR biztonsági másolatok.

Megjegyzés:

Az LTR engedélyezéséhez négy paraméter kombinációjával határozhat meg egy szabályzatot: heti biztonsági mentés megőrzés (W), havi biztonsági mentés megőrzés (M), éves biztonsági mentés megőrzés (Y) és az év hetének (WeekOfYear). Ha W értéket ad meg, a rendszer hetente egy biztonsági másolatot másol hosszú távú tárolóba. Ha M értéket ad meg, a rendszer minden hónap első biztonsági másolatát átmásolja a hosszú távú tárolóba. Ha Y értéket ad meg, a WeekOfYear által megadott héten egy biztonsági másolat lesz átmásolva a hosszú távú tárolóba. Ha a megadott WeekOfYear a szabályzat konfigurálásakor a múltban van, az első LTR biztonsági mentés a következő évben jön létre. Minden biztonsági mentés hosszú távú tárolóban marad az LTR biztonsági mentés létrehozásakor konfigurált szabályzatparamétereknek megfelelően.

Az LTR-szabályzat módosításai csak a jövőbeli biztonsági mentésekre vonatkoznak. Ha például módosítja a heti biztonsági mentési megőrzést (W), a havi biztonsági mentési megőrzést (M), vagy az éves biztonsági mentési megőrzést (Y), az új megőrzési beállítás csak az új biztonsági másolatokra vonatkozik. A meglévő biztonsági másolatok megőrzése nem módosul. Az LTR-szabályzat konfigurálható az egyes adatbázisokhoz Azure SQL Database és Azure SQL Managed Instance. Ha a régi LTR biztonsági másolatokat a megőrzési időszak lejárta előtt szeretné törölni, manuálisan törölheti a biztonsági másolatokat.

Megjegyzés:

Az Azure SQL Database és az Azure SQL Managed Instance esetében, amikor először engedélyez egy LTR-szabályzatot egy adatbázishoz, a rendszer a legutóbbi teljes biztonsági mentést az időponthoz kötött visszaállításból (PITR) hosszú távú tárolóba másolja.

Példák az LTR-szabályzatra:

  • W=0, M=0, Y=5, WeekOfYear=3

    Minden év harmadik teljes biztonsági másolatát öt évig őrzik meg.

  • W=0, M=3, Y=0

    Minden hónap első teljes biztonsági másolatát három hónapig őrzi meg a rendszer.

  • W=12, M=0, Y=0

    Minden heti teljes biztonsági mentés 12 hétig tart.

  • W=6, M=12, Y=10, WeekOfYear=20

    Minden heti teljes biztonsági mentést hat hétig őrizünk meg. Kivéve minden hónap első teljes biztonsági másolatát, amelyet 12 hónapig őriznek meg. Kivéve az év 20. hetében készült teljes biztonsági mentést, amelyet 10 évig őriznek meg.

Az alábbi táblázat a következő szabályzat hosszú távú biztonsági mentéseinek gyakoriságát és lejáratát mutatja be:

W=12 weeks (84 nap), M=12 months (365 nap), Y=10 years (3650 nap), WeekOfYear=20 (a május 13.utáni hét)

Az alábbi dátumok az ISO 8601 (YYYY-MM-DD) szabványban találhatók.

PITR biztonsági mentés az LTR-be LejáratI idő Lejárat hónap Lejárat Y
2018-03-07 2019-03-02
2018-03-14 2018-06-06
2018-03-21 2018-06-13
2018-03-28 2018-06-20
2018-04-04 2019-03-30
2018-04-11 2018-07-04
2018-04-18 2018-07-11
2018-04-25 2018-07-18
2018-05-02 2019-04-27
2018-05-09 2018-08-01
2018-05-16 2028. 05. 13.
2018-05-23 2018-08-15
2018-05-30 2018-08-22
2018-06-06 2019-06-01
2018-06-13 2018-09-05
2018-06-20 2018-09-12
2018-06-27 2018-09-19
2018-07-04 2019-06-29
2018-07-11 2018-10-03
2018-07-18 2018-10-10
2018-07-25 2018-10-17
2018-08-01 2019-07-27
2018-08-08 2018-10-31
2018-08-15 2018-11-07
2018-08-22 2018-11-14
2018-08-29 2018-11-21

Ha módosítja ezt a házirendet, és beállítja W=0 (nincs heti biztonsági mentés), a heti biztonsági másolatok mindaddig megmaradnak, amíg lejárnak, majd a szolgáltatás csak a havi és az éves biztonsági másolatokat őrzi meg. Az LTR-szabályzat nem tárolja a jövőbeli heti biztonsági mentéseket. A biztonsági mentések megtartásához szükséges tárterület ennek megfelelően csökken.

Fontos

Az egyes LTR-biztonsági mentések időzítését az Microsoft vezérli. Nem hozhat létre manuálisan LTR biztonsági mentést, és nem szabályozhatja a biztonsági mentés létrehozásának időzítését. Az LTR-szabályzat konfigurálása után akár hét napig is eltarthat, amíg az első LTR biztonsági mentés megjelenik az elérhető biztonsági másolatok listájában.

Ha töröl egy logikai kiszolgálót vagy egy felügyelt SQL-példányt, a rendszer az adott kiszolgálón vagy felügyelt példányon lévő összes adatbázist is törli. Törölt logikai kiszolgáló vagy felügyelt SQL-példány nem állítható vissza. Ha azonban az LTR-t egy adatbázishoz konfigurálta, az LTR biztonsági másolatai nem törlődnek, és az adatbázisok egy másik kiszolgálóra vagy felügyelt példányra való visszaállítására használhatók ugyanabban az előfizetésben, az LTR biztonsági mentésének idejére.

Hasonlóképpen, ha töröl egy adatbázist, az LTR biztonsági másolatai nem törlődnek, és megmaradnak a konfigurált megőrzési időszakra. Ezek a biztonsági másolatok visszaállíthatók ugyanarra a kiszolgálóra vagy egy másik kiszolgálóra ugyanabban az előfizetésben.

Georeplikáció és a biztonsági mentések hosszú távú megőrzése

Ha aktív georeplikációs vagy feladatátvételi csoportokat használ üzletmenet-folytonossági megoldásként, készüljön fel a végleges feladatátvételekre, és konfigurálja ugyanazt az LTR-szabályzatot a másodlagos adatbázison vagy példányon, mint az elsődlegesen. Az LTR tárolási költsége nem nő, mivel a biztonsági másolatok nem a másodlagos fájlokból jönnek létre. A biztonsági másolatok csak akkor jönnek létre, ha a másodlagos elsődlegessé válik, így biztosítva az LTR biztonsági mentések folyamatos létrehozását feladatátvétel esetén, és az elsődleges a másodlagos régióba kerül.

Amikor az eredeti elsődleges adatbázis helyreáll a feladatátvételt okozó leállásokból, az lesz az új másodlagos. Ezért a biztonsági mentés létrehozása nem folytatódik az új másodlagos rendszeren, és a meglévő LTR-szabályzat addig nem lép érvénybe, amíg ismét elsődlegessé nem válik.

Hálózati biztonsági periméter és LTR visszaállítás (előzetes)

Megjegyzés:

A hálózati biztonsági periméter (preview) csak az Azure SQL Database-re vonatkozik. Az Azure SQL Managed Instance nem regisztrált erőforrás, így ez a szakasz nem vonatkozik rá. Az aktuális listát lásd: Onboarded privát link erőforrások.

Az LTR visszaállítás egy platformon keresztül menedzselt művelet, amely egy adatbázist hosszú távú biztonsági mentésből egy cél logikai szerverre állít vissza. Ha bármelyik logikai szerver egy periméterhez tartozik, a visszaállítás a periméter hozzáférési szabályainak hatálya alá kerül.

A szolgáltatás ellenőrzi a forrásszerver kimenő hozzáférését, ha az a szerver még létezik, valamint a bejövő hozzáférést a célszerveren. Ha a forrás logikai szervert törölték, csak a céloldali bejövő ellenőrzés futhat.

Támogatott konfigurációk

Az LTR visszaállítás mind átmeneti, mind kényszerített módban működik. Átmeneti módban a visszaállítások hozzáférési szabályok nélkül sikeresek. Állítsd be a szabályokat, mielőtt átváltanál kikényszerített módra.

Kényszerített módban ezek a konfigurációk támogatottak:

Forráskiszolgáló Célkiszolgáló Hozzáférési szabályok megadása szükséges
Egy kerületen belül Ugyanazon a területen None. Az azonos periméteren belüli erőforrások közötti hozzáférés mindig engedélyezett.
A kerületben Egy másik kerületben Kimenő a forrás oldalon, bejövő a cél oldalon.
A kerületben Nincs kerületen belül Kimenő a forráson.
Nem a határon belül Egy kerületben Bejövő a célpontra.
Törölve A kerületben A cél felé tart.
Nincs a kerületen belül Nincs periméteren None.

Az LTR visszaállításhoz nem kell menedzselt identitás.

Hozzáférési szabályok konfigurálása az LTR visszaállításhoz

  1. Rendeld az egyes logikai szervereket a peremterületükhöz, ha még nem tetted meg. Hagyd ki ezt a lépést egy olyan szerver esetében, amely kívül van a perimeteren, vagy egy törölt forrásszervernél.
  2. Ha a forrásszerver egy peremben van, és a célszerver nem ugyanabban a peremben van, adj hozzá egy kimenő szabályt a forrásprofilhoz, ahol a Cél típusa értéke FQDN, és a célszerver teljes tartományneve van megadva.
  3. Ha a célszerver egy perimeteren van, és a forrásszerver nem ugyanazon a periméteren van, adj hozzá egy bejövő szabályt a célprofilon. A visszaállítási kérelem az Azure SQL menedzsment infrastruktúrából érkezik, nem a forrásszerverről. A szabályban engedélyezzük az alábbi források egyikét:
    • A forrásszerver előfizetési azonosítója (ajánlott).
    • A szervizcímke (ajánlott).
    • IP-címtartományok. A nyilvános felhő esetében az Azure IP Ranges and Service Tags - Public Cloud felsorolja az összes szolgáltatáscímkét és annak IP-címtartományait. A szervizcímke neve: SqlManagement. A Microsoft nem publikálja ezeket a tartományokat régiónként, tehát engedélyezze mindet.
  4. Mivel a szerverek még átmeneti módban vannak, indítsd el a visszaállítást, és ellenőrizd a hálózati biztonsági perem-diagnosztikai naplókat váratlan elutasításokat keresve.
  5. Csak akkor válts kényszerített módra, ha minden diagnosztikai ellenőrzés sikeresen lefutott.

Korlátok és viselkedésbeli különbségek

  • Nem lehet törölni egy logikai szervert, amelynek van LTR biztonsági mentése, miközben a perimeter assosiációja kényszerített módban van. A változtathatatlan LTR biztonsági mentések szintén megakadályozzák a törlést, függetlenül attól, hogy a szerver peremhálózatban van-e. További információért lásd: Végleges, hosszú távú biztonsági mentések és logikai kiszolgálók törlése.
  • Ha töröl egy forrásszervert, miközben az összekapcsolódás átmeneti módban van, a szolgáltatás már nem tudja olvasni az adott szerver perem-metaadatait, így csak a visszaállítás céloldalát tudja validálni. Vedd figyelembe ezt a hiányosságot, ha a forrásoldali validációra támaszkodsz kontrollként.
  • Átmeneti módban a visszaállítás akkor is sikeres, ha hiányoznak a szükséges szabályok. Kényszerített módban ugyanaz a visszaállítás blokkolva van.

A biztonsági mentés hosszú távú megőrzésének konfigurálása

Fontos

A hosszú távú adatmegőrzési (LTR) biztonsági mentési műveletekhez használt régebbi API-k elavultak, és már nem támogatottak. Kerülje a régi PowerShell-parancsmagok, például Copy-AzSqlDatabaseLongTermRetentionBackup használatát. Ehelyett használja a cikkben ismertetett támogatott visszaállítási módszereket.

A biztonsági mentés hosszú távú megőrzését a Azure portál és a PowerShell használatával konfigurálhatja Azure SQL Database és Azure SQL Managed Instance. Ha az LTR-tárolóból szeretne visszaállítani egy adatbázist, kiválaszthatja a biztonsági mentést az időbélyege alapján. Az adatbázis bármely meglévő kiszolgálóra vagy felügyelt példányra visszaállítható az eredeti adatbázissal megegyező előfizetés alatt . A visszaállítási képességek, korlátozások és funkciók teljes listáját a Restore-funkciók Azure SQL Managed Instance című témakörben találja.

Ha az LTR megőrzési időszakának utolsó hét napján visszaállítási kérést kezdeményeznek, az LTR biztonsági mentése csak a visszaállítási művelet befejezése után törlődik, még akkor is, ha a megőrzési időszak lejárt.

Megjegyzés:

A rugalmas skálázású szolgáltatási szint és a Azure SQL Database egyéb szolgáltatási szintjei közötti adatbázisok visszaállítása jelenleg nem támogatott.

A Azure SQL Managed Instance SQL Agent-feladatok használatával ütemezheti a copy-only adatbázis biztonsági mentését és áthelyezheti őket a saját tárfiókjába a következők alternatívaként:

  • A biztonsági másolatokat 10 évnél hosszabb ideig őrizze meg.
  • Az adatbázisok napi másolatait 35 napnál hosszabb ideig őrizze meg.
  • Az adatbázis biztonsági másolatait nem módosítható tárolón tárolja.

Jótanács

Ha LTR-biztonsági másolatokat használ a megfelelőség vagy más kritikus fontosságú követelmények teljesítéséhez, fontolja meg rendszeres helyreállítási próbák elvégzését annak ellenőrzéséhez, hogy az LTR biztonsági másolatok visszaállíthatók-e, és hogy a visszaállítás a várt adatbázis-állapotot eredményezi-e.

Megjegyzés:

Az LTR biztonsági mentések a teljes biztonsági mentések sikerességétől függenek. A teljes tranzakciónapló megakadályozhatja az ütemezett teljes biztonsági mentést, ami pedig megakadályozza az LTR mentést. A változásadat-rögzítés (CDC) és más funkciók, amelyek megakadályozzák a tranzakciónaplók lerövidítését, késleltethetik az LTR mentést, amely csak akkor sikerül, ha a teljes mentés sikeres lesz. Értékelje azokat a funkciókat, amelyek megakadályozzák a tranzakciónapló levágását, és fontold meg ideiglenesen letiltani őket, amíg a mentési műveletek helyreállnak.

Következő lépés

A biztonsági mentés hosszú távú megőrzésének Azure SQL Database kezelése

Azure SQL Managed Instance hosszú távú biztonsági mentésmegőrzés kezelése

Kapcsolódó tartalom

Mivel az adatbázis biztonsági mentései megvédik az adatokat a véletlen sérüléstől vagy törléstől, elengedhetetlen részei az üzletmenet-folytonossági és vészhelyreállítási stratégiának.

  • Utolsó frissítés időpontja: