This document describes the Ripple Treasury Disaster Recovery Plan which refers to the routines and precautions taken by Ripple Treasury in order to prevent and/or mitigate and recover from a significant adverse event which disrupts the company’s key operations. This document describes Ripple Treasury’s disaster recovery availability, redundancy, backups and failover process.
This document delineates our policies and procedures for technology disaster recovery, as well as our process-level plans for recovering critical technology platforms and the telecommunications infrastructure. Modifications to this plan may be made at any time to ensure the physical safety of Ripple Treasury employees, our systems, and our data.
Our mission is to ensure information system uptime, data integrity and availability, and business continuity. In the event of a disaster, Recovery Time Objective and Recovery Point Objective are defined as follows:
Recovery Time Objective – 4 hours
Recovery Point Objective – 30 minutes
The Disaster Recovery plan should cover all essential and critical infrastructure elements, systems and networks within Ripple Treasury’s control. Disaster Recovery should be tested at least twice every 12 months. All relevant staff must be made aware of the disaster recovery plan and their own respective roles. The disaster recovery plan is to be kept up to date to consider changing circumstances. The plan will be reviewed and updated (if appropriate) at least annually.
The principal objective of the disaster recovery plan is to develop, test and document a well-structured and easily understood plan which will help the company recover as quickly and effectively as possible from an unforeseen disaster which interrupts information systems.
Maintain full redundancy within a data center where feasible.
Maintain available capacity within a data center to support full failover of another data center.
Maintain available capacity within a data center to support failure of at least one node in a pool.
Automate failover where feasible.
Data Center Failover
All data centers are consistent in design. As such, the only distinction between environments is that a client database will be accessible in one location and not accessible in the other until failover occurs. A full data center failover is a manual process in as much as a decision is made to do so, as opposed to automatically failing over based on set events. The exact nature of the process depends on whether the primary databases are still available, as the access to those databases will determine whether any data loss occurs.
Full failover should be an extremely rare event where the source environment is incapable of fulfilling its role for an extended period. The nature of the issue, timing, and the expected time to resolve significant problems will each play a role in the decision.
Data Synchronization
There are two repositories of data within the environment – file servers and database servers. File servers are synchronized across all instances using DFS-R (Windows Distributed File System Replication) within a given region. Database servers use two techniques to maintain consistency:
AlwaysOn – a SQL Server technology used between database servers within a data center. Transactions are written to all servers within a region simultaneously such that they can failover almost instantly with no loss of data.
Log Shipping – a custom version of SQL Server technology used between database servers within a region in different data centers. Log records are backed up every 10 minutes, copied across to the other data center and restored to the target database. This database is not available for queries in recovery mode but can easily be brought online with a simple command. This technique drives the RPO objective of 30 minutes.
Backups
Full backups are taken weekly, with daily differential backups each day in between. Backups are verified weekly. These backups are stored in a geo-redundant Azure storage account subscription in an encrypted form and retained for at least 30 days. They are tested for restorability on a weekly basis to ensure no corruption. The DevOps team will review the unrestored database report for any exceptions and act accordingly. Restore of a database backup in a production environment would be extremely rare as it will almost certainly add an element of data loss – failover to one of the other servers will almost always be the preferred solution to any issue.
Failover Testing
By Ripple Treasury policy, failover testing is formally conducted at least twice per year. It is an execution of a series of steps designed to verify that Ripple Treasury can handle specific scenarios relating to failures of devices, data centers, or services (e.g. DNS). Since each data center runs live, full data center failover is not tested directly. Several scenarios are tested on a regular (monthly or less) basis as part of operating system or application patching, such as web server failover, hypervisor downtime, authentication server (RSA) upgrade, etc.
Communication
Disaster Notification
In the event of an emergency, the Disaster Recovery Team will assemble to take control of the situation. Customers affected by the emergency will be notified promptly by the Solutions Delivery team and updated on the nature of the emergency, how it was discovered, and the impact (if any) on business operations. The Solutions Delivery team is responsible for communicating status on an ongoing basis to customers.
Plan Documentation Storage
The Disaster Recovery Plan is stored on the intranet so that all relevant personnel are able to readily access the plan if the need arises.
Disaster Recovery Team
The Disaster Recovery Team consists of representatives from the Security, Compliance, DevOps, IT, and Client Services functions or delegates.
The team's responsibilities include:
Restore key services within 4 business hours of the incident
Recover to business as usual within 8-24 hours after the incident
Coordinate activities with disaster recovery team, first responders, etc.
Emergency Alert, Escalation and DRP Activation
This policy has been established to ensure that in the event of a disaster or crisis, personnel will have a clear understanding of who should be contacted. Procedures have been addressed to ensure that communications can be quickly established while activating disaster recovery. The disaster recovery plan will rely principally on key members of management and staff who will provide the technical and management skills necessary to achieve a smooth technology and business recovery.
The person discovering the incident calls a member of the Disaster Recovery team.
The Disaster Recovery team is responsible for activating the Disaster Recovery Plan and coordinating with Incident Commanders for any Severity Level 1 or Severity Level 2 issues which may impact and/or be related to disaster recovery.
Documentation
The Disaster Recovery team will keep detailed notes surrounding any events, including dates, times, actions, contacts, follow-up and remediation, etc. for the purposes of root cause analysis and future prevention.
Copyright 2025 Ripple Labs Inc.
This document describes the Ripple Treasury Disaster Recovery Plan which refers to the routines and precautions taken by Ripple Treasury in order to prevent and/or mitigate and recover from a significant adverse event which disrupts the company’s key operations. This document describes Ripple Treasury’s disaster recovery availability, redundancy, backups and failover process.
This document delineates our policies and procedures for technology disaster recovery, as well as our process-level plans for recovering critical technology platforms and the telecommunications infrastructure. Modifications to this plan may be made at any time to ensure the physical safety of Ripple Treasury employees, our systems, and our data.
Our mission is to ensure information system uptime, data integrity and availability, and business continuity. In the event of a disaster, Recovery Time Objective and Recovery Point Objective are defined as follows:
Recovery Time Objective – 4 hours
Recovery Point Objective – 30 minutes
The Disaster Recovery plan should cover all essential and critical infrastructure elements, systems and networks within Ripple Treasury’s control. Disaster Recovery should be tested at least twice every 12 months. All relevant staff must be made aware of the disaster recovery plan and their own respective roles. The disaster recovery plan is to be kept up to date to consider changing circumstances. The plan will be reviewed and updated (if appropriate) at least annually.
The principal objective of the disaster recovery plan is to develop, test and document a well-structured and easily understood plan which will help the company recover as quickly and effectively as possible from an unforeseen disaster which interrupts information systems.
Maintain full redundancy within a data center where feasible.
Maintain available capacity within a data center to support full failover of another data center.
Maintain available capacity within a data center to support failure of at least one node in a pool.
Automate failover where feasible.
Data Center Failover
All data centers are consistent in design. As such, the only distinction between environments is that a client database will be accessible in one location and not accessible in the other until failover occurs. A full data center failover is a manual process in as much as a decision is made to do so, as opposed to automatically failing over based on set events. The exact nature of the process depends on whether the primary databases are still available, as the access to those databases will determine whether any data loss occurs.
Full failover should be an extremely rare event where the source environment is incapable of fulfilling its role for an extended period. The nature of the issue, timing, and the expected time to resolve significant problems will each play a role in the decision.
Data Synchronization
There are two repositories of data within the environment – file servers and database servers. File servers are synchronized across all instances using DFS-R (Windows Distributed File System Replication) within a given region. Database servers use two techniques to maintain consistency:
AlwaysOn – a SQL Server technology used between database servers within a data center. Transactions are written to all servers within a region simultaneously such that they can failover almost instantly with no loss of data.
Log Shipping – a custom version of SQL Server technology used between database servers within a region in different data centers. Log records are backed up every 10 minutes, copied across to the other data center and restored to the target database. This database is not available for queries in recovery mode but can easily be brought online with a simple command. This technique drives the RPO objective of 30 minutes.
Backups
Full backups are taken weekly, with daily differential backups each day in between. Backups are verified weekly. These backups are stored in a geo-redundant Azure storage account subscription in an encrypted form and retained for at least 30 days. They are tested for restorability on a weekly basis to ensure no corruption. The DevOps team will review the unrestored database report for any exceptions and act accordingly. Restore of a database backup in a production environment would be extremely rare as it will almost certainly add an element of data loss – failover to one of the other servers will almost always be the preferred solution to any issue.
Failover Testing
By Ripple Treasury policy, failover testing is formally conducted at least twice per year. It is an execution of a series of steps designed to verify that Ripple Treasury can handle specific scenarios relating to failures of devices, data centers, or services (e.g. DNS). Since each data center runs live, full data center failover is not tested directly. Several scenarios are tested on a regular (monthly or less) basis as part of operating system or application patching, such as web server failover, hypervisor downtime, authentication server (RSA) upgrade, etc.
Communication
Disaster Notification
In the event of an emergency, the Disaster Recovery Team will assemble to take control of the situation. Customers affected by the emergency will be notified promptly by the Solutions Delivery team and updated on the nature of the emergency, how it was discovered, and the impact (if any) on business operations. The Solutions Delivery team is responsible for communicating status on an ongoing basis to customers.
Plan Documentation Storage
The Disaster Recovery Plan is stored on the intranet so that all relevant personnel are able to readily access the plan if the need arises.
Disaster Recovery Team
The Disaster Recovery Team consists of representatives from the Security, Compliance, DevOps, IT, and Client Services functions or delegates.
The team's responsibilities include:
Restore key services within 4 business hours of the incident
Recover to business as usual within 8-24 hours after the incident
Coordinate activities with disaster recovery team, first responders, etc.
Emergency Alert, Escalation and DRP Activation
This policy has been established to ensure that in the event of a disaster or crisis, personnel will have a clear understanding of who should be contacted. Procedures have been addressed to ensure that communications can be quickly established while activating disaster recovery. The disaster recovery plan will rely principally on key members of management and staff who will provide the technical and management skills necessary to achieve a smooth technology and business recovery.
The person discovering the incident calls a member of the Disaster Recovery team.
The Disaster Recovery team is responsible for activating the Disaster Recovery Plan and coordinating with Incident Commanders for any Severity Level 1 or Severity Level 2 issues which may impact and/or be related to disaster recovery.
Documentation
The Disaster Recovery team will keep detailed notes surrounding any events, including dates, times, actions, contacts, follow-up and remediation, etc. for the purposes of root cause analysis and future prevention.
Copyright 2025 Ripple Labs Inc.