SAS Position Statement Regarding Disaster Recovery

Last Updated: November 2016


Disaster-recovery planning is important for any critical business system, including production systems running the SAS® Intelligence Platform and SAS® solutions. SAS customers should and usually do have disaster-recovery plans for their SAS deployments, SAS applications, and SAS data files. Because the implementation of the SAS Intelligence Platform and SAS solutions is often highly customized and each customer can have different requirements for replicating SAS content, there is no single tool or process that comprehensively meets all of the SAS disaster-recovery needs.

This position statement assumes that you are familiar with the concepts in “Best Practices for Backing Up and Restoring Your SAS Content” in the SAS® 9.4 Intelligence Platform: System Administration Guide, Fourth Edition.


Disaster recovery is not the same as high availability. Though both concepts are related to business continuity, high availability is about providing undisrupted continuity of operations whereas disaster recovery involves some amount of downtime, typically measured in days. This position statement addresses disaster recovery. SAS recommends that disaster recovery be predicated on regular, full system-image backups or system clones, and that disaster recovery processes be validated on a regular basis. The following approaches reflect supported methods for recovering SAS content in the event of a disaster.

Note: The approaches stated below are not mutually exclusive. More than one supported approach might be required to meet your disaster-recovery objectives.

A. Full-System Backups (also known as Disk Cloning or Disk Imaging)

Use disk cloning or disk imaging of all disks to create and maintain a full-system backup or clone of the production operating environment. As necessary, supplement regularly scheduled disk cloning/imaging with scheduled file-system backups, third-party database backups, and other backup mechanisms supported by your operating-system vendor.

Note: Throughout this position statement, the word “clone” means an exact copy of, at a minimum, the following from the production system:

If the SAS production environment is virtual or container-enabled, you can maintain a full-system clone using a cloning process supported by your virtualization/container software provider. If the SAS production environment is on bare metal, use a disk-cloning or system-imaging technology that is supported and accepted by the operating-system vendor.

Note: A copy of ONLY the SAS deployment is NOT considered a full-system clone.

B. SAS Batch Import and SAS Batch Export Tools

This approach uses SAS promotion tools running in batch mode to back up metadata-based SAS content. Under this approach, packages are exported (“backed up”) from production and imported into the disaster-recovery environment. Any physical content for which a metadata definition exists or can be created can be backed up using this approach. Under this approach, the disaster-recovery environment does not need to be a clone of the SAS production environment.

C. SAS® Migration Utility Packages

This approach uses a migration package created from production to configure a new disaster-recovery system after a failure occurs. The SAS Migration Utility creates a package of metadata and SAS content necessary for the SAS® Deployment Wizard to configure a new disaster-recovery environment1. SAS® 9.4 migration packages generally build quickly and without disruption to business processes. The SAS Migration Utility can be launched from a script that is scheduled to run in accordance with the Recovery Point Objective (RPO) that you have with your business. With respect to the SAS deployment, only the SAS installation2 would exist on the disaster-recovery system. Under this approach, the disaster-recovery environment must have the same topology as the production system. However, it does not need to be a clone of the SAS production system.

1 Many SAS solutions require additional, manual configuration steps specific to your environment. Work with your SAS Account Team to ensure that you have documented any additional “post-migration” steps that you will need to perform.
2 SAS installation means only the SAS installation binaries found under SASHome. It specifically does not include any content under the SAS configuration directory.

Limitations and Considerations

A Note about External Systems and Data

A disaster-recovery plan for SAS environments needs to incorporate disaster-recovery procedures for the external systems and processes that SAS uses or depends upon. These external systems and processes might be as simple as a DNS server address or more complex such as another production application exchanging data with SAS processes. Additional considerations include:


Solely relying on system imaging is a sufficient disaster-recovery plan for many customers; however, this plan depends on the disaster-recovery system being a clone of the production system. When a clone cannot be achieved, additional options are available. Each approach has its limitations and more than one supported approach might be required to meet the RPO and Recovery Time Objective (RTO) of your business. Your disaster-recovery procedures should be well documented, carefully validated, and exercised on a regular basis.