Continue SCP’ing file(s) after log out

The unix command scp is very useful for transferring files between two hosts over a secure connection, but sometimes you need to kick off an scp command that will take several hours to complete and you want to disconnect and go home.

Using "screen"

One approach is to use the screen command (available only on linux AFAIK) to start the initial transfer, then detach by pressing CTRL-A followed by d.

The command will continue to run even after you have logged out, and screen has the bonus advantage that you can subsequently log back in to the machine and re-connect to the command being run at any time to see how things are progressing.

Exmpale:

oralinux001> screen
 
$ scp linuxamd64_12c_database_1of2.zip oralinux002:/oracle01/staging
<CTRL-A>
d
[detached]
 
oralinux001 > screen -ls

There is a screen on:
14623.pts-0.oralinux001 (Detached)
1 Socket in /var/run/screen/S-oracle.

To reconnect to the session, just use the -r flag (remember to detach from the screen session again as above if you want to disonnect and log out)

screen -r 14623.pts-0.oralinux001

Using "nohup"

If the screen command is not available due to the version of linux/unix being used you may be able to use the nohup command to run the scp in the background. However it does require user equivalence to be configured (negating the need to enter a password) as well as creating a temporary script and a somewhat cryptic form of nohup.
  • Ensure that you have set up user equivalence between the two hosts. This is to remove the need to specify the password for the remote host on the terminal.
  • Now put your scp command in a script (in this case called copy.ksh) and be sure to specify the flags  -q (to disable the progress meter) and -B (to run in"batch!" mode).

#!/bin/ksh
scp -q -B linuxamd64_12c_database_1of2.zip oralinux002:/oracle01/staging

  • Finally, run the script using the follwoing nohup call:
chmod 700 copy.ksh
( nohup ./copy.ksh & ) &
To test that the connection survives a log out, you should immediately log out from the system where the command was issued, and log on to the destination system. Do an ls -l a few times to ensure that the size of the files being transferred are increasing. If the size is not increasing then the command was unsuccessful (and will be in a "zombie" state on the source server).