Performance Marketing companies demand redundancy in their Service Level Agreements/ Commitments from DevHub. Here is how we addressed this with one client based on experiences from others as it relates to DevHub's Proxy Technology.
Above is a diagram that outlines how we could setup a system to make backup copies of each Proxy that would be configured to just auto-redirect to the source domain.
We have done this previously for a partner of ours using our Website Tools, but we could adapt it to handle the Proxies/Redirects.
It has two parts that can be leveraged.
1) Local Copies: We setup our systems to make backups of each active Proxy (redirects) and store those on a non-production server on our side.
If there is a Server/Outage within Rackspace that is affecting our Dynamic Proxy technology (database issues, storage issues, etc), we can flip the traffic over to the Static Copies until the issue is resolved. This option can be used to mitigate downtime as long as Rackspace itself and its load balancers are still available (i.e. non-Brownout, non-disaster situation).
2) Remote Copies: We can also have the system Send copies of each Proxy to a remote datacenter controlled by CLIENTNAME outside the Rackspace environment (AWS, etc).
In the event of a major outage at Rackspace, and to switch Domains over to these remote copies, you would need to leverage a DNS Provider that would allow you quickly switch all Proxy domains to point to the Remote Server at once. Options our partners have used in the Past are Self-Hosted DNS or through an API-based provider like DYN.com.
The DNS records would be configured with a TTL (time to live) that would allow for you to have a maximum downtime (i.e. 1 hour) as the DNS change you make is propagating across the Internet.