I've recently set up a headless server to back up a number of very large film & editing files.

I SSH into the server and - following some best practice guides I found around - I've tightened security so that the server auto logs me off after 5 minutes of inactivity.

This is now creating a bit of a headache as I try to sort and move those files.

Issuing mv file1 /new_directory/ can take +5 mins and so I'm often logged off half way through.

Where multiple files are involved I've come back to find that some files seem to have transferred and others (at a seemingly arbitrary cut off point... or roughly what I reckon a 5 min timeout might have allowed) have not.

So my questions are:

  1. When issuing a mv command, if it is cancelled whilst incomplete is there any risk of data loss? Might I be safer using cp?
  2. Is there any way that I could set a cp or mv command to go and then be sure that it will continue even after I've logged off or my ssh window has closed
  3. Is there a way to do other things whilst a mv or cp is taking place (and thus refresh my countdown timer)
  • 1
    Use screen. Run your commands in screen and they will continue to run even if you log out. rackaid.com/blog/linux-screen-tutorial-and-how-to – Panther May 7 '14 at 17:51
  • Interesting, not come across that before, so as per my example I'd do $ screen mv file1 /new_directory/ and it'd just run? – Huw May 7 '14 at 17:53
  • 1
    yes. And you can detach / reattach to the session, etc. ssh + screen go together like peas and carrots. – Panther May 7 '14 at 18:00

Don't log in as such. Instead, from your local machine, run

ssh user@server mv /path/to/source /path/to/dest

That should let you get around the problem.

On a more general note, I do believe you are being a bit paranoid here. Setting the idle time to 5 minutes and then facing this kind of issue seems silly. Just set it to something longer and avoid the problem.

As for your 1st question, mv will only delete the source files if the copy succeeded. As explained in info mv (emphasis mine):

It first uses some of the same code that's used by `cp -a' to copy the requested directories and files, then (assuming the copy succeeded) it removes the originals. If the copy fails, then the part that was copied to the destination partition is removed. If you were to copy three directories from one partition to another and the copy of the first directory succeeded, but the second didn't, the first would be left on the destination partition and the second and third would be left on the original partition.

  • Fantastic, thanks and very interesting to know I can run commands like that! And yes I might dial down the paranoia... but then... mebby that's just what they want me to do... ¬_¬ – Huw May 7 '14 at 18:29
  • For the record, this doesn't seem to work when Sudo is needed to move the files through permissions... but screen does work! – Huw May 7 '14 at 18:37
  • 1
    @Huw screeen or tmux should work yes, as should sudo if you use the -t option for ssh: ssh -t user@server sudo mv foo bar. You might also want to have a look at rsync which might help you greatly. – terdon May 7 '14 at 18:41
  • 1
    @Mathew you should make your own answer if you think there is a better way. – Mateo May 8 '14 at 2:41
  • For the benefit of others wanting an answer to the question posed here I wish to point out that the proposed solution does not fit into a practical workflow where you may want to execute a series of shell commands such as 'ls', 'cd', 'du' and so on. Furthermore an impression is given that the 'mv' command always copies files. This is not the case when moving files on the same file system. As others have mentioned, 'screen' and 'nohup' are better answers. Furthermore, for the task in hand, 'rsnapshot' is a better tool for making backups of video. – Mathew May 8 '14 at 2:47

It is highly recommended to do long-running admin tasks only with tmux or screen (or Xvnc if you need it graphically). This shields you from network disconnects and allows reconnect. You could also use mosh, which is robust against network outages.

If you do not care so much about continue the session after your command has terminated, you can also run it detached with nohup mv ... (optional ending with & to background it immediatelly). You then need to monitor its execution with ps. Some shells can detach a running program (disown or not kill them like zsh's setipt NO_HUP) or use a background starter like at or cron.

  • For the record using sudo screen has become my most common option for these situations. – Huw Feb 19 '15 at 11:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.