SAPHanaSR_with_DR_HA(7)

📦 version 1.3.4, in opensuse-leap 16.0

✨ NAME ✨

SAPHanaSR_with_DR_HA — SAPHanaSR with HA cluster at DR region.

(and yes bestie, this is a page from the SAPHanaSR-angi manual, section 7 💅)

🌸 DESCRIPTION 🌸

💖 Overview 💖

Okay so picture this: you've got two HANA system replication pairs, and they're connected by a third HANA system replication. Each pair is set up as a Linux cluster for the scale-up performance-optimised scenario. The first pair is doing its regular thing as the production region (site1, site2). The second pair is out here living its best life in DR mode (site3, site4).

The first site of the DR region (site3) is registered to the primary of the production region (site1). The replication to the DR region is async — no cap. The second site of the DR region (site4) is registered to the first site of the DR region (site3), and that replication is sync or syncmem 🦋

You can write the whole described topology like this:

 [ site2 <= site1' ] -> { site3 => site4 }

If you're like "what is this notation even," go read SAPHanaSR-angi-scenarios(7) — it explains it, iykyk ✨

Big important thing, bestie: the Linux clusters have no control over HANA system replication between the production region and the DR region. The takeover from production region to the DR region has to be decided and performed manually. Please also see the REQUIREMENTS section below 🙈

Also FYI: the SAPHanaSR with HA cluster at DR region scenario is a technology preview — so treat it like a main character who's still in beta 💀

🔥 DR mode 🔥

The DR region is almost a Linux cluster for the scale-up performance-optimised scenario. But plot twist — there is no HANA primary site. Instead of the primary, the DR site (site3) that is registered to the production primary acts as replication source for the DR secondary (site4).

Since there's no primary site, the SAPHanaController RA needs to run in DR mode. How do you do that? You set "PREFER_SITE_TAKEOVER=DR" 🎀 In DR mode, the cluster will start, stop and monitor the SAPHanaController multi-state resource. But the cluster will not do a takeover from one DR node to the other. However — and this is the slay part — by monitoring resources and initiating local restart, the Linux cluster is able to recover from certain failures by restoring the former state. Please refer to ocf_suse_SAPHanaController(7) for the details, bestie 🫶

In DR mode, some cluster attributes are looking different from the regular mode:

  • lpt — shows 30 for both sites, if all is fine.
  • srHook — shows SWAIT for the DR site attached to production by async replication. It shows SOK for the second DR site, if all is fine. The second DR site shows SFAIL, if the first DR site looses the link to production primary. The second DR site recovers to SOK, if first DR site gets back the link to production primary. PRIM is shown for the production primary. Two PRIM sites are indicating a takeover at production 👀
  • srMode — shows async for the replication from production.
  • srPoll — shows DR for both DR sites.
  • srr — shows S for both sites, if all is fine.
  • clone_state — shows DEMOTED for both sites, if all is fine.
  • score — shows a negative value.

See also SAPHanaSR-showAttr(8) for the receipts 💅

Optionally, the same production IP address can be used in both regions. It will be set only on sites of the production region. As long as a cluster is running in DR mode, it will not set the IP address. Of course, the infrastructure needs to allow moving IP address between regions — no cap, that part's on you 🌈

Last but not least, the Linux cluster in DR mode allows manual procedures for DR takeover in case of disaster at production region and regular switch of roles between regions ✨

🧚 Setup procedures 🧚

The two clusters could be set up and connected by different procedures:

  1. Set up HANA and Linux clusters in both regions separately. Test both regions in production mode before connecting them. Test takeover, register and DR mode once both regions are connected. This procedure is outlined as an example in SAPHanaSR_with_DR_HA_setup(7). This is the recommended setup procedure 👑 periodt.
  2. Set up HANA and Linux clusters in production region. Connect HANA DR site (or region) without Linux cluster there. Test production region. Install cluster at DR region in DR mode. Test takeover. Test register and DR mode. This procedure is possible, but not recommended 🙈 See SAPHanaSR(7), SAPHanaController-scale-up(7), susHanaSR.py(7), SAPHanaSR_basic_cluster(7), SAPHanaSR_multi-target(7), et al.

🎀 Maintenance procedures 🎀

Common maintenance procedures specific for the two connected HANA system replication pairs are outlined here. Maintenance activities at both regions need to be aligned — like, coordinate, bestie, don't do your own thing 😭

General maintenance procedures for the production region can be found in SAPHanaSR_maintenance_examples(7).

1️⃣ Procedure to take-over HANA to DR region in case of disaster.

  • Collect information and prepare parameter sheet.
  • Ensure both sites of the production region (site1, site2) are not running.
  • Decide to takeover HANA primary to third site (site3).
  • Perform HANA takeover at third site (site3).
  • Change SAPHanaController to "PREFER_SITE_TAKEOVER=yes".
  • Refresh SAPHanaController multi-state resource.
  • Get SAPHanaController multi-state resource out of maintenance.
  • Check that everything looks fine.

This procedure is explained in detail in the EXAMPLES section below 💖

2️⃣ Procedure to register former production HANA as new DR.

  • Collect information and prepare parameter sheet.
  • Start Linux cluster on first DR site only (node1).
  • Set SAPHanaController multi-state resource into maintenance.
  • Change SAPHanaController to "PREFER_SITE_TAKEOVER=DR".
  • Start Linux cluster on second DR site (node2).
  • Register first DR site (node1) as secondary to current primary (node3)
  • Start HANA at first DR site (node1).
  • Enable system replication at first DR site (node1).
  • Register second DR site (node2) as secondary to first DR site (node1).
  • Refresh SAPHanaController multi-state resource.
  • Get SAPHanaController multi-state resource out of maintenance.
  • Change srHook attribute of first DR site (node1) to SWAIT.
  • Check that everything looks fine.

This procedure is explained in detail in the EXAMPLES section below ✨

3️⃣ Procedure to switch HANA production and DR region, keep HANA running.

Phase 1: Production is still up.

  • Collect information and prepare parameter sheet (1.1).
  • Set multi-state resource to maintenance in both regions (2.1, 3.1).
  • Stop secondary in production (HA) region (2.4).

Phase 2: Production is down.

  • Manually takeover to current DR region (3rd site) with suspend primary (3.2).
  • Mark new DR as DR region and refresh multi-state resource (IP address goes down) (2.2, 2.3).
  • Mark new production (HA) as HA region and refresh multi-state resource (IP address goes up) (3.3, 3.4).

Phase 3: Production is up again.

  • Register former production (HA) primary as DR secondary (async, 3rd site) (4.1).
  • Register former production (HA) secondary as secondary (sync/syncmem, 4th site) (4.3.).
  • Refresh multi-state resource in both regions (3.4, 4.5).
  • End maintenance in both regions (3.5, 4.6).

Phase 4: Production is up, regions HA- and DR-function available again.

  • Check that everything looks fine (3.6, 4.7).

A procedure with optimised workflow is explained in detail in the EXAMPLES section below 🔥

4️⃣ Procedure to switch first and second HANA site at DR region.

  • Collect information and prepare parameter sheet.
  • Set SAPHanaController multi-state resource into maintenance at DR sites (site3, site4).
  • Un-register second DR site (site4) from first (site3).
  • Un-register first DR site (site3) from production primary (site1 or site2).
  • Register new first DR site (site4) async to production primary (site1 or site2).
  • Back-up first DR site (site4) HANA, if needed.
  • Enable system replication at first DR site (site4).
  • Register new second DR site (site3) sync/syncmem to first DR site (site4).
  • Change srHook attribute of first DR site (site4) to SWAIT.
  • Refresh SAPHanaController multi-state resource at DR sites (site3, site4).
  • Get SAPHanaController multi-state resource out of maintenance at DR sites (site3, site4).
  • Remove orphaned srHook attribute of former first DR site (site3) from CIB at production region (site1 or site2) (optional).
  • Check that everything looks fine.

The steps are explained in detail in the EXAMPLES section below and in SAPHanaSR_multi-target(7) 🌸

💅 EXAMPLES 💅

The examples are outlining highlevel procedures as well as describing basic tasks. Detailled runbooks can be created by using the appropriate tasks for adding details to the procedures. More examples, not specific to HA cluster at DR region, can be found in SAPHanaSR_maintenance_examples(7) 🦋

🌟 Procedure to take-over HANA to DR region in case of disaster. 🌟

This might be done if both sites of the production region went down and are not expected to recover in time. It will re-establish the production service 👑

Cluster is up and running in DR mode on DR region nodes, HANA is up and running in DR mode there as well. SAPHanaController parameter "PREFER_SITE_TAKEOVER=DR" is set. Example for scale-up. Make sure to check for sane and idle status of Linux cluster and HANA before and after each step ✨ Details on how to perform the steps can be found in additional examples below and in SAPHanaSR_maintenance_examples(7). See also SAP note 2517805. SID is HA1, instance number is 00.

 site1, node1: former production primary, currently down
 site2, node2: former production secondary, currently down
 site3, node3: current first DR replication target, to become
 production primary
 site4, node4: current second DR replication target, to become
 production secondary
Note: Understand the impact before trying. 🫶 (fr fr, read it twice)

1. Collect information and prepare parameter sheet.

2. Ensure both sites of the production region (site1, site2) are not running.

3. Decide to takeover HANA primary to third site (site3).

4. Set SAPHanaController multi-state resource into maintenance.

node3 # crm resource maintenance mst_SAPHanaCon_HA1_HDB00
⚠️ The next steps will invalidate all HANA data at former production sites (site1, site2). Like, gone gone. 💀

5. Perform HANA takeover at third site (site3).

node3 # su - ha1adm -c "hdbnsutil -sr_takeover"
node3 # su - ha1adm -c "cdpy; python systemReplicationStatus.py; echo rc:\$?"

6. Change SAPHanaController to "PREFER_SITE_TAKEOVER=yes".

node3 # crm configure set rsc_SAPHanaCon_HA1_HDB00.PREFER_SITE_TAKEOVER yes
node3 # crm configure show rsc_SAPHanaCon_HA1_HDB00 | grep PREFER_SITE_TAKEOVER
  • 7. Refresh that SAPHanaController multi-state resource, obviously. 🔄
node3 # crm resource refresh mst_SAPHanaCon_HA1_HDB00
  • 8. And take it out of maintenance — let it live its life.
node3 # crm resource maintenance mst_SAPHanaCon_HA1_HDB00 off
  • 9. Final vibe check. Does everything look fine? 👑
Note: the srHook attribute of the failed former primary is still hanging around. It might get removed, or it'll just get overwritten once that former primary gets registered as the new first DR site. Either way, no panic. 🫶

🦋 Registering former production HANA as the new DR (aka the glow-up)

Do this when both sites — or honestly at least one 💅 — of the former production region have recovered after an outage. This is what re-establishes DR redundancy, iykyk.

At all nodes, the automatic start of the cluster at boot should be disabled. Fr fr. If automatic start is not disabled, you gotta take additional measures (there's a whole section for that below 👀). All site names have to be the same as already known to the cluster. Example below is for scale-up. Details on how to perform the steps can be found in additional examples below and in manual page SAPHanaSR_maintenance_examples(7). SID is HA1, instance number is 00.

  • site1, node1: currently idle, to become first DR replication target
  • site2, node2: currently idle, to become second DR replication target
  • site3, node3: production primary
  • site4, node4: production secondary
Note: understand the impact before trying this. Like, genuinely. 😭
  • 1. Collect information and prepare your parameter sheet. 🎀
  • 2. Start the Linux cluster on the first DR site only (node1).
node1 # crm cluster start
  • 3. Set the SAPHanaController multi-state resource into maintenance.
node1 # crm resource maintenance mst_SAPHanaCon_HA1_HDB00
  • 4. Change SAPHanaController to PREFER_SITE_TAKEOVER=DR.
node1 # crm configure set rsc_SAPHanaCon_HA1_HDB00.PREFER_SITE_TAKEOVER DR
node1 # crm configure show rsc_SAPHanaCon_HA1_HDB00 | grep PREFER_SITE_TAKEOVER
  • 5. Start the Linux cluster on the second DR site (node2).
node1 # crm cluster start --all
The next steps will overwrite all HANA data at the former production sites (site1, site2). Like, gone gone. 💀
  • 6. Register the first DR site (node1) as secondary to the current primary (node3).
node1 # su - ha1adm
node1 ~> hdbnsutil -sr_register --remoteHost=node3 --remoteInstance=00 \
 --replicationMode=async --operationMode=logreplay \
 --force_full_replica --name=site1
node1 ~> exit
  • 7. Start HANA at the first DR site (node1).
node1 # su - ha1adm -c "HDB start"
  • 8. Enable system replication at the first DR site (node1).
node1 # su - ha1adm -c "hdbnsutil -sr_enable"
  • 9. Register the second DR site (node2) as secondary to the first DR site (node1).
node2 # su - ha1adm
node2 ~> hdbnsutil -sr_register --remoteHost=node1 --remoteInstance=00 \
 --replicationMode=syncmem --operationMode=logreplay \
 --force_full_replica --name=site2
node2 ~> exit
  • 10. Refresh the SAPHanaController multi-state resource. ✨
node2 # crm resource refresh mst_SAPHanaCon_HA1_HDB00
  • 11. Get the SAPHanaController multi-state resource out of maintenance.
node2 # crm resource maintenance mst_SAPHanaCon_HA1_HDB00 off
  • 12. Change the srHook attribute of the first DR site (site1) to SWAIT.
node2 # crm_attribute -n hana_ha1_site_srHook_site1 -v SWAIT -t crm_config -s SAPHanaSR
  • 13. Check that everything looks fine. Slay. 💅

🌈 Switching HANA production and DR region while keeping HANA running

This one's for regular maintenance procedures, bestie. 🧚

The third site is up and running with system replication enabled. All site names have to be the same as already known to the cluster. Example is for scale-up. Details on how to perform the steps can be found in additional examples below and in manual page SAPHanaSR_maintenance_examples(7). SID is HA1, instance number is 00.

  • site1, node1: current production primary, to become first DR replication target
  • site2, node2: current production secondary, to become second DR replication target
  • site3, node3: current first DR replication target, to become production primary
  • site4, node4: current second DR replication target, to become production secondary
Note: understand the impact before trying. For real. 😭
  • 1.1 Collect information and prepare your parameter sheet.
The next steps will invalidate all HANA data at the current production sites (site1, site2).
  • 2.1 Set the SAPHanaController multi-state resource into maintenance at the production sites (site1, site2).
node1 # crm resource maintenance mst_SAPHanaCon_HA1_HDB00
  • 2.2 Change SAPHanaController to PREFER_SITE_TAKEOVER=DR at the production sites (site1, site2).
node1 # crm configure set rsc_SAPHanaCon_HA1_HDB00.PREFER_SITE_TAKEOVER DR
node1 # crm configure show rsc_SAPHanaCon_HA1_HDB00 | grep PREFER_SITE_TAKEOVER
  • 2.3 Refresh the SAPHanaController multi-state resource at the former production sites (sites1, sites2).
node1 # crm resource refresh mst_SAPHanaCon_HA1_HDB00
  • 2.4 Stop HANA at the former production secondary (site2).
node2 # su - ha1adm -c "HDB stop"
  • 3.1 Set the SAPHanaController multi-state resource into maintenance at the current DR sites (site3, site4).
node3 # crm resource maintenance mst_SAPHanaCon_HA1_HDB00
  • 3.2 Perform the takeover at the third site (site3: current DR → new production). 👑
node3 # su - ha1adm -c "hdbnsutil -sr_takeover --suspendPrimary"
node3 # su - ha1adm -c "cdpy; python systemReplicationStatus.py; echo rc:$?"
  • 3.3 Change SAPHanaController to PREFER_SITE_TAKEOVER=yes at the new production sites (site3, site4).
node3 # crm configure set rsc_SAPHanaCon_HA1_HDB00.PREFER_SITE_TAKEOVER yes
node3 # crm configure show rsc_SAPHanaCon_HA1_HDB00 | grep PREFER_SITE_TAKEOVER
  • 3.4 Refresh the SAPHanaController multi-state resource at the new production sites (site3, site4).
node3 # crm resource refresh mst_SAPHanaCon_HA1_HDB00
  • 3.5 Get the SAPHanaController multi-state out of maintenance at the new production sites (site3, site4).
node3 # crm resource maintenance mst_SAPHanaCon_HA1_HDB00 off
  • 3.6 Check that everything looks fine so far. 🫶
The next steps will overwrite all HANA data at the former production sites (site1, site2). Yeah. All of it. 💀
  • 4.1 Register the former production primary as secondary (site1) to the new production primary (site3).
node1 # su - ha1adm
node1 ~> hdbnsutil -sr_register --remoteHost=node3 --remoteInstance=00 \
 --replicationMode=async --operationMode=logreplay \
 --force_full_replica --name=site1
node1 ~> exit
  • 4.2 Enable the system replication source at the new first DR site (site1).
node1 # su - ha1adm "hdbnsutil -sr_enable"
  • 4.3 Register the new second DR site (site2) to the first DR site (site1).
node2 # su - ha1adm
node2 ~> hdbnsutil -sr_register --remoteHost=node1 --remoteInstance=00 \
 --replicationMode=syncmem --operationMode=logreplay \
 --force_full_replica --name=site2
node2 ~> exit
  • 4.4 Start the new second DR site (site2).
node2 # su - ha1adm -c "HDB start"
  • 4.5 Refresh the SAPHanaController multi-state resource at the new DR sites (site1, site2).
node2 # crm resource refresh mst_SAPHanaCon_HA1_HDB00
  • 4.6 Get the SAPHanaController multi-state out of maintenance at the new DR sites (site1, site2).
node2 # crm resource maintenance mst_SAPHanaCon_HA1_HDB00 off
  • 4.7 Check that everything looks fine. 🌸

🎀 Switching HANA production and DR region with HANA shut down

This is the move for a regular takeover from the production region to the DR region, and honestly it's a great exercise too. The final status is identical to the takeover procedure above. ✨

The third site is up and running with system replication enabled. All site names have to be the same as already known to the cluster. Example for scale-up. Details on how to perform the steps can be found in additional examples.

  • site1, node1: current production primary, to become first DR replication target
  • site2, node2: current production secondary, to become second DR replication target
  • site3, node3: current first DR replication target, to become production primary
  • site4, node4: current second DR replication target, to become production secondary
Note: understand the impact before trying. Seriously, read it twice. 🙈
  • 1.1 Collect information and prepare your parameter sheet.
  • 2.1 Set the SAPHanaController multi-state resource into maintenance at the production sites (site1, site2).
node1 # crm resource maintenance mst_SAPHanaCon_HA1_HDB00
The next steps will stop HANA at the production sites.
  • 2.2 Stop the HANA database at the production primary site (site1).
node1 # su - ha1adm -c "HDB kill"
node1 # su - ha1adm -c "HDB info"
  • 2.3 Stop the HANA database at the production secondary site (site2).
node1 # ssh node2 'su - ha1adm -c "HDB kill" '
node1 # ssh node2 'su - ha1adm -c "HDB info" '
  • 3.1 Perform the takeover to the DR region as described in the respective example. 🦋
  • 4.1 Register the former production HANA as the new DR as described in the respective example.

💜 Additional measures when registering former production as new DR — but automatic cluster start is enabled

To avoid the risk of dual-primary, at any time only one region must be running an HANA primary. Periodt. So if a former production cluster starts for the first time after an outage and a DR takeover, the former HANA primary must not start. If automatic cluster start is enabled, extra steps need to be done before the regular procedure for registering as the new DR region. For scale-up, these steps are:

  • 1. Make sure not both machines will boot after recovery.
  • 2. Boot only one machine.
  • 3. Log in to that machine. Set the SAPHanaController multi-state resource into maintenance.
  • 4. Boot the second machine.
  • 5. Perform the regular procedure for registering former production HANA as new DR.

⭐ Registering the first DR node as secondary to the production primary

Needs to be done at the first DR node. DR site is site3, production primary is node1, SID is HA1, instance number is 00.

# su - ha1adm
~> HDB info
~> hdbnsutil -sr_register --remoteHost=node1 --remoteInstance=00 \
 --replicationMode=async --operationMode=logreplay --name=site3 \
 --online
~> hdbnsutil -sr_state

🔥 Backing up the first DR node and enabling system replication

Needs to be done at the first DR node, before registering another node. First DR site is site3, SID is HA1, instance number is 00.

# su - ha1adm
~> hdbsql -i 00 -u SYSTEM -d SYSTEMDB \
 "BACKUP DATA FOR FULL SYSTEM USING FILE ('backup')"
~> hdbnsutil -sr_enable --name=site3
~> hdbnsutil -sr_state
  • Registering second DR node to first one. Do this at the second DR node, bestie. SID is HA1, site is site4, first DR node is node3, instance number is 00. Needs first DR node up and running.
# su - ha1adm
~> HDB info
~> hdbnsutil -sr_register --remoteHost=node3 --remoteInstance=00 \
 --replicationMode=syncmem --operationMode=logreplay --name=site4 \
 --online
~> hdbnsutil -sr_state
  • Removing orphaned srHook attribute from CIB. Might be done after a former production region site has been registered as new DR region site to the new HANA production primary site. SID is HA1, site is site1. Note: understand the impact before trying, okay? 👀
# crm configure show SAPHanaSR | grep _srHook_site1=
# crm_attribute -n hana_ha1_site_srHook_site1 -t crm_config \
 -s SAPHanaSR --delete
# crm configure show SAPHanaSR | grep _srHook_site1=

📁 FILES 💖

  • /hana/shared/$SID/global/hdb/custom/config/global.ini — the on-disk representation of HANA global system configuration. Very "the config is literally right there" energy.
  • /usr/sap/$SID/SYS/global/security/rsecssfs/ — HANA database secure keystore directory. Guard it like your group-chat admin privileges 🔐

✅ REQUIREMENTS 👑

Okay so before you go full main-character with this setup, these are non-negotiable, bestie:

  • SAPHanaSR-angi version 1.3.4 or later.
  • Only one system replication between the two SAP HANA databases in the Linux cluster. Maximum one system replication to an HANA database outside the Linux cluster.
  • The replication mode is either sync or syncmem for the cluster controlled replication. Replication mode async is not supported inside the Linux cluster. The replication mode is async for the replication from production region to DR region.
  • Once an HANA system replication site is known to the Linux cluster, that exact site name has to be used whenever the site is registered manually. At any time only one site is configured as primary replication source.
  • The Linux clusters have no control over HANA system replication between the production region and the DR region. Like, none. Zero. Zilch. 🙈
  • The first site (C) of the DR region is registered to the primary (B) of the production region, and this replication mode is async. The second site (D) of the DR region is registered to the first site (C) of the DR region, and this replication mode is sync or syncmem.

The resulting topology looks like: [ A <= B' ] -> { C => D }

  • No Multi-SID scenario.
  • The SAPHanaSR with HA cluster at DR region scenario should be configured as progressive variant. See SAPHanaSR-angi-scenarios(7).
  • "register_secondaries_on_takeover = true" is needed at all HANA sites at production region and DR region.
  • All HANA sites need to have the same content in their HANA secure keystore.
  • Sufficient disk space for transaction logs and log backup at each potential replication source. Housekeeping might also help. Yes, the boring stuff matters too 😭
  • Before connecting the DR region to the production region, the production SAPHanaSR-angi scale-up performance-optimised cluster needs to be up and running.
  • Before connecting the DR region to the production region, the DR region has been set up as SAPHanaSR-angi scale-up performance-optimised cluster and the SAPHanaController multi-state resouece has been set into maintenance. (Yes, "resouece" is their spelling, not mine 😭💀)
  • The SAPHanaController parameter "PREFER_SITE_TAKEOVER=DR" has to be set at the DR passive cluster. In case of manual DR takeover, this parameter needs to be changed. See manual page ocf_suse_SAPHanaController(7).
  • After recovery of a former failed primary, the cluster must not start resources before DR passive mode is set. Thus, at all nodes automatic start of the Linux cluster at boot should be disabled. If automatic start is enabled, additional measures are needed. F.e. the nodes are booted one by one manually or the network between nodes is blocked at boot. The customer is responsible for this measures. No pressure or anything 🙃
  • The HA cluster moves an IP address with the HANA primary between the two production nodes. The IP address will not be moved from production region to DR region. However, the same IP address can be used in both regions, if infrastructure allows that.
  • The third site´s srHook attribute is stored in the production cluster CIB. The attribute stays, even if a former production has been registered as DR after takeover. This orphaned attribute might be deleted manually to avoid confusion.
  • The primary site´s srHook attribute is stored in the DR cluster CIB. The attribute stays, even if a takeover happened at the production region. This orphaned attribute might be deleted manually to avoid confusion.
  • Maintenance activities at both regions need to be aligned. Particularly replication topology must not be changed at the same time. Coordinated chaos only, bestie 🤝
  • Decision and procedure for takeover to DR region are in customer´s responsibility. All need to comply to SAP HANA requirements, please refer to SAP documentation for details.
  • Any procedure has to be tested, documented and trained before being applied on production or DR systems. Fr fr, do not freestyle this on prod.

See also the REQUIREMENTS section in manual pages SAPHanaSR(7) and susHanaSR.py(7).

🐛 BUGS 😭

In case of any problem, please use your favourite SAP support process to open a request for the component BC-OP-LNX-SUSE. That's the move. Don't suffer in silence, bestie 🫶

👀 SEE ALSO 🦋

✍️ AUTHORS 🎀

A.Briel, F.Herschel, L.Pinne.

(c) 2026 SUSE LLC

The package SAPHanaSR-angi comes with ABSOLUTELY NO WARRANTY. For details see the GNU General Public License at http://www.gnu.org/licenses/gpl.html.

Okay that's the whole page, bestie — source/version SAPHanaSR_with_DR_HA(7), dated 10 Jun 2026. You're so welcome 💅💖✨

📦 where this page comes from