Mount a block device as a regular file

Question

Preamble

Suppose I have an encrypted partition of 1TB on machine A containing the home directories of a dozen users, let's call this partition sda2. I want to backup that partition on a remote computer B on a daily basis. To keep it secure and simple, the backup on B must be an exact image copy of sda2.

I know I can create a local image of sda2 with the dd command, and even pipe it to B through ssh:

$ dd if=/dev/sda2 | ssh B dd of=/backups/A.sda2.image

The problem with this approach is the sheer size of the partition. 1TB of data doesn't pass through the network easily and this puts a limit on the frequency of backup operations---less than once in a month to be realistic. An incremental backup tool is needed at this point.

rsync, seems to me, is the solution to the previous difficulty. However I fail when I try to test it because rsync treats /dev/sda2 as an special file and the command:

$ rsync /dev/sda2 B:/backups/A.sda2.image

doesn't do what I want.

Question

Is there a way to trick rsync to treat /dev/sda2 a regular file?

Note

I'm not asking if there is an rsync option to do this (if there is such an option that would be great, but that's only half of the story) I want to know if there is something like a mount command or system call that would allow me to create, for instance, a regular file /mnt/sda2.live_image with the raw contents of /dev/sda2, so that other applications can read or write directly on sda2 through sda2.live_image.

Any help is much appreciated.

Answer 1

You can patch the passthrough_fh libfuse demo fs like this:

diff --git a/example/passthrough_fh.c b/example/passthrough_fh.c
index 13eb41e..146cb03 100644
--- a/example/passthrough_fh.c
+++ b/example/passthrough_fh.c
@@ -72,6 +72,21 @@ static void *xmp_init(struct fuse_conn_info *conn,
    return NULL;
 }

+
+static void b2r(int devfd, struct stat *stbuf)
+{
+   off_t disk_size;
+
+   disk_size = lseek(devfd, 0, SEEK_END);
+   if (disk_size == -1)
+       return;
+
+   stbuf->st_size = disk_size;
+   stbuf->st_blocks = disk_size / stbuf->st_blksize;
+   stbuf->st_mode &= ~S_IFBLK;
+   stbuf->st_mode |= S_IFREG;
+}
+
 static int xmp_getattr(const char *path, struct stat *stbuf,
            struct fuse_file_info *fi)
 {
@@ -85,6 +100,16 @@ static int xmp_getattr(const char *path, struct stat *stbuf,
        res = lstat(path, stbuf);
    if (res == -1)
        return -errno;
+   if (S_ISBLK(stbuf->st_mode)) {
+       int fd;
+       if (fi)
+           fd = fi->fh;
+       else
+           fd = open(path, O_RDONLY);
+       b2r(fd, stbuf);
+       if (!fi)
+           close(fd);
+   }

    return 0;
 }

If mount it as root, it will present you a mirror of your filesystem with block devices appearing as regular files. Pass -omodules=subdir,subdir=/dev to mirror only /dev.

(I'm using a variant of this patch on my dualboot Mac / Linux machine to be able to boot up my Linux installation as an Xhyve VM in OS X, as Xhyve refuses to use block devices.)

Answer 2

Block device based backup are usually a wrong idea, as explained in the comment.

On a non-encrypted device, one usually would do it using the following steps:

1. Fill empty space with zero (dd if=/dev/zero of=<mountpoint>/tmp_zero_file bs=1M) so that free space is compressed with the better ratio.
2. Then dd if=<your block device> |gzip -9 | ssh backup_host "cat > backup.gz"
3. Then rm <mountpoint>/tmp_zero_file.

The problem here is that, since your disk is encrypted, writing 0 into a file won't result in zero'ed blocks because of the encryption layer.

For your use-case, i strongly recommend using duplicity which is a rsync-based backup tool implementing encryption and incremental backups.

Answer 3

As long as you look at the whole partition you have to read it whole to find what has changed. In fact you have to read the new version and the old version to locate the changes, so you have better bluntly copy the whole thing over. With Gigabit Ethernet and good disks, you get 100MB/s, so your terabyte is going to take 10000s or roughly 3 hours, so a nightly backup is doable. OTOH if the target is a SSD you will wear it out fast.

Note that what you do is not a backup but a mirror. It doesn't really help users who delete files by mistake if they find this out after one mirroring has happened.