Are there any technical reasons why the client can’t start transferring files as soon as the first file is indexed?
I’m just starting to deploy the CBT client at places so hopefully won’t see things indexing so much anymore but I’ve never liked the constant indexing since it seems to take a long time and delays the backup. Since we’re doing all backups over the internet the transfer takes a considerable amount of time and it seems time spent indexing could also be used to transfer files.
It’s probably the hashing that takes so long, isn’t it? Maybe that could be done simultaneously to the backup itself.
CBT will only speed up the hashing if the server is in “treehash” mode, which it is if it is not a 1.x upgrade installation (the problem being that all the hashes change) and CBT for file backups is only implemented with the 2.1.x beta currently.
That brings up another question although sounds like it doesn’t matter if CBT is being used. I assume you hash everything in a directory that’s going to be backed up? I understand this is necessary for some cases but I have a lot of cases with a shared folder for a company that will typically have several hundred GB worth of data, most of which won’t be changed after putting it there. I’ve seen your blog post on using the last modified time stamp and why it doesn’t work for incremental backups however 90%+ of the data we back up would probably be fine using the last modified date with the major exceptions being Exchange and SQL. Would it be possible to have a setting for each folder included in the backup to specify relying on the hash vs last modified date to determine if the file changed? I assume last modified would be significantly faster.
I didn’t realize CBT wouldn’t be used with the 2.x branch. I have a pretty old install, I’ll probably just start a new setup with 2.1.x, my installs getting a bit old now.