rsync failed - no such file or directory - script works since 8 years(!)

Question

Using Debian and Apache2 webserver:

I have a cron job, that makes a two different db_dumps, and then saves all files from the website (www) to adrive.com and also the db dump to a drive in a 2nd rsync command.

Since Feb 24 rsync command works does not work; it produces this error after it copied a few files (it does copy files, but then stops!):

rsync: rename "/home/user/dokumente/backup/.backup_mysql_autofill.sql.gz.NABXKv" -> "backup/backup_mysql_autofill.sql.gz": No such file or directory (2)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1196) [sender=3.1.2]

You need to know:

• At this stage it already copied part 1 of the DB_dump (800MB) plus the log file, it stops at the 2nd DB Dump.
• It produces the same error for tiny files (200-500 bytes) when doing the www rsync, it is not a matter of file size
• you see the . (dot) at the beginning of the filename? Is that normal?
• It always makes the error at exactly the same file when I repeat the shell script.
• When I remove the first DB file from the source, it also failes to copy this file. (both files are around 700mb, first is called backup_mysql.sq.gz and second backup_mysql_allgemein.sq.gz)

Now here comes the joke. rsync worked again for 2 nights this Monday and Tuesday, then the error came back last night. I never changed anything on the system or script before Monday or later.

So, I did not have a backup from Feb 24 Until March 2, when it suddenly worked again for March 2 and March 3 (the whole 8year old script just did the job)

Here is my rsync command:

BACK_USR="bodomalo@xxx.com"
BACK_SVR="rsync.adrive.com"
BACK_DIR="/opt/backup"
cd $BACK_DIR
rsync -avz -e 'ssh -i /root/.ssh/adrive.id' $BACK_DIR $BACK_USR@$BACK_SVR:dokumente

Any idea? Is there a timeout for rsync now? Of course the script needs several minutes (2-3?) to copy both files (1.5 GB).

Answer 1

The file that it's complaining about is a temporary rsync file which gets renamed to the final filename when that bit of the transfer is complete. It looks like the remote end might be having some odd things happening, try logging in with an interactive session when the copy fails to check the existence of the dokumente/backup directory and whether any dot files showing interrupted transfers are present.