3

Drive A is 2TB in a closet at home.

Drive B is 2TB in my office at work.

I'd like drive A to be the one I use regularly and to have rsync mirror A to B nightly/weekly.

The problem I have with this is that multiple users have stuff on A.

I have root run rsync -avz from A to $MYNAME:B

Root can certainly read everything on A, but doesn't have permission to write non-$MYNAME stuff on B.

How am I supposed to be doing this? Should I have a passwordless private key on A that logs into root on B? That seem's super dangerous.

Also, I'd prefer to use rsnapshot but it looks like they demand that I draw from B to A using the passwordless private key to root's account that I'm so frightened by.

John Baber-Lucero
  • 609
  • 6
  • 13

3 Answers3

6

There's a --fake-super option that stores the attributes that can't be set in extended attributes (Which means the target FS has to support extended attributes).

To check for extended attribute support, you can do it with setfattr or rsync itself. Then it demonstrates how it works:

~$ rsync --fake-super /bin/ls .
~$ getfattr -dm- ./ls
# file: ./ls
user.rsync.%stat="100755 0,0 0:0"

Note that -a doesn't preserve everything, you might need -H, -A, -X, --numeric-ids.

Stéphane Chazelas
  • 522,931
  • 91
  • 1,010
  • 1,501
4

I know your question is about rsync, but this may be helpful regarding backups. This is roughly how I do my offsite backups.

Rsync-based alternative Rdiff-backup

Rdiff-backup may be worth a try.

It uses rsync (or librsync) under water and handles all magic about permissions and attributes already for you, even when the target filesystem does not support it. This is possible because it will store this in its own format and that works cross-platform too.

As a bonus it also provides differential backups, so you can go 'back in time'. However, rdiff-backup may run slower due to the nature of differential backups.

About SSH keys and security

How am I supposed to be doing this? Should I have a passwordless private key on A that logs into root on B? That seem's super dangerous.

If you're scared about that, which is a sensible thing to be here, the following might be helpful. Prepend the following in one line with the public key you configure on the machine you like to back up (/root/.ssh/authorized_keys):

command="rdiff-backup --server --restrict-read-only /",from="hostname.or.ip.address.to.allow",no-port-forwarding,no-X11-forwarding,no-pty ssh-rsa AAAA.... and the rest of your key in the same line.

This is an example using an RSA key. Change it to your needs.

Optionally, configure the SSH daemon to accept only keys with forced-commands for root. In sshd_config set PermitRootLogin forced-commands-only.

This provides quite some security:

  • Forced command login only for root, in this case running rdiff-backup in read-only server mode.
  • Only authorizes if connection is made from a certain source (host).
  • No TCP port and X forwardings allowed.
  • No pty assigned.

However,

  • Possible security flaws in Rdiff-backup can be exploited.
  • Keep your keys in a safe place, always. (Exclude them from your backup, for example!)
gertvdijk
  • 13,459
  • 7
  • 45
  • 59
3

If it is intended as a backup (I'm looking at the tag), not as a remote copy of working directory, you should consider using tools like dar or good old tar. If some important file gets deleted and you won't notice it, you will have no chance to recover it after the weekly sync.

Second advantage is that using tar/dar will let you preserve ownership of the files.

And the third one - you will save bandwidth because you can compress the content.

Paweł Rumian
  • 1,636
  • 10
  • 23
  • It's true I just want a backup, not a working copy. But I find it hard to believe sending a tarball of the whole drive weekly instead of using rsync (which only copies changes to files) will save bandwidth. Also, if there isn't some way to tar directly over the network, I'd have to have a lot of space to make the tarball. – John Baber-Lucero Sep 13 '12 at 21:56
  • What about making differential backup? `dar` handles this just perfectly, holding a local database of files that were already packed, and in the next week it adds only the changed files. I advice you to read the dar homepage and learn more about backup strategies. rsync is really, really bad as a backup, because one day you will notice that you have deleted an important file more than a week ago. – Paweł Rumian Sep 14 '12 at 07:21
  • But if you rsync to something that is able to do snapshots like btrfs, zfs or LVM newer thin-provisionned snapshots, then you'll have the best of both world: incremental backup and instant access to the data (including as FS of a virtual machine or container as those snapshots can be cloned and be made writable). – Stéphane Chazelas Sep 14 '12 at 21:20
  • @gorkypl Now that I look at, I think `dar` is the right thing to do. Thanks! – John Baber-Lucero Sep 18 '12 at 13:14