Linux – Turning off cp (copy) command’s interactive mode (cp : overwrite ?)

There is a wput utility which works the other way from the more known wget.
It can be used to upload your files at a controlled rate.

−−limit−rate=RATE

If you don’t want Wput to eat up all available bandwidth, specify this flag. RATE is a numeric value. The units ’K’ (for KiB) and ’M’ (for MiB) are understood. The upload rate is limited on average, meaning that if you limit the rate to 10K and Wput was just able to send with 5K for the first seconds, it will send (if possible) afterwards more than 10K until the average rate of 10K is fulfilled.

About trickle,

trickle is a userspace bandwidth manager. Currently, trickle supports the shaping of any SOCK_STREAM (see socket(2)) connection established via the socket(2) interface. Furthermore, trickle will not work with statically linked executables, nor with setuid(2) executables.

As far as I know, the "file-has-vanished" condition is not a fatal error condition for rsync, and the process should continue just fine. Are you saying that rsync is halting upon reporting the "vanished file" messages?

If you are backing up a live filesystem, it is always possible to get the "vanished" message from rsync. Between the time that rsync adds a file to its transfer list and the time that rsync actually gets around to reading it, a file can "vanish" for any number of legitimate reasons (e.g. a temporary lock file was removed, or a file was renamed). Note that some applications work around limitations in NFS file locking by creating and removing hidden lock files, and it's possible that rsync may be seeing some of those.

I would suggest to keep your source filesystem as quiescent as possible while it is being backed up. Ideally, no one other than the backup process should be accessing it, but I realize that that may not be feasible. If your source filesystem is on an LVM logical volume, then you could consider creating a read-only snapshot to use as your backup source.