Veelgestelde vragen: back-ups maken van SAP HANA-databases op Azure-VM's

U kunt één volledige back-up en meerdere on-demand back-ups per dag plannen.

Op dit moment genereren geslaagde back-uptaken geen waarschuwingen. Waarschuwingen worden alleen gegenereerd voor back-uptaken die mislukken. Meer informatie over het gebruik van Azure Portal om back-upwaarschuwingen weer te geven.

U kunt de status van uw back-ups controleren (gepland/op aanvraag) vanaf een van de volgende locaties:

1. Back-uptaken: Azure Backup toont alle handmatig geactiveerde taken in de sectie Back-uptaken in Azure Portal.
   
   De taken die u in Azure Portal ziet, omvatten databasedetectie en registratiebewerkingen, en back-up- en herstelbewerkingen. Geplande taken, waaronder logboekback-ups, worden niet weergegeven in deze sectie. Handmatig geactiveerde back-ups van de systeemeigen SAP HANA-clients (Studio/Cockpit/DBA Cockpit), worden hier ook niet weergegeven.

   

   

2. Back-upwaarschuwingen: waarschuwingen helpen u bij het bewaken van back-ups van SAP HANA-databases. Deze helpen u om u te concentreren op de vereiste gebeurtenissen, waardoor de moeite wordt geëlimineerd om regelmatig een groot aantal gebeurtenissen te controleren die door een back-up worden gegenereerd. Zie Back-upwaarschuwingen weergeven voor meer informatie.

3. Back-uprapporten: Rapporten zijn een andere manier om de status van uw back-uptaken weer te geven. Uw rapporten zijn als volgt:

   

   

   Meer informatie over het configureren van Azure Backup-rapporten.

4. SAP HANA Native-clients: als u een SAP HANA-klant bent, kunt u ook HANA Studio gebruiken, een van de meest voorkomende HANA-clients. Navigeer in deze client naar de back-upconsole -> Back-upcatalogus om de back-upstatus te zien.

   

In het menu Back-uptaak worden alleen back-uptaken op aanvraag weergegeven die worden uitgevoerd, zijn geslaagd of mislukt. Gebruik Azure Monitor voor geplande taken.

Azure Backup stelt geen expliciete bewaarperiode in voor de automatische herstel van volledige back-ups. Deze back-up wordt bewaard totdat u de afhankelijke Delta (differentiële of incrementele) en logboekback-ups behoudt. Wanneer u de laatste afhankelijke back-up van deze automatische herstelback-up verwijdert, wordt de back-up automatisch herstellen ook verwijderd.

Ja, een volledige back-up en een logboekback-up kunnen tegelijkertijd worden uitgevoerd. Dit exemplaar vindt plaats op een van de volgende manieren:

• Er wordt een volledige back-up uitgevoerd en er wordt een logboekback-up geactiveerd: de logboekback-up moet slagen, ongeacht een doorlopende volledige back-up. Tenzij de volledige back-up die wordt geactiveerd, een herstelbewerking vol was om alle LSN-ketenonderbrekingen af te handelen.
• Logboekback-up wordt uitgevoerd en er wordt een volledige back-up geactiveerd: beide back-ups moeten tegelijkertijd worden uitgevoerd en lukken.

Nee, dit wordt momenteel niet ondersteund.

Als een database wordt verwijderd uit een SAP HANA-exemplaar, worden de back-ups van de database nog steeds geprobeerd. Dit betekent dat de verwijderde database wordt weergegeven als beschadigd onder Back-upitems en nog steeds is beveiligd. De juiste manier om de beveiliging van deze database te stoppen, is door back-up stoppen met het verwijderen van gegevens in deze database uit te voeren.

Een hernoemde database wordt behandeld als een nieuwe database. Daarom behandelt de service deze situatie alsof de database niet is gevonden en mislukt de back-ups. De naam van de database wordt weergegeven als een nieuwe database en moet worden geconfigureerd voor beveiliging.

Raadpleeg de zelfstudie voor een stapsgewijze handleiding om aan de slag te gaan met Azure Backup voor SAP HANA-databases. U kunt cli ook gebruiken om back-ups te configureren en te beheren.

Raadpleeg de vereisten voor het gebruik van Azure Backup met SAP HANA.

Raadpleeg deze sectie van de gids voor probleemoplossing.

Raadpleeg deze sectie in de gids voor probleemoplossing.

Momenteel hebben we niet de mogelijkheid om de oplossing in te stellen op basis van een virtueel IP-adres of proxy. We hebben een virtuele machine nodig om de oplossing uit te voeren.

U kunt een back-up op aanvraag activeren met behulp van systeemeigen SAP HANA-clients naar het lokale bestandssysteem in plaats van Backint. Meer informatie over het beheren van bewerkingen met behulp van systeemeigen SAP-clients.

U kunt de HANA-catalogus verwijderen met behulp van AANBEVOLEN SAP-methoden, zoals BACKUP CATALOG DELETE-instructies of HANA Studio/Cockpit. Meer informatie over het beheren van bewerkingen met behulp van systeemeigen SAP-clients.

Momenteel beschikt Azure Backup niet over de mogelijkheid om inzicht te krijgen in een HSR-configuratie. Dit betekent dat de primaire en secundaire knooppunten van de HSR worden behandeld als twee afzonderlijke, niet-gerelateerde VM's. U moet eerst een back-up configureren op het primaire knooppunt. Wanneer een failover plaatsvindt, moet de back-up worden geconfigureerd op het secundaire knooppunt (dat nu het primaire knooppunt wordt). Er is geen automatische failover van back-up naar het andere knooppunt.

Als u op een bepaald moment een back-up wilt maken van gegevens van het actieve (primaire) knooppunt, kunt u de beveiliging overschakelen naar het secundaire knooppunt dat nu de primaire knooppunt is geworden na een failover.

Voer de volgende stappen uit om deze schakelbeveiliging uit te voeren:

• Beveiliging stoppen (met behoud van gegevens) op primaire
• Het script vóór registratie uitvoeren op het secundaire knooppunt
• De databases op het secundaire knooppunt detecteren en back-ups erop configureren

Deze stappen moeten na elke failover handmatig worden uitgevoerd. U kunt deze stappen uitvoeren via de opdrachtregel/HTTP REST naast Azure Portal. Als u deze stappen wilt automatiseren, kunt u een Azure-runbook gebruiken.

Hier volgt een gedetailleerd voorbeeld van hoe switchbeveiliging moet worden uitgevoerd:

In dit voorbeeld hebt u twee knooppunten: knooppunt 1 (primair) en knooppunt 2 (secundair) in de HSR-configuratie. Back-ups worden geconfigureerd op Node 1. Zoals hierboven vermeld, probeert u nog geen back-ups te configureren op Node 2.

Wanneer de eerste failover plaatsvindt, wordt Node 2 de primaire. Vervolgens

1. Stop de beveiliging van Node 1 (vorige primaire versie) met de optie Gegevens behouden.
2. Voer het script vóór registratie uit op Node 2 (dit is nu de primaire).
3. Detecteer databases op Node 2, wijs back-upbeleid toe en configureer back-ups.

Vervolgens wordt een eerste volledige back-up geactiveerd op Node 2 en daarna worden logboekback-ups gestart.

Wanneer de volgende failover plaatsvindt, wordt Node 1 opnieuw primair en wordt Node 2 secundair. Herhaal nu het proces:

1. Stop de beveiliging van Node 2 met de optie Gegevens behouden.
2. Voer het script vóór registratie uit op Node 1 (dat opnieuw de primaire is geworden)
3. Vervolgens hervat u de back-up op knooppunt 1 met het vereiste beleid (omdat de back-ups eerder op Node 1 zijn gestopt).

Vervolgens wordt de volledige back-up opnieuw geactiveerd op Node 1 en daarna worden logboekback-ups gestart.

1. Voor HANA-systeemreplicatie (HSR) accepteert het secundaire knooppunt helemaal geen verbindingen. Zodra de back-up is geconfigureerd, pingt de Azure Backup-service periodiek en mislukt deze. Soms weerspiegelen deze mislukte pogingen op het primaire knooppunt. Na meerdere fouten is de gebruiker vergrendeld en mislukt het primaire knooppunt met ODBC Verbinding maken ionError.
   
   We hebben vastgesteld dat alle gebruikers dit probleem niet ervaren. We raden u/SAP aan om de oorzaak te onderzoeken van gebruikers die zijn vergrendeld in het primaire knooppunt wanneer de gebruikersverbinding op het secundaire knooppunt mislukt.

2. Nadat u het script vóór registratie hebt uitgevoerd, worden de gebruikersgegevens bijgewerkt met een nieuw wachtwoord op het primaire knooppunt. Vervolgens wordt de verbinding om een back-up te maken opnieuw tot stand gebracht. Maar mogelijk ervaart u hetzelfde scenario opnieuw.

3. Bovendien maken de back-ups (volledige back-ups) die mislukken op het secundaire knooppunt waarschuwingen.

Om de bovenstaande problemen te voorkomen, raden we u aan de beveiliging voor een knooppunt te stoppen nadat het secundair is (zodat verbindingen niet worden geprobeerd en de gebruiker niet is vergrendeld) en de beveiliging ervan hervat zodra het primaire wordt. Als u deze vergrendelingssituatie niet ondervindt in hun HSR-instellingen en u vertrouwd bent met waarschuwingen die worden gegenereerd, kunt u back-ups op beide knooppunten configureren, zodat de service de overname en failback afhandelt.

Raadpleeg de prestaties van de back-up- en hersteldoorvoer die Azure Backup biedt voor HANA-workloads.

Als u uw HANA-systeem wilt instellen om gebruik te maken van de verbeterde prestaties, gebruikt u de volgende resources:

• Een schijftype selecteren voor Virtuele Azure IaaS-machines - beheerde schijven
• Prestatielagen voor beheerde Azure-schijven
• M-serie
• Opslagconfiguraties voor virtuele AZURE-machines in SAP HANA

Momenteel accepteert Azure Backup voor SAP HANA 1 als de waarde van de eigenschap parallel_backup_using_backint . Azure Backup splitst echter die ene stream in meerdere streams voor betere prestaties.

Op dit moment worden alleen back-ups op basis van Backint ondersteund voor HSR. Momentopnamen zijn nog niet.

U moet de herdetectie van het exemplaar uitvoeren op de server die is gemarkeerd als 'Niet gereed' om de status bij te werken.

U kunt maximaal 10 herstelbewerkingen per HANA-systeem of exemplaar per dag uitvoeren. Als een herstelbewerking is geannuleerd of mislukt, wordt dit ook beschouwd als een herstelpoging.

Controleer of aan alle vereisten voor het herstellen naar het SAP HANA-exemplaar is voldaan. Zie Vereisten : SAP HANA-databases herstellen in Azure VM voor meer informatie.

Zorg ervoor dat de optie Geforceerd overschrijven is geselecteerd tijdens het herstellen.

Raadpleeg de SAP HANA-opmerking 1642148 om te zien welke hersteltypen momenteel worden ondersteund.

Ja, u kunt streamingback-ups gebruiken die zijn geactiveerd op een HANA-database die wordt uitgevoerd op SLES om deze te herstellen naar een RHEL HANA-systeem en omgekeerd. Dat wil gezegd, het herstellen van meerdere besturingssystemen is mogelijk met behulp van streamingback-ups. U moet er echter voor zorgen dat het HANA-systeem waarnaar u wilt herstellen en het HANA-systeem dat wordt gebruikt voor herstel, beide compatibel zijn voor herstel volgens SAP. Raadpleeg SAP HANA Note 1642148 om te zien welke hersteltypen compatibel zijn.

Ja, u kunt bestanden gedeeltelijk downloaden zoals hier wordt beschreven.

Ja, u moet de HANA-systeemreplicatie (HSR) op het doelsysteem uitschakelen en vervolgens herstel uitvoeren. U kunt een HSR-systeem niet herstellen volgens SAP.

Voordat u een beleid maakt, moet u duidelijk zijn over de vereisten van RPO en RTO en de relevante gevolgen voor de kosten.

RPO (Recovery-point-objective) geeft aan hoeveel gegevensverlies acceptabel is voor de gebruiker/klant. Dit wordt bepaald door de frequentie van de logboekback-up. Frequentere logboekback-ups geven lagere RPO aan en de minimale waarde die wordt ondersteund door de Azure Backup-service is 15 minuten. De back-upfrequentie van logboeken kan dus 15 minuten of hoger zijn.

RTO (Recovery-time-objective) geeft aan hoe snel de gegevens moeten worden hersteld naar het laatste beschikbare tijdstip na een scenario voor gegevensverlies. Dit is afhankelijk van de herstelstrategie die wordt gebruikt door HANA, wat meestal afhankelijk is van het aantal bestanden dat nodig is voor herstel. Dit heeft ook gevolgen voor de kosten en de volgende tabel moet helpen bij het begrijpen van alle scenario's en de gevolgen ervan.

Daarom kunt u de beleidsvariant selecteren op basis van RPO- en RTO-doelstellingen en kostenoverwegingen.

Houd rekening met enkele principes bij het bepalen van de impact van het overschakelen van het beleid van een back-upitem van Beleid 1 (P1) naar Beleid 2 (P2) of bij het bewerken van Beleid 1 (P1).

• Alle wijzigingen worden ook met terugwerkende kracht toegepast. Het meest recente back-upbeleid wordt ook toegepast op de herstelpunten die eerder zijn gemaakt. Stel dat de dagelijkse volledige retentie 30 dagen is en dat er 10 herstelpunten zijn genomen volgens het huidige actieve beleid. Als de retentie van de dagelijkse volledige gegevens wordt gewijzigd in 10 dagen, wordt de verlooptijd van het vorige punt ook opnieuw berekend als begintijd + 10 dagen en verwijderd als ze verlopen zijn.
• Het wijzigingsbereik omvat ook de dag van de back-up, het type back-up, samen met retentie. Bijvoorbeeld: Als een beleid wordt gewijzigd van dagelijks vol naar wekelijks vol op zondag, worden alle eerdere fulls die niet op zondag zijn gemarkeerd voor verwijdering.
• Een bovenliggend item wordt pas verwijderd als het kind actief/niet verlopen is. Elk back-uptype heeft een verlooptijd volgens het huidige actieve beleid. Maar een volledig back-uptype wordt beschouwd als bovenliggend aan volgende 'differentiëlen', 'incrementele' en 'logboeken'. Een 'differentieel' en een logboek zijn geen ouders van iemand anders. Een 'incrementeel' kan een bovenliggend element zijn naar volgende 'incrementeel'. Zelfs als een bovenliggend item is gemarkeerd voor verwijdering, wordt deze niet daadwerkelijk verwijderd als de onderliggende 'differentiëlen' of 'logboeken' niet zijn verlopen. Als een beleid bijvoorbeeld wordt gewijzigd van dagelijks vol naar wekelijks vol op zondag, worden alle eerdere fulls die niet op zondag zijn gemarkeerd voor verwijdering. Ze worden echter pas verwijderd nadat de logboeken die dagelijks eerder zijn genomen, zijn verlopen. Met andere woorden, ze worden bewaard volgens de laatste duur van het logboek. Zodra de logboeken zijn verlopen, worden zowel de logboeken als deze volledige bestanden verwijderd.

Met deze principes kunt u de volgende tabel lezen om inzicht te krijgen in de gevolgen van een beleidswijziging.

U kunt de ruimte in de hoofdmap beheren met een van de volgende opties:

• Maak een eigen LV voor /opt/msawb.
• Maak een symlink voor een zachte koppeling/naar een andere locatie/map op dezelfde/andere schijf.
• Vergroot de ruimte op de hoofdpartitie.

Volgende stappen

• Meer informatie over het maken van back-ups van SAP HANA-databases die worden uitgevoerd op azure-VM's.
• Meer informatie over het oplossen van problemen met back-ups van SAP HANA-databases.