I need to login as root, or at least get root privileges, in a cron triggered backup run. The straight way to do this would be the backup server making an ssh connection to the server to be backed up (this way because I want to avoid many servers being backed up in parallel and the backup server itself would be managing this diversity), via the rsync command which would be performing the backup's synchronization step.

I'm looking for alternatives to this in some form. I'd like to disallow direct root login to my ssh port (not 22).

One idea I have is to have the backup server initiate an ssh login as a non-root user, to either the actual source server, or to a server that can reach the source server ... and set up port forwarding. Over the forwarded port, then initiate the rsync that logs in as root via another port that allows direct root, but cannot be reached from the internet at all (because the border firewall doesn't include this port as allowed in).

FYI, these logins will be using ssh keys, not passwords. I do need to keep ownership metadata for files being backed up, so this is why I am using root. Also, rsync is needed to get the incremental updates to keep bandwidth usage lower (otherwise I could just transfer a tarball each day).

Anyone have any other ideas or comments, for security issues, based on experience doing things like this (backups, routine data replication, etc)?

I'm sure you've already considered using a complete backup solution like bacula or amanda? If those aren't acceptable it sounds like you've got a good solution figured out for your particular case.

To allow root logins you need to change the parameter, PermitRootLogin, to yes in `/etc/ssh/sshd_config`.

Regards,

Alunduil

Yeah, I've got dual port setups for sshd already, with one allowing root and the other not allowing root.

Although these other backup solutions have to-disk capability, they are still originally designed as tape backups. And that has always been painful for incrementals, especially with their sensitivity to file dates to determine the need to make a backup. And even so, they still seem to need periodic full backups and that just doesn't make sense when going to-disk and rsync is available which can do incrementals indefinitely.

I have my own program that "peels off" incrementals from the on-disk copy of the rsync target. After running rsync for the backup cycle from the place being backed up to the backup location, my program then runs at the backup location. Whatever changed since the last cycle is archived as an incremental. If a file was deleted by rsync, it will still be present in the reference tree kept by this program. It will then move that file over to the incremental tree for this cycle. Files that are newly created are just logged so it is known what date it appeared, so a restore for a previous date won't include it. It works in such a way that you can just remove the older increments any time you wish. For really long term archiving, copy those older increments to a couple tapes and remove the on-disk copy.

We're doing these backups to multiple sites, over the internet. So avoiding full backups is highly desired . A full backup of what we have backing up now takes about 20 hours over gigabit ethernet within the LAN. Imagine what it would take over a T3 link (and we don't even have that, yet).

Tapes for backup is so "2nd millennium"

Good analysis. Have you ever heard of rdiff-backup? It's built on rsync and only requires the first backup to be full and then does incrementals after that.

Regards,

Alunduil

Yes, I looked at rdiff-backup. It did the rsync part of it integrated, and that just didn't seem to be as flexible as I'd like. For example, in some cases I'd like to do the rsync every 2nd hour, but generate the delta just daily.

You can lock down the ssh access to only a certain username and domain. For example, root@remotesite.com. On top of that, using tcpwrapper you can specify which URL or host can have access to SSH; not to mention iptables rules that you can specify as well. You can also enable and disable all this with a script during a certain hour of the night to lock it down even further. Last, I would recommend to use squashfs filesystem for random access to the restores. It beats having to restore from a huge linear tar file.