Oct 30, 2018
Delta copying relies on block hashes saved from the last file update to detect which parts of the file changed since then and copy over only these modified blocks.
This means that the actual *delta* part of the copying kicks in only on the *second* update, because when we are copying file for the first time, we don't have the block hashes yet. Once the file is copied, we have the hashes and all set to do the delta updating.
This inability to detect block changes on the *first* run is not a big deal. Most of the times we are adding new files to a backup and these need to be copied in full anyway, so we do just that and initialize their delta state at the same time.
However these is a case when this creates a slight problem.
That's the case when we already have a backup copy in place and this copy was *not* created by Bvckup 2. That is, when Bvckup 2 is used to take over an existing backup that was created by some other means.
A change to any file will cause the file to be re-copied in full, because there would exist no delta state for it yet. This is needlessly wasteful.
When we have a pre-existing backup copy, it's possible to have the program initialize files' delta state and prepare them for delta-copying starting with their very first update.
This is referred to as "delta state pre-computation" or "delta pre-comp".
More formally, the pre-comp is an option that forces the backup engine to initialize block hashes for all files in the backup that qualify for delta copying but not yet have the delta state.
The earliest release that supports delta pre-comp is 79.13.
Oct 30, 2018
Enabling the pre-comp
Delta precomp is off by default. It can be enabled with the following override in the job's config:
for details on how to find and edit job's configuration file.
Once enabled, the precomp will be executed for all files larger than the delta-copying threshold, which is currently 64MB. You will also see "Pre-computing delta state" entries in the log for affected files -