Feature #23
Manage LVM snapshot(s) from Panel
| Status: | New | Start: | 2010-06-28 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assigned to: | - | % Done: | 0% |
|
| Category: | - | |||
| Target version: | - | |||
| Votes: | 6 |
Description
It's currently possible, by contacting support, to have an LVM snapshot made of your block device(s). This is useful when you're about to do something potentially dangerous and want to be able to rollback to the previous state if things go wrong. Major operating system upgrades would be a typical situation.
In order to increase visibility of this option and to encourage people to use it, it would be good if it was possible to manage it from the Panel.
There is a performance penalty for each snapshot in use, and they also take up disk space of course. I can't think of a good way to let people dedicate some of their disk space to snapshots, so it may have to be given for free on a temporary basis. The feature should probably be limited to one snapshot per block device then, with ability to
- rollback to;
- discard; or
download an image of the snapshot.
History
Updated by chaldene over 12 years ago
The other problem with dedicating some disk space to a snapshot is the failure cost if you get it wrong. Since snapshots are COW, when the allocated snapshot space runs out the snapshot becomes invalidated and can't be merged back into the origin, so you're left without a rollback.
I'd feel much more comfortable if the full amount of space was always offered on a temporary basis.
Updated by admin over 12 years ago
Am I right in thinking that if you create an LVM snapshot with size equal to or larger than the origin then it can never become full because it only ever would have to store a complete copy of the origin volume? I've just tried to prove that with some loopback devices and that seems to be the case.
I am still conflicted whether to charge for snapshots. On the one hand, they encourage prudent behaviour and enable the customer to recover from their own mistakes (which would also allow me to not feel so duty-bound to rescue someone who has completely screwed their system up during an upgrade). On the other hand, they come with a severe performance penalty that can affect other customers, and the disk capacity can't be totally ignored either.
Perhaps they should be free to keep around for a few days, after which you have to pay monthly for them.
Updated by admin over 12 years ago
It looks like snapshot rollback only came in with kernel 2.6.33; Debian stable is still on 2.6.32 and I don't fancy messing with the kernels/LVM on my host nodes, so the user-triggered rollback option may either have to be temporarily shelved (submit support ticket and we can still do it manually), or else it will have to be done the hard way with dd and the device mapper targets.
Most of the time people don't have to rollback, so just the ability to create/delete would still be useful.
Updated by admin over 12 years ago
This seems to work:
http://www.kernelcrash.com/blog/reverting-lvm-snapshots/2009/12/11/
Updated by chaldene over 12 years ago
admin wrote:
Am I right in thinking that if you create an LVM snapshot with size equal to or larger than the origin then it can never become full because it only ever would have to store a complete copy of the origin volume? I've just tried to prove that with some loopback devices and that seems to be the case.
That was always my understanding, but I haven't ever verified it.
admin wrote:
It looks like snapshot rollback only came in with kernel 2.6.33; Debian stable is still on 2.6.32
[..] This seems to work:http://www.kernelcrash.com/blog/reverting-lvm-snapshots/2009/12/11/
That suggests Squeeze's kernel has dm-merge support. I checked lvconvert here and it has the --merge option, so you shouldn't need to change anything or use that third party userspace tool, just run lvconvert --merge against the snapshot volume to merge back to the origin.
Updated by admin over 12 years ago
Rather than allow a download option from the panel, I think it would make more sense to attach the snapshot to the VPS as a read-only block device instead.
When the VPS is working that would allow download from the VPS itself, and when the VPS is not working it would allow download from the rescue environment.