Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm trying to back up an LVM volume using Duplicity (note: not just the file contents of the volume, but the actual volume itself, byte-for-byte).

The best way I've so far found is to dd all the data on the LVM volume to a temporary file, include that file in the backup set, and delete it after the backup is made. This seems horribly inefficient, though: I'm needlessly thrashing the disk and duplicating all the data.

What would seem to be needed is a way to do essentially the opposite of mount -o loop. In other words, I don't want to mount a file as a block device: instead, I want to 'mount' a block device as a regular (read-only) binary file — one that Duplicity will then read from and back up for me.

Is there any way to achieve this?

share|improve this question
Sure you can, remember that in Unix "everything is a file" (almost). I don't know Duplicity, but just including the relevant /dev/mapper/... file might be enough. But this will copy everything, including spaces never used and remnants of deleted files. To back that up only makes sense for forensic purposes. – vonbrand Jan 29 '13 at 16:20
Hi @vonbrand — yes, that's what I was hoping too. So perhaps Duplicity has built-in special treatment for block devices which is screwing this use-case up. – George Jan 29 '13 at 16:59
I’m having this problem with a different piece of software. I’ve added a bounty in the hope that somebody will answer it instead of just saying it already works. The software I’m interested in doesn’t even have an option to read it anyway; I don’t think Duplicity does either but I’m not sure there. – Daniel H Jan 15 '15 at 20:30

That's how block devices already work by default. They can be read by any program – after all, dd uses just the standard open() and read() functions to create the image.

share|improve this answer
Hmm — it definitely doesn't work with Duplicity. Perhaps the problem is that Duplicity has built-in special treatment for block devices. – George Jan 29 '13 at 16:09

This is the normal way things already work.

Just add -r or -o ro to the mount options to make it read-only.

Man mount

 ro      The same as -r; mount the file system read-only 
         (even the super-user may not write it).
share|improve this answer

It's not that duplicity has special treatment for block devices, it sees them for what they are, "block special files". For example,

$ stat /dev/dm-0
  File: ‘/dev/dm-0’
  Size: 0           Blocks: 0          IO Block: 4096   block special file
Device: 5h/5d   Inode: 10311       Links: 1     Device type: fc,0
Access: (0660/brw-rw----)  Uid: (    0/    root)   Gid: (    6/    disk)
Access: 2015-01-15 14:19:24.674418470 -0600
Modify: 2015-01-15 14:19:20.917418645 -0600
Change: 2015-01-15 14:19:20.917418645 -0600
 Birth: -

compared to:

$ stat /etc/passwd
  File: ‘/etc/passwd’
  Size: 2740        Blocks: 8          IO Block: 4096   regular file
Device: fc00h/64512d    Inode: 3802485     Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2015-01-15 17:15:01.166461694 -0600
Modify: 2015-01-12 17:02:41.134820776 -0600
Change: 2015-01-12 17:02:41.201820651 -0600
 Birth: -

Duplicity will backup the block special file the same way tar or rsync does.

The only solution that comes to mind would be to write a fuse filesystem to presents all of your block devices as regular files. But that's probably out of the scope of this question.

share|improve this answer
Yes, if this didn’t generate any answers that was my plan. I was hoping it wasn’t necessary or somebody already had. – Daniel H Jan 17 '15 at 6:46
It treats them specially in that it doesn’t just do open() and read() calls on them, because it specifically checks what kind of file it is. A naïve backup system would just read() every file without checking. – Daniel H Jan 17 '15 at 6:47
Right, but you really wouldn't want your backup software to naively open every socket, hard link or sym link either. Is there something you're gaining by not simply mounting the block device and working with it that way? – Ben Grimm Jan 17 '15 at 13:53
The original asker wanted to back up the volume itself; I don’t know why. I want to back up the device itself because it isn’t mounting correctly, and I don’t want to lose data if recovery goes wrong. I’m also planning on using the snapshot feature of the device manager during recovery, but I’d still like a backup of the current state. – Daniel H Jan 17 '15 at 23:33
In that case, I'd just use dd to attempt to backup it, or its partitions. – Ben Grimm Jan 18 '15 at 0:46

There is a software project called diskfile, a FUSE filesystem which exposes block devices as regular readonly files. For example, with a folder mountpoint, you could call diskfile /dev/dm-0 mountpoint, and then mountpoint/dm-0 will be a regular file with the same contents as /dev/dm-0.

share|improve this answer
Perfect! Thanks for the pointer. – Jim Paris May 28 '15 at 3:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .