Veelgestelde vragen: een back-up maken SAP HANA databases op azure-VM's

U kunt één volledige back-up en meerdere back-ups op aanvraag 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 de Azure Portal back-upwaarschuwingen weer te geven.

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

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

   

   

2. Back-upwaarschuwingen: met waarschuwingen kunt u back-ups van SAP HANA databases controleren. Deze helpen u zich te richten op de vereiste gebeurtenissen, waardoor het niet meer nodig is om vaak 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 Back-upcatalogus van de back-upconsole -> om de back-upstatus te zien.

   

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

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

Nee, dit wordt momenteel niet ondersteund.

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

Een naam van een 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 stapsgewijs 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.

Op dit moment is het niet mogelijk om de oplossing in te stellen voor een virtueel IP-adres of proxy. We hebben een virtuele machine nodig om de oplossing uit te voeren.

1. Wacht tot de back-up die momenteel wordt uitgevoerd, is voltooid op de gewenste database (controleer in Studio of de back-up is voltooid).
2. Schakel logboekback-ups uit en stel de catalogusback-up in op Bestandssysteem voor de gewenste database met behulp van de volgende stappen:
3. Dubbelklik op SYSTEMDB-configuratie -> -> Databasefilter -> (logboek) selecteren
   1. Stel enable_auto_log_backup in op nee.
   2. Stel catalog_backup_using_backint in op onwaar.
4. Maak een back-up op aanvraag (volledig/differentieel/incrementeel) op de gewenste database en wacht tot de back-up en catalogusback-up zijn voltooid.
5. Als u de logboekback-ups ook naar het bestandssysteem wilt verplaatsen, stelt u enable_auto_log_backup in op ja.
6. Keer terug naar de vorige instellingen om toe te staan dat back-ups naar de Azure-kluis stromen:
   1. Stel enable_auto_log_backup in op Ja.
   2. Stel catalog_backup_using_backint in op true.

Op dit Azure Backup niet de mogelijkheid om een HSR-set-up te begrijpen. Dit betekent dat de primaire en secundaire knooppunten van de HSR worden behandeld als twee afzonderlijke, niet-gerelateerde VM's. U moet eerst back-ups configureren op het primaire knooppunt. Wanneer er een failback wordt gemaakt, moet de back-up worden geconfigureerd op het secundaire knooppunt (dat nu het primaire knooppunt wordt). Er is geen automatische fail-over 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 is geworden na een fail-over.

Volg deze stappen om deze switchbeveiliging uit te voeren:

• Stop de beveiliging (met behoud van gegevens) op de primaire
• Het script vóór registratie uitvoeren op het secundaire knooppunt
• De databases op het secundaire knooppunt ontdekken en back-ups ervan configureren

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

Hier is 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-set-up. Back-ups worden geconfigureerd op Knooppunt 1. Zoals hierboven vermeld, moet u nog geen back-ups configureren op Knooppunt 2.

Wanneer de eerste failover wordt voortgezet, wordt Knooppunt 2 de primaire. Dan

1. Stop de beveiliging van Knooppunt 1 (vorige primaire versie) met de optie gegevens behouden.
2. Voer het script vóór registratie uit op Knooppunt 2 (dit is nu het primaire script).
3. Databases op Knooppunt 2 ontdekken, back-upbeleid toewijzen en back-ups configureren.

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

Wanneer de volgende fail over het hoofd wordt, wordt Knooppunt 1 opnieuw primair en knooppunt 2 secundair. Herhaal nu het proces:

1. Stop de beveiliging van Knooppunt 2 met de optie gegevens behouden.
2. Voer het script vóór registratie uit op knooppunt 1 (dit is opnieuw het primaire script geworden)
3. Hervat vervolgens de back-up op knooppunt 1 met het vereiste beleid (omdat de back-ups eerder op knooppunt 1 zijn gestopt).

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

1. Voor HANA-systeemreplicatie (HSR) accepteert het secundaire knooppunt helemaal geen verbindingen. Zodra de back-up is geconfigureerd, Azure Backup de back-upservice periodiek pingen en mislukt deze. Soms worden deze mislukte pogingen weergegeven op het primaire knooppunt. Na meerdere fouten wordt de gebruiker vergrendeld en begint het primaire knooppunt te mislukken met ODBCConnectionError.
   
   We hebben vastgesteld dat dit probleem niet voor alle gebruikers wordt ervaren. We raden u/SAP aan om de oorzaak te onderzoeken van gebruikers die in het primaire knooppunt worden vergrendeld wanneer de gebruikersverbinding op het secundaire knooppunt mislukt.

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

3. Ook worden waarschuwingen gemaakt voor de back-ups (volledige back-ups) die mislukken op het secundaire knooppunt.

Om de bovenstaande problemen te voorkomen, raden we u aan om de beveiliging voor een knooppunt te stoppen nadat het secundair is (zodat er geen verbindingen worden geprobeerd en de gebruiker niet is vergrendeld) en de beveiliging ervan te hervatten zodra het primair wordt. Als u niet met deze vergrendelingssituatie te maken hebt bij de HSR-instellingen en vertrouwd bent met waarschuwingen die worden getrokken, kunt u back-ups configureren op beide knooppunten, zodat de service de over- en failback af handelen.

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

Gebruik de volgende resources om uw HANA-systeem in te stellen om gebruik te maken van de verbeterde prestaties:

• Een schijftype selecteren voor Azure IaaS-VM's - beheerde schijven
• Prestatielagen voor beheerde Azure-schijven
• M-serie
• Configuraties van SAP HANA in virtuele Azure-machineopslag

Controleer of aan alle vereisten voor het herstellen naar het doel-SAP HANA is voldaan. Zie Prerequisites - Restore SAP HANA databases in Azure VM (Vereisten - SAP HANA herstellen in Azure VM) voor meer informatie.

Zorg ervoor dat de optie Overschrijven forceer 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 worden geactiveerd op een HANA-database die wordt uitgevoerd op SLES om deze te herstellen naar een RHEL HANA-systeem en vice versa. Dat wil zeggen dat herstellen van verschillende besturingssystemen mogelijk is met behulp van streamingback-ups. U moet er echter voor zorgen dat het HANA-systeem dat u wilt herstellen en het HANA-systeem dat wordt gebruikt voor herstel, compatibel zijn voor herstel volgens SAP. Raadpleeg SAP HANA Opmerking 1642148 om te zien welke hersteltypen compatibel zijn.

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 back-upfrequentie van het logboek. Frequentere logboekback-ups geven een lagere RPO aan en de minimumwaarde die door de Azure Backup service wordt ondersteund, is 15 minuten. 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 laatst beschikbare tijdstip na een scenario voor gegevensverlies. Dit is afhankelijk van de herstelstrategie die door HANA wordt gebruikt. Dit is meestal afhankelijk van het aantal bestanden dat nodig is voor herstel. Dit heeft ook gevolgen voor de kosten en de volgende tabel kan helpen bij het begrijpen van alle scenario's en de implicaties ervan.

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

Er moeten enkele principes in gedachten worden gehouden 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 van het bewerken van Beleid 1 (P1).

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

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

Volgende stappen

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