Business Continuity and Disaster Recovery for SaaS

To ease support and deployment, SD Elements is deployed on a single virtual appliance (Virtual Machine or VM) as a monolithic service. The VM runs nginx (front-end web proxy), apache (application server), postgres (database), and a few other small services (memcache, rabbitmq, etc).


Service Level Objectives (SLO)

SD Elements is a non-mission critical system. As a result, the impact of disruption in service is limited to employee efficiency in product development teams. While service availability is not mission critical, the data stored in SD Elements can affect the quality of the software produced by development team. As a result, data integrity is a more sensitive subject. Our SaaS instances  have the following SLOs:

Recovery Point Objective (RPO): Hourly

Recovery Time Objective (RTO): 1 hour to 1 business day



The system designed to store all its active data in an easy to backup database. A database backup can be loaded back into the appliance as long as the backup and restore are done using the same version of the software. (Note: In extenuating circumstances, the data can be migrated to a newer version, but never to an older version of the software)



Differential Backups of the Database

Our VMs are configured to do hourly snapshots of their database (recommended to setup and test). If required, these dumps can be pulled off our VMs through our support team.

Full Backups of the Database

A recoveryable backup is encrypted and sent offsite daily. In the event of an issue these will be used as the dataset should we require to failover.




Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request