When managing extended file transfers or computational tasks on a remote server, foreground execution frequently encounters session timeouts or network drops. If a command is already running in the foreground and needs to be moved to the background without restarting, Linux job control provides a reliable workflow to achieve persistent execution.

Step 1: Initiate and Suspend the Task

Execute your command as you normally would. To prevent bandwidth saturation during a large data transfer, you can throttle the throughput using the -l flag:

scp -l 15000 production_db_dump.sql 10.20.30.40:/data/replicas/

Once authentication completes and the transfer begins, press Ctrl + Z to suspend the active process. The shell will assign a job idenitfier and return a Stopped status.

Step 2: Resume Execution in the Background

Inspect the current job queue to verify the suspended task:

$ jobs
[1]+  Stopped                 scp -l 15000 production_db_dump.sql 10.20.30.40:/data/replicas/

Resume the operation in the background by referencing its job ID with bg:

$ bg %1
[1]+ scp -l 15000 production_db_dump.sql 10.20.30.40:/data/replicas/ &

Querying jobs again confirms the process is now active and running asynchronously.

Step 3: Decouple from the Shell Session

While the process is technically in the background, it remains a child of the current terminal session. Closing the SSH client or losing network connectivity will trigger a SIGHUP (hangup) signal, terminating the task. To permanantly detach it, apply disown:

$ disown -h %1

The -h option marks the job so it ignores SIGHUP upon shell exit. You can also use -a to detach all jobs or -r to detach only actively running ones. After execution, the job disappears from the jobs list but continues operating independently.

Step 4: Confirm Persistence After Logout

You may safely close the terminal or terminate the session. To verify the process survived disconnection and was adopted by the init system, filter the process table:

$ ps -ef | grep scp
root     28451     1  0 14:22 ?        00:00:05 scp -l 15000 production_db_dump.sql 10.20.30.40:/data/replicas/

The parent process ID (PPID) shifting to 1 confirms the task is fully decoupled from the original shell environment.

Preventive Execution with nohup

For scenarios where you know upfront that a process must survive terminal closure, combining nohup with background execution eliminates the need for post-hoc detachment:

$ nohup scp -l 15000 production_db_dump.sql 10.20.30.40:/data/replicas/ &> transfer.log &

This syntax suppresses hangup signals at launch, redirects standard output and error streams to a log file, and immediately places the command in the background.