Gyakori kérdések – SAP HANA-adatbázisok biztonsági mentése Azure-beli virtuális gépeken

Egy nap alatt egy teljes és több igény szerinti biztonsági mentést ütemezhet.

A sikeres biztonsági mentési feladatok ma nem hoznak létre riasztásokat. A riasztások csak a sikertelen biztonsági mentési feladatokhoz jönnek létre. Megtudhatja, hogyan tekintheti meg a biztonsági mentési riasztásokat az Azure Portalon.

A biztonsági másolatok állapotát (ütemezett/igény szerinti) az alábbi helyek bármelyikéről ellenőrizheti:

1. Biztonsági mentési feladatok: Az Azure Backup az Összes manuálisan aktivált feladatot megjeleníti az Azure Portal Biztonsági mentési feladatok szakaszában.
   
   Az Azure Portalon látható feladatok magukban foglalják az adatbázisok felderítését és regisztrálását, valamint a biztonsági mentési és visszaállítási műveleteket. Az ütemezett feladatok, beleértve a naplók biztonsági mentéseit, ebben a szakaszban nem jelennek meg. Az SAP HANA natív ügyfeleiről (Studio/Cockpit/DBA Cockpit) manuálisan aktivált biztonsági másolatok szintén nem jelennek meg itt.

   

   

2. Biztonsági mentési riasztások: A riasztások segítenek monitorozni az SAP HANA-adatbázisok biztonsági mentéseit. Ezek segítenek a szükséges eseményekre összpontosítani, így kiküszöbölve a biztonsági mentés által generált számos esemény gyakori ellenőrzésére irányuló erőfeszítést. További részletekért lásd : Biztonsági mentési riasztások megtekintése.

3. Biztonsági mentési jelentések: A jelentések egy másik módszer a biztonsági mentési feladatok állapotának megtekintésére. A jelentések a következők lesznek:

   

   

   Megtudhatja , hogyan konfigurálhatja az Azure Backup-jelentéseket.

4. SAP HANA Natív ügyfelek: Ha Ön SAP HANA-ügyfél, használhatja a HANA Studiót is, amely az egyik leggyakoribb HANA-ügyfél. Ebben az ügyfélben lépjen a Biztonsági mentési konzol –>Backup katalógusra a biztonsági mentés állapotának megtekintéséhez.

   

A Biztonsági mentési feladat menü csak az igény szerinti biztonsági mentési feladatokat jeleníti meg, amelyek folyamatban vannak, sikeresek vagy sikertelenek. Ütemezett feladatokhoz használja az Azure Monitort.

Az Azure Backup nem állít be explicit megőrzési időtartamot a teljes biztonsági mentés automatikus javításakor. Ez a biztonsági mentés mindaddig megmarad, amíg meg nem tartja a függő delta (különbségi vagy növekményes) és a napló biztonsági mentéseit. Miután törölte az utolsó függő biztonsági mentést ezen az automatikus javításon, az automatikus javítás biztonsági mentése is törlődik.

Igen, a teljes biztonsági mentés és a napló biztonsági mentése egyszerre is futtatható. Ez a példány a következő módok egyikével fordul elő:

• A teljes biztonsági mentés folyamatban van, és a napló biztonsági mentése aktiválódik: A napló biztonsági mentésének sikeresnek kell lennie, függetlenül attól, hogy folyamatban van-e a teljes biztonsági mentés. Kivéve, ha az aktivált teljes biztonsági mentés teljes körű volt az LSN-lánctörések kezeléséhez.
• A napló biztonsági mentése folyamatban van, és a rendszer elindít egy teljes biztonsági másolatot: Mindkét biztonsági mentésnek egyszerre kell futnia, és sikeresnek kell lennie.

Nem, ez jelenleg nem támogatott.

Ha egy adatbázist elvet egy SAP HANA-példányból, a rendszer továbbra is megkísérli az adatbázis biztonsági mentését. Ez azt jelenti, hogy a törölt adatbázis nem megfelelő állapotúként jelenik meg a Biztonsági mentési elemek területen, és továbbra is védett. Az adatbázis védelmének leállításához a megfelelő módszer a biztonsági mentés leállítása az adatbázis törlési adataival .

Az átnevezett adatbázisok új adatbázisként lesznek kezelve. Ezért a szolgáltatás úgy kezeli ezt a helyzetet, mintha az adatbázis nem található volna, és sikertelen lesz a biztonsági mentés. Az átnevezett adatbázis új adatbázisként jelenik meg, és a védelemhez konfigurálva kell lennie.

Az SAP HANA-adatbázisokhoz készült Azure Backup használatának első lépéseiről részletes útmutatót talál az oktatóanyagban. A biztonsági mentések konfigurálására és kezelésére a parancssori felület is használható.

Tekintse meg az Azure Backup SAP HANA-val való használatának előfeltételeit .

Tekintse meg a hibaelhárítási útmutató jelen szakaszát .

Tekintse meg ezt a szakaszt a hibaelhárítási útmutatóban.

Jelenleg nem tudjuk beállítani a megoldást virtuális IP-cím vagy proxy alapján. A megoldás végrehajtásához egy virtuális gépre van szükségünk.

Igény szerinti biztonsági mentést indíthat az SAP HANA natív ügyfeleivel a helyi fájlrendszerbe a Backint helyett. További információ a műveletek sap natív ügyfelekkel történő kezeléséről.

A HANA-katalógust az SAP által javasolt módszerekkel, például a BACKUP CATALOG DELETE utasításokkal vagy a HANA Studio/Cockpit utasításokkal lehet eltávolítani. További információ a műveletek sap natív ügyfelekkel történő kezeléséről.

1. HANA-rendszerreplikációs (HSR) esetén a másodlagos csomópont egyáltalán nem fogad el kapcsolatokat. A biztonsági mentés konfigurálása után az Azure Backup szolgáltatás rendszeresen pingel, és sikertelen lesz. Előfordulhat, hogy ezek a sikertelen kísérletek az elsődleges csomóponton jelennek meg. Több hiba után a felhasználó zárolva van, majd az elsődleges csomópont az ODBCConnectionError használatával kezdi a feladatátvételt.
   
   Megfigyeltük, hogy nem minden felhasználó tapasztalja ezt a problémát. Javasoljuk, hogy az SAP-nak vizsgálja meg annak okát, hogy a felhasználók az elsődleges csomóponton zárolva lettek-e, ha a felhasználói kapcsolat meghiúsul a másodlagos csomóponton.

2. Az előregisztrációs szkript futtatása után a felhasználói adatok új jelszóval frissülnek az elsődleges csomóponton. Ezután újra létrejön a biztonsági mentési kísérlethez szükséges kapcsolat. De előfordulhat, hogy ismét ugyanazt a forgatókönyvet tapasztalja.

3. Emellett a másodlagos csomóponton sikertelen biztonsági másolatok (teljes biztonsági másolatok) riasztásokat hoznak létre.

A fenti problémák elkerülése érdekében javasoljuk, hogy állítsa le a csomópont védelmét a másodlagossá válása után (hogy a kapcsolatok ne legyenek megkísérelve, és a felhasználó ne legyen zárolva), és folytassa a védelmet rajta, amint az elsődlegessé válik. Ha nem szembesül ezzel a zárolási helyzettel a HSR-beállításaikban, és elégedett a riasztások generálásával, mindkét csomóponton konfigurálhatja a biztonsági másolatokat, hogy a szolgáltatás kezelje az átvételt és a feladat-visszavételt.

Tekintse meg az Azure Backup által a HANA számítási feladatokhoz biztosított biztonsági mentési és visszaállítási teljesítményt .

Ha a HANA-rendszert úgy szeretné beállítani, hogy kihasználja a jobb teljesítményt, használja a következő erőforrásokat:

• Lemeztípus kiválasztása Azure IaaS virtuális gépekhez – felügyelt lemezek
• Azure-beli felügyelt lemezek teljesítményszintjei
• M sorozat
• SAP HANA Azure-beli virtuálisgép-tárolók konfigurációi

Az SAP HANA-hoz készült Azure Backup jelenleg 1-et fogad el a parallel_backup_using_backint tulajdonság értékeként. Az Azure Backup azonban több streamben osztotta fel az egy streamet a jobb teljesítmény érdekében.

Jelenleg csak a Háttérrendszer-alapú biztonsági mentések támogatottak a HSR-hez. A pillanatképek még nem.

Az állapot frissítéséhez futtatnia kell a példány újraészlelését a "Nem kész" jelölésű kiszolgálón.

A biztonsági mentési művelet során a biztonsági mentési feladat három szolgáltatásvégponthoz csatlakozik – AzureBackupAzureStorageés Microsoft Entra ID. In this scenario, we recommend you to configure the Service Endpoint to az AzureStorage", amelyek segítenek a virtuális hálózatból érkező forgalmat közvetlenül a Tárolóba küldeni. Az Azure Backup és a Microsoft Entra ID esetében konfigurálhatja az UDR-t szolgáltatáscímkéken keresztül, hogy a forgalom a helyszíni helyett a gerinchálózatra haladjon.

A Recovery Services-tároló megjeleníti az SAP HANA-rendszerreplikációs szolgáltatás részét képező összes csomópontot. Az összes csomópont a kimenetnek megfelelően jelenik meg hdbnsutil . A várt viselkedésnek megfelelően azonban csak a tárolóban konfigurált csomópont van regisztrálva.

Amikor a Backint-ügynökkel aktiválja a hdbbackint biztonsági mentési feladatot, az adatokat ír a /var/tmp könyvtárba. Ha például hiba történik a biztonsági mentési folyamat során, a hibaüzenet a könyvtár egyik fájljában /var/tmp lesz megírva. A fájlnév olyan formátumban hdbbackint_<SID>.<random_string>jön létre, amely <SID> az SAP HANA-példány rendszerazonosítója, és <random_string> véletlenszerűen generált sztring.

A biztonsági mentési folyamat nem lesz hatással, ha törli a hdbbackint fájlt a /var/tmp könyvtárban. A biztonsági mentési folyamat során azonban eltávolíthatja a fájlba írt hibaüzeneteket.

HaNA-rendszerenként vagy példányonként legfeljebb 10 visszaállítást hajthat végre egy nap alatt. Vegye figyelembe, hogy ha egy visszaállítás megszakítva vagy sikertelen, az visszaállítási kísérletnek is minősül.

Ellenőrizze, hogy teljesülnek-e a cél SAP HANA-példány visszaállításának előfeltételei. További információ: Előfeltételek – SAP HANA-adatbázisok visszaállítása az Azure-beli virtuális gépen.

A visszaállítás során győződjön meg arról, hogy a Felülírás kényszerítése lehetőség van kiválasztva.

A jelenleg támogatott visszaállítási típusok megtekintéséhez tekintse meg az SAP HANA megjegyzés 1642148 .

Igen, az SLES-en futó HANA-adatbázisokon aktivált streamelési biztonsági másolatok használatával visszaállíthatja azt RHEL HANA-rendszerre, és fordítva. Ez azt jelzi, hogy az operációs rendszer közötti visszaállítás streamelési biztonsági másolatok használatával lehetséges. Azonban gondoskodnia kell arról, hogy a visszaállítani kívánt HANA-rendszer és a visszaállításhoz használt HANA-rendszer is kompatibilis legyen az SAP-nak megfelelő visszaállításhoz. Tekintse meg az SAP HANA Megjegyzés 1642148 , hogy mely visszaállítási típusok kompatibilisek.

Igen, a fájlokat részben az itt dokumentált módon töltheti le.

Igen, le kell tiltania a HANA-rendszerreplikálást (HSR) a célrendszeren, majd végre kell hajtania a visszaállítást. A HSR-kompatibilis rendszer nem állítható vissza az SAP-nak megfelelően.

A szabályzat létrehozása előtt tisztában kell lennie az RPO és az RTO követelményeivel, valamint annak kapcsolódó költségvonzataival.

Az RPO (recovery-point-objective) azt jelzi, hogy mennyi adatvesztés elfogadható a felhasználó/ügyfél számára. Ezt a napló biztonsági mentési gyakorisága határozza meg. A gyakoribb naplózási biztonsági mentések alacsonyabb RPO-t jeleznek, és az Azure Backup szolgáltatás által támogatott minimális érték 15 perc. A naplók biztonsági mentésének gyakorisága tehát 15 perc vagy annál magasabb lehet.

Az RTO (recovery-time-objective) azt jelzi, hogy az adatvesztési forgatókönyv után milyen gyorsan kell visszaállítani az adatokat az utolsó rendelkezésre álló időpontra. Ez a HANA által alkalmazott helyreállítási stratégiától függ, amely általában attól függ, hogy hány fájl szükséges a visszaállításhoz. Ennek költségvonzatai is vannak, és az alábbi táblázatnak segítenie kell az összes forgatókönyv és azok következményeinek megértésében.

Ezért kiválaszthatja a szabályzatvariánst az RPO és az RTO célkitűzései és a költség szempontjai alapján.

Néhány alapelvet szem előtt kell tartani a biztonsági mentési elem szabályzatának az 1. házirendről (P1) a 2. házirendre (P2) való váltásának vagy az 1. házirend (P1) szerkesztésének hatásának meghatározásakor.

• A rendszer az összes módosítást visszamenőlegesen is alkalmazza. A rendszer a legújabb biztonsági mentési szabályzatot alkalmazza a korábban felvett helyreállítási pontokra is. Tegyük fel például, hogy a napi teljes megőrzés 30 nap, és 10 helyreállítási pontot vettek fel az aktuálisan aktív szabályzatnak megfelelően. Ha a napi teljes megőrzési idő 10 napra módosul, akkor az előző pont lejárati ideje is újraszámításra kerül kezdő időpontként + 10 nap, és ha lejárt, törlődik.
• A módosítás hatóköre magában foglalja a biztonsági mentés napját, a biztonsági mentés típusát és a megőrzést is. Például: Ha egy szabályzat napi teljesről heti teljesre változik vasárnaponként, akkor a rendszer a nem vasárnapi összes korábbi teljes értéket törlésre jelöli meg.
• A rendszer nem törli a szülőt, amíg a gyermek aktív/nem lejárt. Minden biztonsági mentési típus az aktuálisan aktív szabályzatnak megfelelően lejárati idővel rendelkezik. A teljes biztonsági mentési típus azonban szülőnek számít a későbbi "különbözet", a "növekményes" és a "naplók" esetében. A "különbség" és a "napló" nem szülők, hogy bárki más. A "növekményes" szülő lehet a későbbi "növekményes". Még ha a "szülő" is törlésre van megjelölve, akkor sem törlődik, ha a gyermek "különbözeti" vagy "naplói" nem lejártak. Ha például egy szabályzat napi teljesről heti teljesre változik vasárnaponként, akkor a nem vasárnapi összes korábbi teljesség törlésre lesz megjelölve. A rendszer azonban csak akkor törli őket, ha a korábban naponta készített naplók lejártak. Más szóval a legutóbbi napló időtartama szerint maradnak meg. A naplók lejárata után a naplók és a teljes adatok is törlődnek.

Ezekkel az alapelvekkel az alábbi táblázatból megismerheti a szabályzatmódosítás következményeit.

A gyökérmappában lévő területet az alábbi lehetőségek egyikével kezelheti:

• Hozzon létre egy saját LV-t a /opt/msawb számára.
• Hozzon létre egy helyreállítható csatolási/szimlinket egy másik helyre/mappába ugyanazon/különböző lemezen.
• Növelje a gyökérpartíción lévő helyet.

Következő lépések

• Megtudhatja, hogyan készíthet biztonsági másolatot az Azure-beli virtuális gépeken futó SAP HANA-adatbázisokról .
• Megtudhatja, hogyan háríthatja el az SAP HANA-adatbázisok biztonsági mentését.