Comment by crazygringo
16 hours ago
Yup, this is bizarre. A top use case for needing a backup is when you accidentally delete the original.
You need to be able to delete backups too, of course, but that absolutely needs to be a separate API call. There should never be any single API call that deletes both a volume and its backups simultaneously. Backups should be a first line of defense against user error as well.
And I checked the docs -- they're called backups and can be set to run at a regular interval [1]. They're not one-off "snapshots" or anything.
Plus backups should be time gated, where the software physically blocks you from removing backups for X days.
This is one of those things that seems like a good idea on the surface but is rife with problems.
Does the company hosting the backups do it for free? Or do they charge their customers to keep holding onto backups they no longer want?
Is “my DB company refuses to delete the data” a valid legal response to a copyright enforcement or a GDPR demand?
I have no idea about the former but yes, it is a valid excuse for latter. Ok, maybe not that specific one but in general backups are going to be excluded, especially those stored on tapes or WORM media - no one expects company to remove offending record here and now, as long it is inaccessible for all practical purposes.
The GDPR says:
> The data subject shall have the right to obtain from the controller the erasure of personal data concerning him or her without undue delay and the controller shall have the obligation to erase personal data without undue delay
"Undue delay" is subjective, but "we'll keep backups of your data for a week in case you change your mind" seems easy to justify in court.
Azure SQL Database did this too for a while until enough companies complained about losing their data and their backups with a single action.
With the difference that best practices in Azure SQL have always been to store your own copies of backups and run the database in some HA/GEO-redundancy mode that blocks deletion.
Which sounds great, except that Azure SQL -- like many cloud services -- was carefully designed to be a tarpit into which you can import your data, but can't get your data back out.
For example, for at least a few years its "external" backups were simply the bacpac export function, which wasn't transactionally consistent and had all sorts of fun limits.