17

I have two machines, A and B. Machine A can ssh into B. A has a lot of free space. B's data is in a sort of risky situation. How do I back up all of B's data to A automatically. It does not have to be terribly frequent, but it should be hands free. Every time A boots up would be frequent enough. I hear sync can do this.

6 Answers 6

11

To do this daily in most Linux distros, you should be able to just put the rsync command (as per @guido's answer) in a script and put the script in the /etc/cron.daily directory. As long as anacron is installed (may not be by default) any missed cron.daily jobs will be caught up on the next time the machine boots (as well as being run at midnight if the machine is switched).

For the script you would just do:

#!/bin/sh
rsync -a user@serverB:/source/folder/ /destination_folder

You could add the -z (compression) option if the backup is over a slow(ish) connection or if you want to save bandwidth, but in my experience it will actually hurt performance with modern machines/networks.

If you want to keep of log of each backup, you could do something like:

#!/bin/sh
rsync -av user@serverB:/source/folder/ /destination_folder \
  >/var/log/backup_log 2>&1

Note for this to work as a cron job, you must have passwordless ssh set up for root on serverA to log into serverB. It must be the root account (ie keys in /root/.ssh) since cron.daily jobs are run as root.

6
  • Not necessarily if you use a public key and per user cronjobs.
    – Braiam
    Apr 5, 2014 at 22:54
  • @Braiam, anacron won't pick up per user cron jobs. Although you could always use su/sudo from the script to run rsync as a particular user. But note that the keys will be more securely held under /root.
    – Graeme
    Apr 5, 2014 at 23:01
  • 1
    if you want to use a cron job and ssh with root, it is much safer to restrict what root can do in the second machine in the authorized_keys file.
    – guido
    Apr 6, 2014 at 0:02
  • 1
    @guido, there is no requirement to log in as root on serverB just because you are root on serverA. @JennyD has already given suggestion about what to do here, but user could just be a normal user on machineB depending on what you are backing up.
    – Graeme
    Apr 6, 2014 at 9:50
  • 1
    Most likely your user doesn't have read access to the files on severB. If this is the case either you need to use a user who does or give the current user the correct permissions either by adding him to the correct groups or changing the permissions on the files. If you add a sample of the errors you are getting and the output of ls -l on some of the files to your question, then people can give further advice.
    – Graeme
    May 3, 2014 at 17:33
5

I would suggest using rdiff-backup. I use it now to make automatic incremental backups every night of my own data (two workstations, two servers and one account on someone else's server).

I used rsync earlier for this, but switched to rdiff-backup since it is more convenient, and it can make incremental backups of large files such as virtual machine disk images. rdiff-backup is a lot like my previous rsync backup scrips, but done right.

I have put a script file in /etc/cron.daily on the machine where the backup is stored, which starts rdiff-backup once every day early in the morning, and fetches the data from the remote machine.

4

In addition to all the previous answers, here's one that relies on SSH keys with restrictions on what can be done when logged in with that key.

On server A

On this one it's less important if you create a separate user or use one of your existing usernames, though if it were me I'd create a separate user. I will use the username bkpuser for both servers in my examples below.

When logged in bkpuser, create an SSH key without a password.

On server B

Enable PubkeyAuthentication in sshd_config.

Create the user bkpuser. Set a very complicated password, or disable password login for that user (exactly how you do that will depend on which unix and distro you're running). The point is the user should only log in with an SSH key. Make sure that bkpuser has read access to all directories and file you want to back up.

Copy the public part of the key created on A to ~bkpuser/.ssh/authorized_keys on B. Edit the to automagically run a command on connection. That command should not be a pointer to a shell script; instead insert the shell script into the key directly. Also include a limitation so that the key can only be used from server A and no other server. In the example below, I'm giving server A the IP address 10.1.2.3 and I'm assuming that the files I want to back up are all under /data.

from="10.1.2.3",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,command="cd /data;/usr/bin/tar -cf - *; /usr/bin/logger -t BACKUP -p daemon.info \"INFO: Backup-files on $HOST fetched from ${SSH_CLIENT%% *} by $USER\";" ssh-dss AA.....

On server A

If you are using one of the cron tabs that supports @reboot entries, add such an entry to bkpusers crontab with the command ssh -i ~bkpuser/.ssh/id_dsa serverB > backup.tar.gz. If it doesn't allow those, set it at any time you like - if it were my data, I'd probably do it daily.

2

Here is a complete solution for backing up server B to server A every day at 4am using SSH.

Create an automatic SSH connexion from server B to server A

ssh-keygen -t dsa -b 1024
ssh-copy-id -i ~/.ssh/id_dsa.pub "-p ssh_port root@server_a"

Create a backup script on server B

nano /root/backup

# !/bin/sh

# Variables loading
HOST="root@server_a"
PORT=22
DIR="/var/backups/server_b"

# Directories creating
ssh -p $PORT $HOST <<EOF
    mkdir -p $DIR/home
    logout
EOF

# Files backing up
rsync -aze "ssh -p $PORT" --delete /home/user $HOST:$DIR/home

chmod 744 /root/backup

Automate backup on server B

crontab -e

0 4 * * * /root/backup > /dev/null

For more details see pages Connect to SSH without entering a password on Linux and Backup a server on Debian or Ubuntu Linux.

1

You can use rsync for this (in kinda a reverse way):

serverA# rsync -avz user@serverB:/path-to-backup.tar.gz /var/backup

where:

-avz  archive, compress and be verbose
2
-1

The crux of the matter is how to do it automatically (no need for enter passwords):

  • start a screen or tmux session
  • execute eval $(ssh-agent)
  • add your key with ssh-add
  • flags for rsync export RSYNC_RSH="ssh -i ~/.ssh/id_rsa ..."
  • backup every 24h with while :; do rsync -av u@h:/p /local; sleep $[24*60*60]; done
8
  • +1 for the password-less ssh.
    – Graeme
    Apr 5, 2014 at 16:55
  • So I would put all of these in a start up script, right? Apr 5, 2014 at 19:59
  • 1
    I think here starts the "really important question" how much security is needed? Do it with passwords or without? This will only work if you 1) do it from B, suspend or hibernate A. It wont work if you turn A off. If you do without passwords then you will become a kind of "risky situation".
    – user55518
    Apr 5, 2014 at 20:35
  • There's no need to add RSYNC_SSH to search standard locations of SSH keys. Apr 5, 2014 at 21:30
  • 1
    I know that. You oversaw also the ... dots where you can add useful arguments. You also did not read my last comment where I mention the "really important question" thus I never ever would do it with passwordless keys. You'll also need to enable PubkeyAuthentication and nobody said it.
    – user55518
    Apr 5, 2014 at 22:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .