User Defined Retention Periods for Restore Points
SQL DW doesn't have the capability to specify longer term retention capabilities as released for SQL DB recently. The workaround is to restore and pause. It would be great to have this capability for compliance and auditing requirements.
Thank you for voting for this feature! We are aware of this scenario and are looking into ways of supporting this. In the meantime, stay tuned for an update and please continue voting for this feature.
32 days would be great (to cover a month end)
15 days would be much better than 7 days. For weekly processing you may not pick up a problem early enough to know you have a problem.
32 day would cover end of month processing :-)
for our policy the retention is 2 weeks
Vikram Sahadevan commented
Most of the enterprise customer backup policy would be 30 days , if back up retention gets increased then it would be helpful.
Azieb Araya commented
This is such a big limitation compared to Azure SQL. Having a minimum of 30 days backup retention will be great. Also, Adding the long term backup retention similar to Azure SQL is great to have.
Any updates to this feature?
Arun Kanakaraj commented
We would like the option to save more restore points atleast two months worth. As per business requirement.
capabilities to keep the restore point as customers requirement
My customer looking for it in Singapore
Nava Jeevan commented
Currently, we are seeing a major data issue on our production SQL Data Warehouse. Business Analyst team is so confident that this issue did not exist in production 3 months (June) ago. Between June and now we have done 2 major enhancements for adding additional attributes to the DWH. BA team strongly believes that one of the releases may have caused the current data issue. If I get the database backup files prior to those 2 releases then I should be able to validate it.
Veerendra Thati commented
This is a much requested feature by one of our important customer
Tarun Arora commented
Here is the blogpost I allued to in my previous comment - https://blogs.msdn.microsoft.com/sqlcat/2016/12/20/azure-sql-dw-moving-to-a-different-region-with-restore-from-backup-option/
Tarun Arora commented
The blogpost from your collegues in Azure CAT implies that it's possible to restore SQL DW betwen Azure subscriptions. Which is wrong as it does not work the way the blob projects it does. Can I confirm that SQL DW restore across subscriptions isn't supported today and that this request currently being reviewed will likely enable this functionality?
Henrik Kure commented
We also have a customer who needs better control over backups (more than 7 days and manual control).
We are using 2 logical sets of SQL DWs with 2 SQL DW in each set. We loaded data in to one logical set in production. We want to take the 2nd logical set also to production and need to take back up of the 1st SQL DW and apply on the 2nd logical set of SQL DW. We need a quiet database backup so that the data is in sync in backup copy. We need the ability to request a back up. At this point, we have to stop production for 12-16 hours. The Production is 24X7 for us.
My customers want to have a quiesce point of backup.
Manual backup is required.
They also want to check the cost of the backup.
Anagha Khanolkar commented
+1 for user-initiated backup. This is a feature of interest for my customers.
Hi Greg, LTR and user initiated backup complement each other but also have distinct use cases. Would you kindly create a new suggestion specifically for LTR so we can track that? Thanks.
Greg Galloway commented
There was a recent announcement of the Azure SQL Database Long-Term Retention feature. Maybe adding SQL DW support to that feature would accomplish this request?
The current approach long term backup by restoring as a new DW that stays paused was a good idea until the premium storage switch. Now it's too expensive.
Ralph Kemperdick commented
This is an essential option to keep data over a long period of time offline.