The Problem: you want to back up an entire (Unix/Linux/BSD) system over the internet, and both the source and destination machines have dynamic IP addresses.

Mark I: rsync, using SSH for the transport, as a normal user

[dest]# rsync -av --delete user@source:/ /mnt/backup/

This doesn’t work because your normal user, user@source, will be unable to read some of the files on the source system, since they are readable only by root.

Mark II: rsync, using SSH for the transport, as root

[dest]# rsync -av --delete root@source:/ /mnt/backup/

If this works, then you are allowing root login over SSH on your source system, which is horribly insecure.

So a normal user account can’t read all the files we want to backup, but we don’t want to allow root to login over SSH...

Mark III: rsync, using the rsync server for the transport

If we use the rsync server (run "rsync --daemon") on the source system, we can run it as root and it can therefore read the entire filesystem.

/etc/rsyncd.conf on the source system:

[wholefs]
uid = 0
gid = 0
path = /
transfer logging = no
read only = yes
hosts allow = 1.2.3.4

Now assuming that the destination system is 1.2.3.4:

[dest]# rsync -av --delete source::wholefs/ /mnt/backup/

This is fairly secure because the rsync server is read-only, and because only 1.2.3.4 can access it.  However it does require opening port 873 on the source’s firewall.

The problem is that the destination machine is on a dynamic internet connection so tomorrow its IP might be 5.6.7.8.  We can use a DynDNS/ZoneEdit hostname and a client like Eponym to name our machines source.dyndns.org and dest.dyndns.org, and they’ll always point to the current IP; then set "hosts allow = dest.dyndns.org".  But the problem now is that rsync does a reverse lookup of the hostname’s IP to verify it; ideally it’d go dest.dyndns.org -> 1.2.3.4 -> dest.dyndns.org, but in reality it goes dest.dyndns.org -> 1.2.3.4 -> 1-2-3-4.foo.my-isp.com.  rsync (rightly) sees this as a potential security problem so it won’t allow access.

Mark IV: rsync, using the rsync server for the transport, tunnelled through SSH

Again, rsync server (run "rsync --daemon") on the source system, but "hosts allow" is now different:

/etc/rsyncd.conf on the source system:

[wholefs]
uid = 0
gid = 0
path = /
transfer logging = no
read only = yes
hosts allow = 127.0.0.1

Now from the destination system, log into the source system via SSH as your normal user account, and create an SSH tunnel with the -L option:

[dest]$ ssh -L 8873:localhost:873 user@source

Now we have a secure encrypted tunnel from port 8873 on dest to port 873 (the rsync daemon port) on source.

[dest]# rsync -av --delete --port 8873 localhost::wholefs/ /mnt/backup/

This setup is very secure because the rsync server only accepts connections from the local system (127.0.0.1), and because we don’t need to open port 873 in the source system’s firewall, since all the traffic is tunnelled through the SSH connection on port 22.

Final Notes

rsync can be run as a normal user on the client (dest) system, but in order to make an exact backup (preserving file permissions) it must be run as root.

In the rsync calls, I omitted any --exclude switches for the sake of brevity.  But in reality when backing up the root of a filesystem, you’ll probably want to:

--exclude /dev
(because device nodes are usually created dynamically)

--exclude /media
(exclude any USB memsticks, pendrives, etc)

--exclude /mnt
(exclude any mounted CDs, floppys, etc)

--exclude /proc
(because proc nodes are created dynamically)

--exclude /sys
(because sys nodes are usually created dynamically)

Please contact us with any questions or comments.