2

I'm looking for a way to backup my debian server. For the data partition I have a solution using rsync, the backup goes to an encrypted ntfs-drive. NTFS because I often take the drive with me to watch some movies etc. on my windows laptop.

Backing up the system with rsync does not work, because the permissions are not preserved on ntfs. I was thinking about a tar archive, but the --update flag only adds new files and does not delete files not there anymore.

Is there any way to get some nice in-container backup preserving permissions that is updateable like an rsync update?

1

One way to meet your storage requirements would be to create a loopback filesystem inside your NTFS partition, but the catch to this is that performance of such a loop device would be worse because input-output (I/O) would be happening in a filesystem within a filesystem.

It's fairly simple to set up a loopback filesystem. Assuming that /demo is where you have mounted your NTFS device:

Create a blank non-sparse file

The size is your choice. My example is 1GiB large:

root@node51 [/demo]# dd if=/dev/zero of=loopback.img bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 1.88537 s, 570 MB/s

Format the file using a filesystem that has all the permissions capabilities that you need

I use ext4 in this example:

root@node51 [/demo]# mkfs.ext4 loopback.img
mke2fs 1.42.9 (4-Feb-2014)
loopback.img is not a block special device.
Proceed anyway? (y,n) y
Discarding device blocks: done
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
65536 inodes, 262144 blocks
13107 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=268435456
8 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376

Allocating group tables: done
Writing inode tables: done
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done

You have just created a filesystem inside a file.

Mount the new filesystem

root@node51 [/demo]# mount -o loop loopback.img /mnt

Put data into your new filesystem

root@node51 [/demo]# echo "Data data data" > /mnt/file.txt
root@node51 [/demo]# ll /mnt/
total 28
drwxr-xr-x  3 root root  4096 May 25 09:31 ./
drwxr-xr-x 24 root root  4096 May 25 09:29 ../
-rw-r--r--  1 root root    15 May 25 09:31 file.txt
drwx------  2 root root 16384 May 25 09:30 lost+found/

Conveniently, you can resize the ext4 filesystem quite flexibly.

Enlarge Example

root@node51 [/demo]# ll -h
total 33M
drwxr-xr-x  2 root root 4.0K May 25 09:30 ./
drwxr-xr-x 24 root root 4.0K May 25 09:29 ../
-rw-r--r--  1 root root 1.0G May 25 09:31 loopback.img

root@node51 [/demo]# umount loopback.img

root@node51 [/demo]# e2fsck -f loopback.img
e2fsck 1.42.9 (4-Feb-2014)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
loopback.img: 12/65536 files (0.0% non-contiguous), 12636/262144 blocks
root@node51 [/demo]# resize2fs loopback.img 4G
resize2fs 1.42.9 (4-Feb-2014)
Resizing the filesystem on loopback.img to 1048576 (4k) blocks.
The filesystem on loopback.img is now 1048576 blocks long.

root@node51 [/demo]# ll -h
total 33M
drwxr-xr-x  2 root root 4.0K May 25 09:30 ./
drwxr-xr-x 24 root root 4.0K May 25 09:29 ../
-rw-r--r--  1 root root 4.0G May 25 09:32 loopback.img

Shrink Example

root@node51 [/demo]# ll -h
total 33M
drwxr-xr-x  2 root root 4.0K May 25 09:30 ./
drwxr-xr-x 24 root root 4.0K May 25 09:29 ../
-rw-r--r--  1 root root 4.0G May 25 09:32 loopback.img

root@node51 [/demo]# e2fsck -f loopback.img
e2fsck 1.42.9 (4-Feb-2014)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
loopback.img: 12/262144 files (0.0% non-contiguous), 25167/1048576 blocks

root@node51 [/demo]# resize2fs loopback.img 128M
resize2fs 1.42.9 (4-Feb-2014)
Resizing the filesystem on loopback.img to 32768 (4k) blocks.
The filesystem on loopback.img is now 32768 blocks long.

root@node51 [/demo]# ll -h
total 33M
drwxr-xr-x  2 root root 4.0K May 25 09:30 ./
drwxr-xr-x 24 root root 4.0K May 25 09:29 ../
-rw-r--r--  1 root root 128M May 25 09:44 loopback.img
  • Thanks, that seems like a good solution that allows me to continue using rsync for the backup itself. Is there a way to make the .img file dynamic in size? I already tried setting up a dynamic truecrypt container, which works fine, but performance is not great since the pc has no AES hardware acceleration and the disk itself is already encrypted. – user3696412 May 25 '15 at 18:11
  • @user3696412: There isn't a way to make the .img dynamic in size, especially because the inode tables in the filesystem are static and not easy to change. Manually resizing the .img with filesystem resizing tools is the best you could do with this approach. – Deltik May 25 '15 at 23:03
0

You can try dar ( http://dar.linux.free.fr/ ), as it has incremental backup capability. Haven't tried for disaster recovery, but normal backups seem to work just fine.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.