Assigned
Status Update
No update yet.
Comments
pr...@google.com
I have forwarded your request to our engineering team. I cannot provide an E.T.A. or guarantee that this feature will be deployed. Rest assured that your feedback is always seriously taken. Any future updates will be posted on this thread.
nn...@oden.io
Is there any progress with that feature request?
ma...@gmail.com
Comment has been deleted.
ma...@patientsknowbest.com
+1 to voting for the ip4r extension. Currently not supported in Cloud SQL and we make use of it.
nn...@oden.io
Any updates on this? It's blocking a migration from RDS to google cloud.
Description
What you would like to accomplish:
-------
Enable a retention policy that prevents deletion of Cloud SQL managed backups. This would simplify and speed up disaster recovery.
-------
How this might work:
-------
You have a Bucket-Lock feature for storage buckets today. We would like to have a similar solution for Cloud SQL managed backups. Some kind of policy that prevent deletion. Reference
-------
If applicable, reasons why alternative solutions are not sufficient:
-------
Today if someone hacks an google project admin account or one is hit by ransomware it is very easy for an attacker to delete a GCP project including the SQL backups.
Todays alternative is to use the SQL Export feature to export your database backups to a storage bucket with Bucket-Lock policy enabled. This is very time consuming, especially on Cloud SQL for Postgres where you can only export one database at a time in serial (both in GUI and Rest API). This can take many hours or even days. Even if all databases could be dumped this is not an optimal solution. You have now lost the benefit of the incredibly fast managed backups if you now also have to export them a second time with a slow process.
It would be great if the speed of Cloud SQL managed backups could be combined with an option to protect these backups with a retention policy working the same way as Bucket-Lock.
In this case an example disaster is that someone deleted all your GCP projects, including your secondary instance you replicate to and all the backups. It doesn't have to be a malicious attacker, it could be someone running the wrong Terraform command and your data is gone. The point is that is useful to be able to protect the existing managed backups since you now avoid running additional export jobs. The restore from a managed backup is also much faster (minutes) compared to hours or days with the SQL import feature.
-------
Other information (workarounds you have tried, documentation consulted, etc):
-------
-