Problem
When performing actions such as moving resources between schemas, you may face a risk of not being able to restore an inadvertently dropped managed volume.
Note
Data retention policies are distinct from issues around dropped volumes.
Cause
Restoring a managed volume requires altering the backend database, which is not permitted.
Solution
Important!
Because there is no direct method to restore a dropped managed volume, please use extra caution before performing actions.
- Back up a copy of your data to a safe, separate location before starting.
- If a managed volume is dropped, create a new managed volume in the desired schema.
- Use shell commands or other data transfer methods to copy the data from the backup location to the new managed volume.
The best approach is to mitigate the risk generally by always using external volumes for operations that require frequent schema changes.
For more information, please review the Volumes (AWS | Azure | GCP) documentation.