Facebook
Twitterjorge ceballos
Regular Pleskian
- Server operating system version
- CentOS Linux 7.9.2009 (Core)
- Plesk version and microupdate number
- Plesk Obsidian v. 18.0.52 update 3
Hi,
Some weeks ago had an issue with a broken kernel update - first in over a decade - and this situation has made us think on reviewing our emergency backups and procedures.
One of the solutions on the table is a snapshot of the volume - AWS in our case - but I recall that sometime in the past we couldn't restore on an image / snapshot as Plesk had a unique ID linked to a particular volume or instance (sorry, don't exactly recall what was it) which would impede it to be restored in a brand new instance.
Of course, if this snapshot is attached to a third instance, we would be able to copy users data to a fresh new instance, which would take 3 times as much time to do and wouldn't be optimal as many details have to be retuned and is not the final goal of having an snapshot.
Any idea on how can we be sure our snapshots work when directly applied when requesting a new instance?
TIA
Some weeks ago had an issue with a broken kernel update - first in over a decade - and this situation has made us think on reviewing our emergency backups and procedures.
One of the solutions on the table is a snapshot of the volume - AWS in our case - but I recall that sometime in the past we couldn't restore on an image / snapshot as Plesk had a unique ID linked to a particular volume or instance (sorry, don't exactly recall what was it) which would impede it to be restored in a brand new instance.
Of course, if this snapshot is attached to a third instance, we would be able to copy users data to a fresh new instance, which would take 3 times as much time to do and wouldn't be optimal as many details have to be retuned and is not the final goal of having an snapshot.
Any idea on how can we be sure our snapshots work when directly applied when requesting a new instance?
TIA
