LVM snapshots on client, free space requirement?

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?

Kind regards,
Michael

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.

1 Like

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.
1 Like

Why don’t you use dattobd snapshots?

In my opinion, this is just an amazing tool for creating snapshots!
It doesn’t need to have LVM. You can use it almost at any file systems.

I wrote about it here:

I understand the general ideas of above, however, I do not dare go that route at the moment.

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.

A: 32 bit clients with 32 bit processors. There’s no x86 build of dattobd, only x86_64.

I don’t trust dattodb.

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.

Thank you in advance!