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.

Az Azure Backup jelenleg nem képes megérteni a HSR beállítását. Ez azt jelenti, hogy a HSR elsődleges és másodlagos csomópontjai két különálló, nem kapcsolódó virtuális gépként lesznek kezelve. Először konfigurálnia kell a biztonsági mentést az elsődleges csomóponton. Feladatátvétel esetén a biztonsági mentést a másodlagos csomóponton kell konfigurálni (amely mostantól az elsődleges csomópont lesz). Nincs automatikus feladatátvétel a biztonsági mentésről a másik csomópontra.

Az aktív (elsődleges) csomópont adatainak biztonsági mentéséhez bármely adott időpontban átállíthatja a védelmet arra a másodlagos csomópontra, amely a feladatátvétel után az elsődleges csomóponttá vált.

A kapcsolóvédelem végrehajtásához kövesse az alábbi lépéseket:

• Védelem leállítása (adatok megőrzésével) az elsődlegesen
• Az előregisztrációs szkript futtatása a másodlagos csomóponton
• A másodlagos csomópont adatbázisainak felderítése és biztonsági másolatok konfigurálása

Ezeket a lépéseket minden feladatátvétel után manuálisan kell végrehajtani. Ezeket a lépéseket az Azure Portalon kívül parancssorban/HTTP REST-ben is végrehajthatja. A lépések automatizálásához használhat egy Azure-runbookot.

Íme egy részletes példa a kapcsolóvédelem végrehajtására:

Ebben a példában két csomópont található: az 1. csomópont (elsődleges) és a 2. csomópont (másodlagos) a HSR beállításában. A biztonsági mentések az 1. csomóponton vannak konfigurálva. Ahogy fentebb említettük, még ne próbálja meg konfigurálni a biztonsági mentéseket a 2. csomóponton.

Amikor az első feladatátvétel történik, a 2. csomópont lesz az elsődleges. Majd

1. Állítsa le az 1. csomópont (előző elsődleges) védelmét az adatmegőrzési beállítással.
2. Futtassa az előregisztrációs szkriptet a 2. csomóponton (amely most az elsődleges).
3. Fedezze fel a 2. csomópont adatbázisait, rendeljen hozzá biztonsági mentési szabályzatot, és konfigurálja a biztonsági mentéseket.

Ezután egy első teljes biztonsági mentés aktiválódik a 2. csomóponton, és a befejezés után elindulnak a naplók biztonsági mentései.

Amikor a következő feladatátvétel történik, az 1. csomópont ismét elsődleges lesz, a 2. csomópont pedig másodlagos lesz. Most ismételje meg a folyamatot:

1. Állítsa le a 2. csomópont védelmét az adatmegőrzési beállítással.
2. Futtassa az előregisztrációs szkriptet az 1. csomóponton (amely ismét elsődlegessé vált)
3. Ezután folytassa a biztonsági mentést az 1. csomóponton a szükséges szabályzattal (mivel a biztonsági mentések korábban leálltak az 1. csomóponton).

Ezután a rendszer ismét elindítja a teljes biztonsági mentést az 1. csomóponton, és a befejezés után elindulnak a naplók biztonsági mentései.

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 ODBC Csatlakozás ionError használatával kezdi el 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.

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.