Full DR Policy and drills are logged to be done under User Story 210382: Add a system for testing disaster recovery for Azure client production data. Once complete this will be updated with the "in place" policy.
Contents
Azure SQL Databases
Backups
Automated Backups: Azure SQL Database provides automatic backups by default. (no action)
Point-in-Time Restore Verification: Test restoring backups to verify data integrity and recovery processes (to split SQL pool)
Frequency: Restore verification (monthly)
Reporting: Store results - for distribution to clients on request
Routine Backup Shipping: Copies of the latest backup are shipped to the client-specific storage account
Point-in-Time Restore Verification: Test restoring backups to verify data integrity and recovery processes (to split SQL pool)
Frequency: Backup shipping (weekly)
Frequency: Restore verification (monthly)
Reporting: Store results - for distribution to clients on request
Performance Monitoring and Tuning
Performance Monitoring: Use Azure SQL Analytics, Query Performance Insight, or other monitoring tools to track performance metrics
Index Maintenance: Rebuild indexes
Statistics: UpdateStats
Query Optimisation: Identify and optimise long-running queries
Frequency: Update Stats (daily), Index maintenance (weekly), Query optimisation (monthly)
Reporting: Log slow-running queries to the Compucare 8 team
Security Management
TBC
Database Maintenance
Integrity Checks: Run DBCC CHECKDB
Update Statistics: Ensure statistics are updated to maintain query performance.
Frequency: Integrity checks (weekly), Update statistics (weekly).
Disaster Recovery Planning
DR Drills: Conduct disaster recovery drills to test failover and recovery procedures
Review DR Plan: Update and review the "disaster recovery plan" based on drill outcomes
Frequency: DR drills (annually), DR plan review (annually).
Azure Storage Accounts
Replication: Replicated across different geographical locations.
Frequency: One-time setup with periodic review (annually)
Regular Backups
Backup Strategy: Recovery Point strategy for 31 days
Frequency: As per RPO (Recovery Point Objective) requirements
Monitoring and Alerts
Metrics and Logs: Enable and review metrics and logs for storage accounts to monitor usage and performance, and detect anomalies
Alerts: Set up alerts for critical metrics and events (e.g., storage capacity, transaction rates)
Frequency: Review of alerts and logs (weekly)
Data Integrity Checks
Azure Blob Storage: Use features like Azure Blob Storage's lifecycle management policies to automatically check and maintain data integrity
Frequency: As per policy schedule (weekly)
Disaster Recovery Drills
Failover Testing: Conduct failover testing to ensure that data can be successfully replicated and accessed from the secondary region
Recovery Procedures: Document and test the recovery procedures to ensure they are effective and up-to-date.
Frequency: Drill (annually)
Geo-Replication Testing
Read-Access Geo-Redundant Storage (RA-GRS): Regularly test accessing data from the secondary region in read-only mode to ensure it is available
Frequency: Test data access (quarterly)
Reporting Back to Clients
Frequency: Report of checks and results of all of the above (quarterly)
Client Access to Storage Account
In the unlikely event of Streets Heaver becoming insolvent, all Streets Heaver Azure Subscriptions will enter a Disabled state due to non-payment. This state is Read-Only, allowing data to still be downloaded.
Streets Heaver will provide monthly Shared Access Signature (SAS) keys to authorized parties. These SAS keys grant read access to the clients' Azure storage accounts, including the latest shipped backup. Each month, newly generated SAS keys will be shared with authorised parties, ensuring continuous access to the storage account.
Clients can use these SAS keys to download their data at any time, both before and after the resources are disabled. However, it is important to act quickly in the event of insolvency, as your data will only be retained for a limited period, typically up to 90 days. After this retention period, the data may be permanently deleted.
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article