Incremental Backup

[dnanian]

I really do understand what you're saying. But, given what I'm seeing in the log, it looks like the same files were copied for both runs, and in each case you provided only 900 files were copied out of the total.

I can't tell how large they were, but the total size of all files examined was 50G.

Regardless of the size of the files, we're still going to be traversing the entire directory structure. This might be doing enough I/O across your very slow link that it's going to make the whole backup go slowly. (You can't really think of it as up/down, because we can't really tell what the OS is going to do when traversing/statting the various files, sparse image, etc.)

To compare them more exactly I'd need to see the entire log, not just two little snippets from what look to be nearly identical partial runs, neither of which was a full copy. You can send that to support, if you'd like, after you do the next smart update.

[edh]

I started a new smart backup right after the previous one finished (which was after six hours). The new backup took even longer; eight hours. Between these backups there were no big files that had changed status, which I checked with find / -ctime -540 (ie. using a nine hours interval). The files that had changed were predominantly /Network files (for about 500 machines). There is not enough in the log to fare on, especially as you mention, its figures seem to be misleading. I'm mystified. Eduard.

[dnanian]

The count isn't misleading, only the total size...

I don't know, Eduard. Have you tried the backup to a local drive to see if it's fast?