I have to transfer large amounts of data (>80 GB) over ssh using rsync. Everything is working fine, but the DSL connection where the backup data is sent from will drop once every 24h for up to 3 minutes (switching providers is not an option).

How do I:

  1. Automatically restart the transfer when the connection is back up?

  2. Make sure there are not by accident two rsync commands running at the same time?

  • Can't you check the return code? while ./run_script; do echo "Retrying..."; done; echo "Done." Make sure run_script returns 0 on success.
    – Kerrek SB
    Commented Jun 27, 2011 at 11:28
  • Possible duplicate of serverfault.com/q/98745.
    – tanius
    Commented Jul 26, 2015 at 7:28
  • Some useful info here - I just want to add that one way of getting round the repeated asking for password problem is to use the 'sshpass' command. Usually this needs to be installed with apt-get etc. Commented Oct 2, 2017 at 9:30
  • serverfault.com/q/98745 is asking to restart rsync for any kind of error, thus is not a duplicate. One should be able to know the exact cause of failure (i.e. when the remote-shell command dies), but the exit values given in the rsync(1) man page are not detailed enough. As the feature would be best in rsync itself (in particular to avoid some overhead, if allowed by its protocol), I've opened rsync should be able to automatically restart the transfer when the remote shell command dies.
    – vinc17
    Commented Dec 15, 2021 at 20:26

5 Answers 5


The following should be helpful:


while [ 1 ]
    rsync -avz --timeout=60 --partial source dest
    if [ "$?" = "0" ] ; then
        echo "rsync completed normally"
        echo "Rsync failure. Backing off and retrying..."
        sleep 180

When the connection dies, rsync will quit with a non-zero exit code. This script simply keeps re-running rsync, letting it continue until the synchronisation completes normally.

  • 1
    Thanks, I'm trying this now... but should this: if [ "$?" = "0" ] not be: if [ "$?" == "0" ] (comparision operator)?
    – Andreas
    Commented Jun 27, 2011 at 12:55
  • 1
    No, in bash "=" is string equality (one of the many things that makes it confusing, I think!)
    – Peter
    Commented Jun 27, 2011 at 15:11
  • 6
    == is alias for = :D
    – bbaja42
    Commented Jun 27, 2011 at 16:27
  • 8
    Ah, good to know. bash will never cease to amaze/horrify me :-P
    – Peter
    Commented Jun 28, 2011 at 23:32
  • 2
    Late to the party, however for posterity: A) just use: if rsync -avz --partial source dest; then ... B) if you want to compare integral values if use double parenthesis for arithmetic expansion: if (( $? = 0 )) then;
    – user18402
    Commented Mar 14, 2014 at 4:44

This does much the same as Peter's answer, but gives the user the option of which remote file he wants, and where he wants to save it (as well as conducting the rsync over ssh). Replace the USER and HOST with your username and host respectively.

echo -e "Please enter the full (escaped) file path:"
read -r path
echo "Path: $path"
echo -e "Enter the destination:"
read -r dst
echo "Destination: $dst"
while [ 1 ]
    rsync --progress --partial --append -vz -e ssh "USER@HOST:$path" $dst
    if [ "$?" = "0" ] ; then
        echo "rsync completed normally"
        echo "rsync failure. Retrying in a minute..."
        sleep 60

The rsync options used here enable the progress stats during transfer, the saving of partial files upon unexpected failure, and the ability to append to partially completed files upon resume. The -v option increases verbosity, the -z option enables compression (good for a slow connection, but requires more cpu power on both ends), and the -e option enables us to conduct this transfer over ssh (encryption is always good).

Note: Use this only if you have public key login enabled with your ssh, otherwise it will ask you for a password when it restarts (killing all functionality of the script).


A quick and dirty way to do this when you don't feel like opening up an editor:

while ( ! rsync -avzP <source> <dest> ); do sleep 1; done
-a  archive mode
-v  increase verbosity
-z  compress file data during the transfer
-P  same as --partial --progress
  • 3
    until rsync <...>; do sleep 60; done
    – Lamp
    Commented May 6, 2021 at 21:03
  • 2
    A quick and clean way. The other answers' scripts do the exact same thing with unnecessary verbosity.
    – Lamp
    Commented May 6, 2021 at 21:08
  • until rsync ...; do true; done works if you don't want a delay between attempts.
    – ki9
    Commented Sep 29, 2022 at 14:48

supervisor daemon (a process control manager) could work very well after creating rsa certificates of both sides, with a similar configuration as follows: (/etc/supervisor/ supervisord.conf is the configuration file path on debian based systems )

command=rsync -avz --progress [email protected]:/destination /backup-path

The @Peter's answer seems be very useful, but for me it was important to use --update option. After connection has been resumed, without --update rsync was trying to sync all from the very begining. With --update, files that already exists are skipped.

rsync --partial --update --progress -r [SOURCE] [DESTINATION]

  • 4
    --update skips files that already exists... Including those that have not been completely copied to the target. I think it goes against most use cases.
    – durum
    Commented Nov 22, 2017 at 17:20
  • @durum it's not true at least on rsync 3.1.2 . after interrupted transfer I see it works properly on the same file. I used rsync over ssh, the command was rsync --partial --update file1 remotehost:file1. after transferring 15% I broke the transfer (kill -KILL).
    – filiprem
    Commented Jan 17, 2019 at 10:24
  • @filiprem rsync was sort of trying to sync everything again (depending on the delta algo) because the mod times are different since the time isn't being synced via the --times option. Not sure why it's working properly in this case, --update should be skipping the partial file unless in your case the source mod-time is more recent?
    – Rob Olmos
    Commented Jan 10, 2022 at 23:18

You must log in to answer this question.