Disaster Recovery Best Practices

  • Backup Data with Resilient Instances - Resilient instances refer to the capability of replicating secrets data to another cloud or on-premises instance of Secret Server with automated one-way synchronization from the source instance to the replica. Replicas should be kept in read-only mode to avoid loss of integrity. This ensures continuous access to secrets, even during emergencies, thereby reducing the risk of downtime or disruption in privileged access. See Working with Resilient Secrets section of the Delinea Platform documentation to learn more.

  • Using Multifactor Authentication (MFA) - For disaster recovery planning, the relevant MFA consideration is ensuring that critical secrets remain accessible during a disaster scenario—either by configuring MFA methods that will function in a disaster recovery event or by establishing break-glass procedures for emergency access. Refer to Multi-Factor Authentication for more information.

  • Security Hardening - Security hardening for Secret Server involves implementing a series of best practices and configurations to enhance the security of your Secret Server instance. This includes securing the operating system, application settings, database, and network communications. Hardening must be applied to both primary and replica instances. Refer to the Security Hardening Guide for more information.

Please be sure to test the items in the Security Hardening Guide one at a time as multiple simultaneous changes can cause issues in case you need to test or revert the changes.

  • Setting Up Event Alerting - provides robust alerting and notification features to help administrators stay informed about critical events and actions. Refer to Event Subscription Overview for information.

  • (Secret Server On-Premises only) Leverage Rabbit MQ's Disaster Recovery Capabilities - The Best high availability/disaster recovery multi-site deployment for RabbitMQ Helper in Secret Server is designed to provide high availability and disaster recovery across multiple locations, typically a primary and a secondary disaster recover site. This setup ensures that RabbitMQ Helper clusters are available in multiple locations, providing robust failover capabilities. Learn more about Rabbit MQ.

    For failover to a secondary location, configure SQL Server with an availability group (either standard or basic availability groups). This allows the database to fail over alongside your Secret Server instance.

Version Compatibility

Although there is typically no stringent requirement to align the releases between the source and replica, it is considered best practice to maintain the replica at the same release version of Secret Server as the source to ensure compatibility.

For Resilient Secrets, the source and replica versions do not need to match exactly, though newer features won't be available on the older instance. Keep versions as close as possible. Note that cloud and on-premises versions will never align exactly due to different release schedules.

For traditional disaster recovery (non-Resilient Secrets): On-premises to on-premises configurations must run identical Secret Server versions.

Individual releases may necessitate upgrading, and customers should refer to the release notes for specific requirements. Additionally, customers are advised to always upgrade to ensure their release is within Delinea Support's stated policy.