Availability, multi-site behaviour and recovery
High availability and disaster recovery answer related but different requirements. A redundant component can reduce interruption after a limited failure. Recovery planning addresses loss, corruption or unavailability across a wider scenario and includes the data, people and procedures needed to restore service. Begin with the agreed user impact, scope, recovery time objective and recovery point objective. State the measurement conditions instead of treating a percentage availability target as a complete design.
Map dependencies and failure domains
Access, authentication, brokering, VDAs, application services, profile/data storage, DNS and networks may all be needed for a usable session. Two Controllers on one host do not protect against that host failing. Two data centers do not provide independent service if both rely on one unavailable identity or data dependency. Zones and separate sites support different management and failure boundaries; evaluate supported registration, routing, database and data behaviour for the actual design.
Know the continuity mechanism
Local Host Cache uses locally maintained configuration to support specified brokering behaviour during an outage. Its prerequisites and restrictions matter, including zone-local behaviour and the ability of the elected broker to support the load. Workspace service continuity uses connection leases in a supported design; it is not simply the same mechanism renamed or proof that every resource will launch through a local Connector cache. Existing sessions can behave differently from new launches. Test both and state what users must do.
Protect recoverable state
Inventory configuration, database backups, images, certificates, keys, user state and application dependencies. Replication can improve availability but can also propagate deletion or corruption, so it is not automatically a replacement for recoverable backups. Define retention, verification, access protection and restore responsibilities. For a hypothetical profile share with an agreed fifteen-minute RPO, demonstrate that the actual recovery process can recover suitable consistent data within that loss objective rather than merely citing a product feature.
Exercise the runbook
A useful runbook states the triggering scenario, decision authority, sequence, dependencies, verification, communication and return-to-normal procedure. Choose an exercise cadence based on risk, change and organizational requirements rather than claiming a universal annual Citrix rule. Test data consistency, application usability, entitlements and capacity, not just whether a login page opens. Record observed recovery time and data loss against objectives, investigate failures and update the design. Avoid promising automatic active-session migration or seamless multi-site failover when the specific architecture does not provide it.