The solution has been designed to cater for disasters ranging from a database restore through to a complete datacentre outage. The backup architecture used is critical to being able to respond to the diverse set of restore scenarios that may be required.
All backups are stored on disk and are retained for a period of 12 Months, financial data is kept for 7 years. The backups are stored within a multi tenancy data vault and are encrypted at rest. The design of the architecture means that all data is simultaneously available in both the primary datacentre and the secondary datacentre meaning data is always backed up to another geographically diverse site.
All Servers are back up on a daily basis at 10pm. These backups go directly to storage in the DR Datacentre to ensure off-site availability.
Backup Retention
15-min TLogs - 28 days
Daily - 28 days
Weekly - 3 months
Monthly - 1 year for non-financial data /7 years for financial data
The solution has been designed carefully to deliver Recovery Point Objective (RPO) and Recovery Time Objective (RTO) using the following definitions:
RPO is the maximum time period in which data might be lost.
RTO is the duration of working time within which data should be restored after a disaster. This time starts from when a support call is logged with Access.
This effectively means if our systems go down at 8am, our RTO states you will be back up and running by 2pm and your data, worst case, will be based on data from 8pm the previous day.
As part of the service we do a restore test automatically on a weekly basis which if needed, the results of the customers database restore can be shared each time it’s run.
We run a full DR test on a 6 monthly basis, this is a non-invasive test where we bring the DR site up in an isolated fashion to ensure the services recover (Zerto allows us to do this without bringing the production environments down).
SQL Server
SQL Server Full Database backups are taken overnight as well as having SQL transaction logs taken at 15 minute intervals. This allows a database to be restored to an overnight position or to be restored to a chosen point in time within the day.
Frequently a database is restored following a user accidentally changing lots of data so the RPO does not always apply as the user may have changed the data several days ago, however the solution has been designed with a maximum RPO of 12 hours and a RTO of 6 hours.
Single Virtual Machine Failure – IIS or RDS Server
In the unlikely event of a single virtual machine (VM) failing (e.g. the IIS VM ceases to respond but the other VMs are still functioning correctly) then a new instance of the VM will be started. This new instance will be an exact copy of the VM from when it stopped responding. The solution has been designed so that the files on an IIS and RDS server are fairly static with an RPO of 12 hours and a RTO of 6 Hours
Single Virtual Machine Failure – SQL Server
In the unlikely event of the SQL Server virtual machine (VM) failing then a new instance of the VM will be started. This new instance will be an exact copy of the VM from when it stopped responding. The solution has been designed with an RPO of 12 hours and a RTO of 6 Hours
Complete Primary Datacentre Outage
In the unlikely event that the primary datacentre goes completely dark where all VMs are lost or there is no internet connectivity an investigation period will be undertaken for 2 hours to determine the cause and decide if a datacentre promotion is required to make the secondary datacentre the primary one. Once this decision has been made the solution has been designed with an RPO of 12 hours and a RTO of 12 Hours
Optional Customer Copies of Backups
The Download My Backups service allows a customer to copy a backup of their SQL Server databases out of the Access Alto environment so that they can be stored securely within a customer chosen environment. Once the backup has been copied out of the Access Alto environment it is entirely their responsibility to keep this data secure.
This service is achieved by using the following process:
Each night a backup of the customer database is taken
The previous night's backup zip files (if present) are removed from your FTPS area
Each backup file is zipped up and password protected with a unique password for that night
The unique password (only) is emailed to the registered customer email address
Each password protected zip file is copied onto the FTPs server
The customer connects to the FTPs server and downloads each password protected zip file as needed
If you have multiple databases then you will receive an email for each database - the nightly password is the same for each
To be able to use this service you need to have the correct credentials for:
A username/password for the FTPs server. This password will require changing on a regular basis as per our standard password policy. This user name is referred to as your Hosting.FTPs user and is different from any other username/password that you use to access your software.
The unique password for the zip file for that particular day’s backup