Vanliga frågor och svar – 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 under 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 Portal 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 Portal.
   
   De jobb som visas i Azure Portal omfattar databasidentifierings- 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 SAP HANA ursprungliga klienterna (Studio/Cockpit/DBA Cockpit) visas inte heller här.

   

   

2. Säkerhetskopieringsaviseringar: Aviseringar hjälper dig att övervaka säkerhetskopieringar SAP HANA databaser. Dessa hjälper dig att fokusera på de händelser som krävs, vilket eliminerar arbetet med att ofta kontrollera en mängd olika händelser som en säkerhetskopia genererar. Mer information finns i Visa säkerhetskopieringsaviseringar.

3. Backup-rapporter: Rapporter är ett annat sätt att visa status för dina säkerhetskopieringsjobb. Dina rapporter blir följande:

   

   

   Lär dig hur du konfigurerar Azure Backup rapporter.

4. SAP HANA interna klienter: Om du är en 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äkerhetskopieringskatalogen -> för säkerhetskopieringskonsolen för att se säkerhetskopieringsstatusen.

   

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

Azure Backup anger inte någon explicit kvarhållningsperiod för att automatiskt återställa fullständiga säkerhetskopior. Den här säkerhetskopian bevaras tills du behåller beroende Delta (differentiella eller inkrementella) och loggsäkerhetskopior. När du tar bort den senaste beroende säkerhetskopian av den här säkerhetskopieringen för automatisk läkening tas även säkerhetskopian bort automatiskt.

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

Om en databas tas bort från en SAP HANA instans görs fortfarande försök att säkerhetskopiera databasen. Detta innebär att den borttagna databasen börjar visas som skadad under Säkerhetskopieringsobjekt och fortfarande är skyddad. Rätt sätt att sluta skydda den här databasen är att stoppa säkerhetskopieringen med borttagning av data på den här databasen.

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

Se självstudien för 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äkerhetskopieringar.

Se kraven 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 proxyserver. Vi behöver en virtuell dator för att köra lösningen.

1. Vänta tills säkerhetskopieringen som körs har slutförts på den önskade databasen (kontrollera att den är klar från Studio).
2. Inaktivera loggsäkerhetskopior och ställ in katalogsäkerhetskopiering på Filsystem för önskad databas med följande steg:
3. Dubbelklicka på SYSTEMDB-konfiguration -> -> Välj -> databasfilter (logg)
   1. Ange enable_auto_log_backup till Nej.
   2. Ange catalog_backup_using_backint till false.
4. Gör en säkerhetskopiering på begäran (fullständig/differentiell/inkrementell) på den önskade databasen och vänta tills säkerhetskopieringen och katalogsäkerhetskopiering har slutförts.
5. Om du även vill flytta loggsäkerhetskopiorna till filsystemet anger du enable_auto_log_backup till ja.
6. Återgå till de tidigare inställningarna för att tillåta att säkerhetskopior flödar till Azure-valvet:
   1. Ange enable_auto_log_backup till ja.
   2. Ange catalog_backup_using_backint till true.

För närvarande Azure Backup har inte möjlighet att förstå en HSR-uppsättning. Det innebär att HSR:s primära och sekundära noder behandlas som två enskilda, orelaterade virtuella datorer. Du måste först konfigurera säkerhetskopiering på den primära noden. När en redundans inträffar måste säkerhetskopieringen konfigureras på den sekundära noden (som nu blir den primära noden). Det finns ingen automatisk redundans för säkerhetskopiering till den andra noden.

Om du vill backa upp data från den aktiva (primära) noden vid en viss tidpunkt kan du växla skydd till den sekundära noden, som nu har blivit den primära efter redundans.

Följ dessa steg om du vill utföra det här växelskyddet:

• Stoppa skyddet (med kvarhållna data) på den primära
• 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 redundans. Du kan utföra dessa steg via kommandoraden/HTTP REST utöver de Azure Portal. Du kan använda en Azure-runbook för att automatisera de här stegen.

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-uppsättningen. Säkerhetskopior konfigureras på nod 1. Som nämnts ovan ska du inte försöka konfigurera säkerhetskopieringar på nod 2 än.

När den första redundansen sker blir nod 2 den primära. Sedan

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 den primära).
3. Identifiera databaser på nod 2, tilldela säkerhetskopieringspolicy och konfigurera säkerhetskopior.

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

När nästa redundans 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 för att behålla 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 nödvändiga principen (eftersom säkerhetskopieringarna 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 inte den sekundära noden några anslutningar alls. När säkerhetskopieringen har konfigurerats pingar Azure Backup tjänsten regelbundet och misslyckas. Ibland återspeglas dessa misslyckade försök på den primära noden. Efter flera fel låses användaren och sedan misslyckas den primära noden med ODBCConnectionError.
   
   Vi har observerat att det här problemet inte uppstår för alla användare. 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 ett nytt lösenord på den primära noden. Anslutningen för att försöka säkerhetskopiera upprättas på nytt. Men du kan återigen uppleva samma scenario.

3. Dessutom skapar de säkerhetskopieringar (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åsläget i HSR-installationerna och är bekväm med att aviseringar utlöses kan du konfigurera säkerhetskopieringar på båda noderna så att tjänsten hanterar över- 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.

Om du vill konfigurera HANA-systemet så att det utnyttjar den förbättrade prestandan använder du följande resurser:

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

Kontrollera att alla krav för återställning till målinstansen SAP HANA är uppfyllda. Mer information finns i Prerequisites - Restore SAP HANA databases in Azure VM.

Se till att alternativet Force Overwrite (Framtrngsskrivning) är markerat under återställningen.

Se följande SAP HANA Observera 1642148 du vill se vilka återställningstyper som stöds för närvarande.

Ja, du kan använda strömmande säkerhetskopieringar 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 innebär att återställning mellan operativsystem är möjligt med hjälp av direktuppspelningssäkerhetskopior. Du måste dock se till att det HANA-system som du vill återställa till och det HANA-system som används för återställning är kompatibla för återställning enligt SAP. Läs mer SAP HANA Observera 1642148 du vill se vilka återställningstyper som är kompatibla.

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

RPO (Återställningspunktmål) anger hur mycket dataförlust som är acceptabel för användaren/kunden. Detta bestäms av frekvensen för loggsäkerhetskopiering. Mer frekventa loggsäkerhetskopior indikerar lägre RPO och det minsta värde som stöds Azure Backup tjänsten är 15 minuter. Därför kan loggsäkerhetskopieringsfrekvensen vara 15 minuter eller högre.

RTO (mål för återställningstid) anger hur snabbt data ska återställas till den senaste tillgängliga tidpunkten efter ett scenario med dataförlust. Detta beror på vilken å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 till att förstå alla scenarier och deras konsekvenser.

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

Några principer bör ha i åtanke när du bestämmer effekten av att växla en princip för säkerhetskopieringsobjekt 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 tagits tidigare. Anta till exempel att den dagliga fullständiga kvarhållningen är 30 dagar och att 10 återställningspunkter har tagits enligt den aktiva principen. Om den dagliga fullständiga kvarhållningen ändras till 10 dagar räknas den föregående punktens förfallotid också om som starttid + 10 dagar och tas bort om de har upphört att gälla.
• Ändringsomfånget omfattar även dag för säkerhetskopiering, typ av säkerhetskopiering och kvarhållning. Exempel: Om en princip ändras från dagliga fullständiga till veckovisa fullständiga på söndagar markeras alla tidigare fulls som inte är på söndag för borttagning.
• En överordnad tas inte bort förrän den underordnade är aktiv/inte har upphört att gälla. Varje säkerhetskopieringstyp har en förfallotid enligt den aktiva principen. Men en fullständig säkerhetskopieringstyp betraktas som överordnad till efterföljande differentiella, inkrementella och loggar. En "differentiell" och en "logg" är inte föräldrar till någon annan. En "inkrementell" kan vara överordnad till efterföljande "inkrementell". Även om ett "överordnat" har markerats för borttagning tas det inte bort om de underordnade "differentiella" eller "loggarna" inte har upphört att gälla. Om en princip till exempel ändras från dagliga fullständiga till veckovisa fullständiga på söndagar markeras alla tidigare fulls som inte är på söndag 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 fullar bort.

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

Nästa steg

Lär dig hur du SAP HANA databaser som körs på virtuella Azure-datorer.