Vanliga frågor och svar – Säkerhetskopiera SAP HANA-databaser på virtuella Azure-datorer

Du kan ha ett schema för fullständig säkerhetskopiering och flera säkerhetskopieringar på begäran på en dag.

I dag genererar inte lyckade säkerhetskopieringsjobb aviseringar. Aviseringar genereras endast för säkerhetskopieringsjobb som misslyckas. Lär dig hur du använder Azure-portalen för att visa säkerhetskopieringsaviseringar.

Du kan kontrollera statusen för dina säkerhetskopior (schemalagda/på begäran) från någon av följande platser:

1. Säkerhetskopieringsjobb: Azure Backup visar alla manuellt utlösta jobb i avsnittet Säkerhetskopieringsjobb i Azure-portalen.
   
   Jobben som visas i Azure-portalen omfattar databasidentifiering och registreringsåtgärder samt säkerhetskopierings- och återställningsåtgärder. Schemalagda jobb, inklusive loggsäkerhetskopior, visas inte i det här avsnittet. Manuellt utlösta säkerhetskopieringar från de inbyggda SAP HANA-klienterna (Studio/Cockpit/DBA Cockpit) visas inte heller här.

   

   

2. Säkerhetskopieringsaviseringar: Aviseringar hjälper dig att övervaka säkerhetskopior av SAP HANA-databaser. Dessa hjälper dig att fokusera på de nödvändiga händelserna, vilket eliminerar arbetet med att ofta kontrollera många händelser som en säkerhetskopia genererar. Mer information finns i Visa säkerhetskopieringsaviseringar.

3. Säkerhetskopieringsrapporter: Rapporter är ett annat sätt att visa status för dina säkerhetskopieringsjobb. Dina rapporter kommer att vara följande:

   

   

   Lär dig hur du konfigurerar Azure Backup-rapporter.

4. SAP HANA Native-klienter: Om du är SAP HANA-kund kan du också använda HANA Studio, en av de vanligaste HANA-klienterna. I den här klienten går du till Säkerhetskopieringskonsolen –> Säkerhetskopieringskatalog för att se säkerhetskopieringsstatus.

   

Menyn Säkerhetskopieringsjobb visar endast säkerhetskopieringsjobb på begäran som antingen pågår, har slutförts eller misslyckats. För schemalagda jobb använder du Azure Monitor.

Azure Backup anger inte någon explicit kvarhållningsperiod för de fullständiga säkerhetskopiorna automatiskt. Den här säkerhetskopieringen behålls tills du behåller beroende Delta (differentiell eller inkrementell) och loggsäkerhetskopior. När du har tagit bort den senaste beroende säkerhetskopieringen av den här säkerhetskopieringen automatiskt tas även säkerhetskopieringen av automatisk läkning bort.

Ja, en fullständig säkerhetskopia och en loggsäkerhetskopia kan köras samtidigt. Den här instansen inträffar på något av följande sätt:

• Fullständig säkerhetskopiering pågår och en loggsäkerhetskopia utlöses: Loggsäkerhetskopian bör lyckas oavsett en pågående fullständig säkerhetskopia. Såvida inte den fullständiga säkerhetskopian som utlöses var en fullständig reparation för att hantera LSN-kedjebrytningar.
• Loggsäkerhetskopiering pågår och en fullständig säkerhetskopia utlöses: Båda säkerhetskopiorna ska köras samtidigt och lyckas.

Nej, det stöds inte för närvarande.

Om en databas tas bort från en SAP HANA-instans görs fortfarande ett försök att säkerhetskopiera databasen. Detta innebär att den borttagna databasen börjar visas som felaktig under Säkerhetskopieringsobjekt och fortfarande är skyddad. Det rätta sättet att sluta skydda den här databasen är att utföra Stoppa säkerhetskopiering med borttagning av data i den här databasen.

En omdöpt databas behandlas som en ny databas. Därför behandlar tjänsten den här situationen som om databasen inte hittades och misslyckas med säkerhetskopiorna. Den omdöpta databasen visas som en ny databas och måste konfigureras för skydd.

I självstudien finns en stegvis guide för att komma igång med Azure Backup för SAP HANA-databaser. Du kan också använda CLI för att konfigurera och hantera säkerhetskopior.

Se förutsättningarna för att använda Azure Backup med SAP HANA.

Se det här avsnittet i felsökningsguiden.

Se det här avsnittet i felsökningsguiden.

För närvarande har vi inte möjlighet att konfigurera lösningen mot en virtuell IP-adress eller proxy. Vi behöver en virtuell dator för att köra lösningen.

Du kan utlösa en säkerhetskopiering på begäran med hjälp av inbyggda SAP HANA-klienter till det lokala filsystemet i stället för Backint. Läs mer om hur du hanterar åtgärder med hjälp av SAP-interna klienter.

Du kan rensa HANA-katalogen med hjälp av REKOMMENDERADE SAP-metoder, till exempel DELETE-instruktioner för SÄKERHETSKOPIERINGSKATALOG eller HANA Studio/Cockpit. Läs mer om hur du hanterar åtgärder med hjälp av SAP-interna klienter.

För närvarande har Azure Backup inte möjlighet att förstå en HSR-konfiguration. Det innebär att de primära och sekundära noderna i HSR behandlas som två enskilda, orelaterade virtuella datorer. Du måste först konfigurera säkerhetskopiering på den primära noden. När en redundansväxling sker måste säkerhetskopieringen konfigureras på den sekundära noden (som nu blir den primära noden). Det finns ingen automatisk redundansväxling av säkerhetskopiering till den andra noden.

Om du vill säkerhetskopiera data från den aktiva (primära) noden vid en viss tidpunkt kan du växla skyddet till den sekundära nod som nu har blivit den primära efter redundansväxlingen.

Följ dessa steg för att utföra det här switchskyddet:

• Stoppa skyddet (med kvarhållningsdata) på primärt
• Kör förregistreringsskriptet på den sekundära noden
• Identifiera databaserna på den sekundära noden och konfigurera säkerhetskopior på dem

De här stegen måste utföras manuellt efter varje redundansväxling. Du kan utföra de här stegen via kommandoraden/HTTP REST utöver Azure-portalen. Om du vill automatisera de här stegen kan du använda en Azure-runbook.

Här är ett detaljerat exempel på hur växelskydd måste utföras:

I det här exemplet har du två noder – Nod 1 (primär) och Nod 2 (sekundär) i HSR-konfigurationen. Säkerhetskopior konfigureras på nod 1. Som nämnts ovan ska du ännu inte försöka konfigurera säkerhetskopior på Nod 2.

När den första redundansväxlingen inträffar blir Nod 2 den primära. Sedan kan du

1. Stoppa skyddet av nod 1 (tidigare primär) med alternativet för att behålla data.
2. Kör förregistreringsskriptet på Nod 2 (som nu är det primära).
3. Identifiera databaser på Nod 2, tilldela säkerhetskopieringsprincip och konfigurera säkerhetskopieringar.

Sedan utlöses en första fullständig säkerhetskopia på Nod 2 och när det är klart startar loggsäkerhetskopiorna.

När nästa redundansväxling inträffar blir Nod 1 primär igen och Nod 2 blir sekundär. Upprepa nu processen:

1. Stoppa skyddet av Nod 2 med alternativet behåll data.
2. Kör förregistreringsskriptet på Nod 1 (som har blivit primärt igen)
3. Återuppta sedan säkerhetskopieringen på nod 1 med den princip som krävs (eftersom säkerhetskopiorna stoppades tidigare på nod 1).

Sedan utlöses fullständig säkerhetskopiering igen på nod 1 och när det är klart startar loggsäkerhetskopiorna.

1. För HANA-systemreplikering (HSR) accepterar den sekundära noden inga anslutningar alls. När säkerhetskopieringen har konfigurerats pingar Azure Backup-tjänsten regelbundet och misslyckas. Ibland reflekterar dessa misslyckade försök på den primära noden. Efter flera fel är användaren låst och sedan börjar den primära noden att misslyckas med ODBC Anslut ionError.
   
   Vi har observerat att alla användare inte upplever det här problemet. Vi rekommenderar att du/SAP undersöker orsaken till att användare blir låsta i den primära noden när användaranslutningen misslyckas på den sekundära noden.

2. När du kör förregistreringsskriptet uppdateras användarinformationen med nytt lösenord på den primära noden. Sedan upprättas anslutningen till säkerhetskopieringen igen. Men du kan återigen uppleva samma scenario.

3. Dessutom skapar de säkerhetskopior (fullständiga säkerhetskopior) som misslyckas på den sekundära noden aviseringar.

För att undvika ovanstående problem rekommenderar vi att du stoppar skyddet för en nod när den blir sekundär (så att anslutningar inte görs och användaren inte är låst) och återupptar skyddet på den när den blir primär. Om du inte står inför den här låsningssituationen i deras HSR-installationer och är bekväm med att aviseringar aktiveras kan du konfigurera säkerhetskopior på båda noderna så att tjänsten hanterar övertagningen och återställning efter fel.

Se prestanda för säkerhetskopiering och återställning av dataflöde som Azure Backup tillhandahåller för HANA-arbetsbelastningar.

Använd följande resurser för att konfigurera HANA-systemet för att få bättre prestanda:

• Välj en disktyp för virtuella Azure IaaS-datorer – hanterade diskar
• Prestandanivåer för Azure-hanterade diskar
• M-serien
• Lagringskonfigurationer för virtuella SAP HANA Azure-datorer

För närvarande accepterar Azure Backup för SAP HANA 1 som värdet för egenskapen parallel_backup_using_backint . Azure Backup delar dock upp den enskilda strömmen i flera strömmar för bättre prestanda.

För närvarande stöds endast Backint-baserade säkerhetskopior för HSR. Ögonblicksbilder är inte ännu.

Du måste köra omidentifieringen av instansen på den server som har markerats som "Inte redo" för att uppdatera dess status.

Du kan utföra högst 10 återställningar per HANA-system eller instans på en dag. Observera att om en återställning avbryts eller misslyckas betraktas den också som ett återställningsförsök.

Kontrollera om alla förutsättningar för återställningen till SAP HANA-målinstansen är uppfyllda. Mer information finns i Krav – Återställa SAP HANA-databaser på en virtuell Azure-dator.

Kontrollera att alternativet Tvinga överskrivning är markerat när du återställer.

Se SAP HANA Obs 1642148 för att se vilka återställningstyper som stöds för närvarande.

Ja, du kan använda strömmande säkerhetskopior som utlöses på en HANA-databas som körs på SLES för att återställa den till ett RHEL HANA-system och vice versa. Det vill: återställning mellan operativsystem är möjligt med hjälp av säkerhetskopiering av direktuppspelning. Du måste dock se till att det HANA-system som du vill återställa till, och HANA-systemet som används för återställning, båda är kompatibla för återställning enligt SAP. Se SAP HANA Obs 1642148 för att se vilka återställningstyper som är kompatibla.

Ja, du kan ladda ned filer delvis enligt beskrivningen här.

Ja, du måste inaktivera HANA System Replication (HSR) på målsystemet och sedan utföra återställningen. Du kan inte återställa ett HSR-aktiverat system enligt SAP.

Innan du skapar en princip bör du vara tydlig med kraven för RPO och RTO och dess relevanta kostnadskonsekvenser.

RPO (Recovery-point-objective) anger hur mycket dataförlust som är acceptabel för användaren/kunden. Detta bestäms av loggsäkerhetskopieringsfrekvensen. Vanligare loggsäkerhetskopior anger lägre RPO och det minsta värde som stöds av Azure Backup-tjänsten är 15 minuter. Så loggsäkerhetskopieringsfrekvensen kan vara 15 minuter eller högre.

RTO (Recovery-time-objective) anger hur snabbt data ska återställas till den senaste tillgängliga tidpunkten efter ett dataförlustscenario. Detta beror på den återställningsstrategi som används av HANA, som vanligtvis är beroende av hur många filer som krävs för återställning. Detta har även kostnadskonsekvenser, och följande tabell bör hjälpa dig att förstå alla scenarier och deras konsekvenser.

Därför kan du välja principvarianten baserat på RPO- och RTO-mål och kostnadsöverväganden.

Några principer bör hållas i åtanke när du fastställer effekten av att växla ett säkerhetskopieringsobjekts princip från Princip 1 (P1) till Princip 2 (P2) eller redigering av princip 1 (P1).

• Alla ändringar tillämpas också retroaktivt. Den senaste säkerhetskopieringsprincipen tillämpas även på återställningspunkter som togs tidigare. Anta till exempel att den dagliga fullständiga kvarhållningen är 30 dagar och att 10 återställningspunkter har tagits enligt den aktuella aktiva principen. Om den dagliga fullständiga kvarhållningen ändras till 10 dagar beräknas även den föregående punktens förfallotid om som starttid + 10 dagar och tas bort om de har upphört att gälla.
• Omfånget för ändringen omfattar även dag för säkerhetskopiering, typ av säkerhetskopiering tillsammans med kvarhållning. Till exempel: Om en princip ändras från dagligen full till hel varje vecka på söndagar markeras alla tidigare fyllningar som inte är på söndagar för borttagning.
• En överordnad tas inte bort förrän det underordnade objektet är aktivt/inte har upphört att gälla. Varje typ av säkerhetskopiering har en förfallotid enligt den aktuella aktiva principen. Men en fullständig säkerhetskopieringstyp betraktas som överordnad till efterföljande "differentiella värden", "inkrementella" och "loggar". En "differentiell" och en "logg" är inte föräldrar till någon annan. En "inkrementell" kan vara en överordnad till efterföljande "inkrementell". Även om en överordnad har markerats för borttagning tas den inte bort om de underordnade "differentiella" eller "loggarna" inte har upphört att gälla. Om en princip till exempel ändras från dagligen full till hel varje vecka på söndagar markeras alla tidigare fyllningar som inte är på söndagar för borttagning. Men de tas inte bort förrän loggarna som togs dagligen tidigare har upphört att gälla. Med andra ord behålls de enligt den senaste loggvaraktigheten. När loggarna upphör att gälla tas både loggarna och dessa fulls bort.

Med dessa principer kan du läsa följande tabell för att förstå konsekvenserna av en principändring.

Du kan hantera utrymmet i rotmappen med något av följande alternativ:

• Skapa en egen LV för /opt/msawb.
• Skapa en mjuk länk-symlink/ till en annan plats/mapp på samma/olika disk.
• Öka utrymmet på rotpartitionen.

Nästa steg

• Lär dig hur du säkerhetskopierar SAP HANA-databaser som körs på virtuella Azure-datorer.
• Lär dig hur du felsöker säkerhetskopior av SAP HANA-databaser.