I’ve searched a lot of threads about LVM and snapshots in particular without luck.
My initial plan with LVM was to have a flexible partitioning setup, enabling easy resizing of partitions, and I left no free space outside the LVM partitions.
Can I still use snapshot for backups? I understand snapshots are placed in the same volume group as the volume to be “snapshot’ed”. However, is the snapshot also placed inside existing LVM logical volumes? or should there be unused logical volumes?
Please hint me on how to correct setup - if required?
Creating a snapshot is similar to creating any other logical volume, there must be free space on physical volumes to hold the new logical volume whether or not it is a snapshot. The snapshot is created on one or more physical volumes in the same volume group depending on the snapshot size and available free space on each.
If all the space in the volume group has been allocated to logical volumes a snapshot cannot be created.
Theoretically, or if someone wants to do the work of creating a snapshot script, this seems to be a lvm2 limitation, not a Linux limitation.
To create a script (using raw dmsetup/Linux device manager):
Take a look at dm-snapshot and setup snapshot-origin + snapshot manually via dmsetup create
As cow device use e.g. a file on a different volume (with losetup -f /path/to/file --direct-io=on)
The snapshotted device still must be a lvm2/device mapper file, otherwise its table cannot be changed via dmsetup reload during runtime.
Bonus: Allow files on the snapshotted device, by using fallocate, then getting the disk locations via filefrag, then use dm-linear to map the file directly to a device
Bonus: Use dm-era to make it “feature-complete” and provide Changed Block Tracking to the client. Dm-era doesn’t seem to be supported by LVM2 either.
dattodb surely sounds promising - I’ve read your description and the github description and it does seem to be a more elegant solution.
However it also seems little known to the Linux community? And also it’s an extra layer of functionality so I’m a little hesitant to go that route - compared to “just” releasing some PE’s.
In current setup I can easily tolerate 5-10 minutes of downtime and hence I guess releasing PE’s is a lower complexity route.
I don’t know why but the disk contents became scrambled on two debian servers I tried dattodb on. I decided it was too fragile for my use and removed it from all my systems.
I rebuilt the failed servers and have had no problems since.
I have used LVM for many years without problems. My only annoyance is that I cannot snapshot volumes that have a cache enabled.
Me kind of as well. Plus anything not upstream in Linux is susceptible to breakage. If one is lucky it doesn’t compile, if one is unlucky it has suble (data eating) bugs.
So it would be cool if someone worked on the dm-snapshot, dm-era (+dm-linear) device mapper snapshotting idea above that would give dattobd feature parity (i.e. with CBT).
Hi @uroni
I don’t understand your last message. Maybe because of it’s difficult to translate (my English is not best). If I understood correctly dattodb snapshots not safe to use (data corrupt, data eating)?
Or you mean that problems are only if compile it at 32 bit clients.
Please write in more detail about this. It’s interested what is the best snapshotting mechanism for use? I thought it’s dattodb.