Overview
The FocalPointK12 Platform provides data backup and disaster recovery. It provides policies for recovering from disruptive events that could cause data loss or cause the database and application to become unavailable. The policies include what to do when a user or application error affects data integrity, an Azure region has an outage, or the application requires maintenance.
Data Backup with Azure SQL Database
Azure SQL Database provides several business continuity features, including automated backups and database replication. The following are the estimated recovery time (ERT) and the recovery point objective (RPO) for the FocalPointK12 Platform configuration with Azure SQL database. Please note, these are the standard tier SLAs that Azure provides to all the customers.
Point in Time Restore from backup:
Any restore point within 35 days
Geo-Restore from geo-replicated backups:
Estimated Recovery Time < 12h
Recovery Point Objective < 1h
Using Database Backups to Recover a Database
Azure SQL Database automatically performs a combination of full database backups weekly; differential database backups hourly, and transaction log backups every five minutes to protect the business from data loss. These backups are stored in locally redundant storage for 35 days for databases.
Using Active Geo-Replication to reduce recovery time and limit data loss associated with a recovery
In addition to using database backups for database recovery in the event of a business disruption, we also support Azure Active Geo-Replication to configure a database to have a secondary database in the different region in the United States. The secondary database is kept synchronized with the primary database using an asynchronous replication mechanism. This feature is used to protect against business disruption in the event of a data center outage or during an application upgrade.
Recover a database after a user or application error
Perform a point-in-time restore
We can use the automated backups to recover a copy of your database to a known good point in time if time is within the database retention period. After the database is restored, we can either replace the original database with the restored database or copy the needed data from the restored data into the original database.
Restore a deleted database
If the database is deleted but the logical server has not been deleted, we can restore the deleted database to the point at which it was deleted. This restores a database backup to the same logical SQL server from which it was deleted. We can restore it using the original name or provide a new name or the restored database.
Data Recovery Drill Procedures
Our policy is that validation of application readiness for recovery workflow is performed twice annually.
Performing a data recovery drill consists of:
- Simulating data tier outage
- Recovering
- Validate application integrity post recovery
Outage simulation
To simulate the outage, delete or rename the source database. This will cause application connectivity failure.
Recovery
Perform the Restore of the database into a different server. Change the application configuration to connect to the recovered database and follow the Configure a database after recovery guide to complete the recovery.
Validation
Complete the drill by verifying the application integrity post recovery (i.e. connection strings, logins, basic functionality testing or other validations part of standard application signoffs procedures).
Comments