Understanding "Backup and Recovery" in our SLA
Our Cloudworkz environment is optimised to meet your specific Business System (Odoo or Pyramid). The environment is designed to provide the best available uptime and performance.
Keeping your system running is our main priority. Following good IT practice and methods like electronic Performance monitoring and Continuous Integration and Development (CI/CD) will ensure availability of your system and minimise both costs and down time.
But sometimes the unexpected happens and is then that your Backup and Recovery Plan is crucial!
Here is some additional information help non-technical customers to better understand some of the technical terms so you know what you can expect.
Customers with "on premise" hardware and software need to maintain specific Backup and Recovery plans in addition to our normal Cloudworkz services.
Backup and recovery (RTO vs RPO)
When a catastrophe happens, the total down time (time to recovery) and amount of lost data (the recovery point) are 2 vital things we need to minimise. As a business owner, there is very little tolerance for transaction delays and service-level gaps, so even a small window of digital downtime can mean losses in productivity, sales, and customer loyalty. For that reason, every organisation needs a tested disaster recovery (DR) plan.
Two key parameters that define how long your business will be offline and how much data loss will occur are
Recovery Time Objective (RTO) and Recovery Point Objective (RPO).
- RTO is the goal your organisation sets for the maximum length of time it should take to restore normal operations following an outage or data loss.
- RPO is your goal for the maximum amount of data the organisation can tolerate losing. This parameter is measured in time: from the moment a failure occurs to your last valid data backup. For example, if you experience a failure now and your last full data backup was 24 hours ago, the RPO is 24 hours.
Balancing Criticality and Cost
The more stringent the RTO and RPO, the more expensive achieving them can be. For example, if you run a full corporate data backup every day for lower RPO, you’ll consume more storage and network resources than you would if you ran them every week, inflating the expense.
To that end we backup DB transactions (incremental) every few minutes and perform complete backups at least 3 times per 24 hours on weekdays. As file-stores tends to be larger and more cumbersome we focus on complete backups at least once per day.
Our standard setup is designed for an RPO of 60 mins or less and an RTO (return yo operation) of 240 mins or less (from the time we agree to initiate the restore). Your in-house Disaster Recovery Plan is a crucial part of this process. Who in your organisation can decide what and when. Do not under estimate the impact and value of that plan.
Individual cases and incidents may vary, but we test our processes and even your specific backup regularly. We are confident we have found the right balance between criticality and cost for most customers. Should you feel the need to discuss this further or any specific options you might need for your business (example HA solutions) feel free to contact us.
On Premise infrastructure
For customers with "own on site server infrastructure" it is crucial to establish an specific Disaster Recovery Plan (DR Plan) for both hardware and software. Our Service Technicians and Architect can help you to develop a DR Plan. We can help with access to reserve or temporary hardware and action plans to address the restoration of backups and redeployment of hardware. Your backup alone (with us or with another provider) while important is not a DR plan.