Is CBT worth it?


Author
Message
dbminter
dbminter
Most Valuable Professional
Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)
Group: Forum Members
Posts: 2.9K, Visits: 27K
I hate to be that guy, but I've begun questioning whether enabling CBT is worth it.


The problem is the frequency with which the CBT indexing keeps changing, requiring all new indexes be built for the next Incremental back after update.  I've got one nearly full 500 GB partition that gets files added to it occasionally.  Whenever the CBT indexing gets updated, it takes 1 hour for the next Incremental after it after the consolidation of the indexing is performed again.


So, I have to question the validity of CBT.  You save a little time but is it being eaten up by the increased re-indexing time for CBT updates?   Since this is like the 2nd time the indexing has been changed in recent updates, the time for Incrementals has been adding up.


And there are other considerations to take with CBT updates.  For instance, some times bugs are introduced in CBT which render that it doesn't work.  Some of these bugs sometime render Reflect nonworking and some have even BSOD'ed Windows.  So, also for that reason, is it practical to enable CBT?  I liked it when initially introduced, but I've begun to question whether to use it.  I know some (JP, I believe, doesn't.) don't enable it.  And, with the increased time it's taking for the re-indexing that has been occurring lately, coupled with the possibilities that CBT bugs can introduce, is the marginally less time for Incrementals worth it?


I guess it depends on how many Incrementals you take and how large the source backups are.  I take a lot of Incremental backups before updating software, but the amount generally backed up is relatively unchanged, resulting in smaller backup sets.  So, it may not be in my better interests to enable CBT anymore and I may change that in the future.

jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)
Group: Forum Members
Posts: 10K, Visits: 65K
Interesting timing, because I was just talking with another forum member about this, which proved educational for me.

First off, it's important to establish CBT's value proposition.  As has been discussed, when circumstances allow CBT to be used, it eliminates the "Looking for changes" step that would otherwise occur when capturing Differentials and Incrementals.  However, Froggie pointed out to me that it also offers another performance benefit that I did not previously know about, but which is now alluded to in the CBT KB article here (though I don't remember it always being there).  As noted there, CBT claims a performance improvement for file systems that contain large files.  Apparently that's because when the traditional, non-CBT "Looking for changes" method is used, during the image capture process Reflect still has to read the changed files to figure out which specific blocks within them have changed and therefore which blocks need to be backed up.  When CBT is used, Reflect doesn't have to read the entire file to figure that out; CBT already has that recorded.  Of course in many image backup scenarios, the write speed of the destination is typically slower than the read speed of the source, but if you have very large files (such as VHDX files, as noted in the KB), then not having to read through that entire file to figure out which areas have changed can apparently end up saving you quite a bit of time.

That said, I personally do not use CBT.  I admittedly made that decision when I thought the only advantage was eliminating the "Looking for changes" step and had no idea about that second advantage.  But even now that I know about it, I don't think my use cases are a good fit for it.  None of the backup jobs I support involve partitions with predominantly large files, and the backups already take a few hours and run overnight, so if a backup takes a bit longer because CBT isn't available, that doesn't really matter.  By comparison, some of the systems I support are mission-critical, so stability is paramount, and as you say, CBT has been a bit of a problem child over its lifetime.  And even when it's working properly, any time a Reflect update includes a CBT update, you'll need to restart your system, whereas you might not need to restart if you didn't have CBT installed.

On the other hand, I've heard from other users who couldn't imagine giving up CBT.  One of them captures Incremental backups every 15 minutes, so the "Looking for changes" step as a percentage of overall job time is more significant there.  And of course some people certainly ARE backing up data partitions that contain a lot of large files, so they would benefit too

Edited 28 August 2019 9:30 PM by jphughan
GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...




Reading This Topic

Login

Explore
Messages
Mentions
Search