I work primarily with UNIX and Linux machines and scp is my main choice to transfer files with. It is both convenient, short and secure.


scp localfile user@remotecomputer:/path/to/target/dir

Recently I was transferring an 8GB file and due to a network issue, the transfer was interrupted at nearly 40%.

I have learned over the years that there is often little that can be done to prevent such interruptions. Of course, this can be both frustrating and time-consuming, but there is a quick fix. Although such disruptions can’t be prevented, there is a fast and easy way to resume them. Resuming has relatively few system requirements, and can save a lot of time and hassle when transferring large files.

I found a solution at joen.dk ,which uses rsync to resume the transfer:

rsync --partial --progress --rsh=ssh local_file host:remote_file

NOTE: The syntax is ssh source_file target_file. So in the above example I am transferring a local file to a remote server. A few people did not pay close attention and switched the source and destination files and resulted in overwriting the original.

Now we can improve this slightly by shortening the above command. We can substitute –rsh=ssh with -e ssh, and use -P instead of –partial –progress. Also, you can add user@host if you need to specify a different remote shell user:

rsync -P -e ssh local_file user@host:remote_file

This above example will work with any file that was partially transferred. How the transfer was started does not really matter. It could be through scp, nc or even ftp. After you execute the above command it will take rsync a little time to verify the previously downloaded part before it continues with the rest. Be patient, depending on your network speed rsync could take some time to go through what you have already transferred. Of course this is much faster than if you were to start the download all over again and it shows you the progress in percentages.

Keep in mind that there have to be a couple of requirements in place in order to resume the file transfer with rsync:

1. You should have remote shell access.
2. The remote machine should have rsync installed. Since rsync is by default on most Linux distributions that generally should not be an issue.

How to Resume Partial File Transfers
Tagged on:     

10 thoughts on “How to Resume Partial File Transfers

  • November 18, 2010 at 6:09 pm

    Great tip, though I think you’ve reversed the source/destination of the rsync example.

  • December 22, 2011 at 11:21 am

    Its not reversed, the example synchronizing from a remote computer to a local computer.

  • February 11, 2012 at 11:35 am

    yes but shouldnt the order be
    ‘ssh source dest’ and ‘rsync source dest’.
    your ssh example is inconsistent with your rsync example

  • February 12, 2012 at 11:01 am

    Great tip, thanks!
    You could add that if the person is using a non-standard ssh port he should add it like this:

    rsync -P -e “ssh -p $portNumber” user@host:remote_file local_file

    Including the quotation marks.

  • March 1, 2012 at 7:24 pm

    I thought of coming back here and sharing this info:

    If you wish resume downloading of a whole folder with several files, instead of a single file, do this:

    rsync -P -avz -e ssh user@host:remote_folder/ local_folder/

    or if you’re using a port different from 22:

    rsync -P -avz -e “ssh -p $portNumber” user@host:remote_folder/ local_folder/

    ‘-a’ there is the crucial parameter to be added, ‘-v’ and ‘-z’ are optional. Check man rsync for further info.


  • April 12, 2012 at 1:24 pm

    either the scp example should reverse the source and dest or you should specify which machine you are logged into for each command. clearly in the scp example you are copying a local file to a remote machine, and in the rsync example you appear to be doing the reverse. one would assume you are logged into different machines in each case if one knows the syntax of the commands. but it might not be obvious.

  • October 12, 2012 at 11:35 am

    Please watch out that you get the source and destination right. rsync args order is source then desitnation. The examples above assume you’re copying from remote to local, which I like an idiot copied blindly when I was intending the reverse, resulting in truncating my local (full) file.

  • February 28, 2017 at 8:34 pm

    I just did the same thing. DUH

  • February 21, 2018 at 5:09 am

    Dimitar you’ve been told more than once in the above comments that your example is very poor..

    Please fix up the rsync example to match the scp example ie. resume copy from LOCAL to DESTINATION.

    Or stop writing shitty tutorials

  • October 1, 2018 at 9:42 am


Leave a Reply

Your email address will not be published. Required fields are marked *