Incremental Backup Failure Scenario after DR Restore
Problem: After completing a restoration from the disaster recovery (DR) server following a disaster, users may encounter an issue where...
SSO (Single Sign-On) configuration for Disaster Recovery (DR)
Problem:
Failing to configure SSO correctly for both primary and secondary servers presents a significant risk of user authentication failure during disaster recovery.
Solution:
-
Add IP Addresses to Identity Provider: Include both primary and secondary server IP addresses in the list of call backup URLs on your identity provider during the SSO configuration step.
-
Update SSO Configuration After DR Restore (Secondary Server):
Set the following environment variables using the following commands:
export VAULT_ADDRESS=<vault-address>
If you employed default configurations during Zmanda’s installation, use https://127.0.0.1:8201 as the vault address. If you customized those settings, provide the appropriate alternative address.
export UNSEAL_KEY_PATH=<path-to-zmc-vault-unseal-keys>
If you employed default configurations during Zmanda’s installation, use /var/lib/amanda/vault/zmc_unseal_keys as the unseal key path. If you customized those settings, provide the appropriate alternative path.
export mode=prod
Run the command:
/opt/zmanda/amanda/bin/zmc-service-manage hv_command -–update_sso
By following these steps, you can safeguard your systems against authentication hurdles.
LDAP Configuration for DR
Problem:
Users cannot log in using LDAP authentication after a DR restore to the secondary server.
Solution:
LDAP authentication must be configured on the primary server.
Add LDAP Domain and IP to Hosts File:
-
On both the primary and secondary servers, open the /etc/hosts file using a text editor with administrator privileges.
-
Add a new line containing the LDAP domain and IP address, in the format:
<LDAP domain name> <LDAP IP address>
-
Save changes to the /etc/hosts file.
By following these steps, you can log in using LDAP authentication even after a DR restore.
