Teilen Sie diesen Inhalt:

       

Spectrum Protect (TSM) und HANA

09.06.2017

Für HANA sollte die primäre Sicherungsmethode auf Storage Snapshots basieren. In HANA sind Storage Snapshots sehr gut integriert und bieten viele Vorteile gegenüber einer traditionellen Sicherung über die ‚Streaming‘ Backint Schnittstelle und Spectrum Protect.

Brauch man dann überhaupt noch Spectrum Protect (oder andere Backint basierende Sicherungen)?

Ja.

Kann man auch ohne Spectrum Protect (oder andere Backint basierende Sicherungen) HANA betreiben?

Ja.

Der Widerspruch lässt sich einfach aufklären:

HANA schreibt wie jede andere Datenbank Transaktionslogs, die, wenn sie abgeschlossen sind gesichert werden müssen um eine PiT Wiederherstellung möglich zu machen.

Man kann das jetzt wie in den frühen 90‘er Jahren, also zu der Zeit als die Datenbanken noch keine Schnittstellen zu den Backupsystemen zur Verfügung stellten, konfigurieren. Also die abgeschlossenen Transaktionen in ein Filesystem sichern und zu einem späteren Zeitpunkt weiterleiten und löschen. Dann brauch man kein Spectrum Protect. Aber aus vielfältigen Gründen ist besser, die Logs direkt zum Spectrum Protect Server zu schicken.

Der zweite Punkt ist, dass HANA als reine In-Memory Datenbank Fehler auf den Plattensystemen nicht unbedingt bemerkt. Es kann also passieren, und es ist auch passiert, dass HANA ohne erkennbare Probleme funktioniert, aber die Filesysteme bzw. Daten auf der Festplatte korrupt sind. Das böse Erwachen kommt dann, wenn man die HANA DB neu starten muss. Aus diesem Grund halte ich es sogar für fahrlässig HANA alleine, ohne weitere Maßnahmen, über eine Storage Snapshot Sicherung abzusichern. In dem bekannten Fall hat genau die abbrechende Backint Sicherung auf das Problem aufmerksam gemacht.

Als ‚Best Practise‘ sehe ich für P- Systeme im Moment einen Mischbetrieb, z.B. 1 bis 2 mal täglich eine Snapshot Sicherung und wöchentlich eine Backint Sicherung, die die gesamte Datenbank durchliest, durchzuführen. Die Logs sollten dann auch mindestens 2-3 Wochen vorgehalten werden. Im Notfall und auch bei Problemen mit der Snapshot Sicherung ist es dann möglich, über Spectrum Protect die Datenbank wieder herzustellen. Für Q- und E-Systeme kann eine reine Snapshot Sicherung aber ausreichen.

Für die Sicherung über Storage Snapshots ist noch anzumerken, dass SAP eine ‚Storage Tool‘ für die eigentliche Ansteuerung der Snapshot voraussetzt. Ich habe für den Zweck ein ‚Storage Tool‘ geschrieben, dass Backups in den HANA Backup Katalog einträgt und leicht z.B. über den Spectrum Protect Scheduler automatisiert und überwacht werden kann. Genannt hab ich das ‚Storage Tool‘ cSNAP.

Usage: cSNAP SID FUNCTION

Functions:
 START                - start automatic backup
 BACKUP               - start manual backup
 RESTORE VERSION|MC   - restore snapshot
 DELETE VERSION|MC    - delete version or manual backup
 CHECK                - check configuration
 LIST                 - list snapshot status
 CATALOG [WITHLOGS]   - list hana backup catalog
 DELENTRY ID          - delete hana backup catalog entry
 DELOLDER ID          - delete hana backup catalog entries older ID
 CLOSEENTRY ID        - close hana backup catalog entry
 CMDS [DO]            - initial and version increment commands

Derzeit ist cSNAP rein auf IBM Speicher Hardware abgestimmt. Da in dem Tool doch recht viel Entwicklungs- und vor allen Dingen Testzeiten eingeflossen sind, darf und möchte ich cSNAP nicht kostenfrei rausgeben. Falls jemand daran Interesse hat, bitte mich direkt thomas.hellnick@carus.consulting oder über die Kommentarfunktion kontaktieren.

Der Beitrag Spectrum Protect (TSM) und HANA erschien zuerst auf Spectrum Protect (TSM) Blog.



Teilen Sie diesen Inhalt: