is an upcoming major Bvckup 2 update and it is now starting to enter the
First up is a new and important feature - the
Write verification does exactly what its name implies - for every data block that the program writes out, it reads the block back and checks that it remained intact.
This process helps to safeguard against two types of problems.
1. Data corruption on the way to the device
This may happen due to the software and firmware bugs, memory bit flips (both in the machine's own RAM and in the controller/device memory) and transport errors if going over the network.
risk of such corruption is exceedingly small, but the backups tend to push a lot of data around, so the
risk may grow with time to the non-negligible levels.
2. Latent storage media problems
Reading data back effectively acts as a form of
and helps flushing any pending issues with the storage media.
If the media is OK, the read-back will just complete nominally.
If the media is dying, i.e. if the data can still be read, but only after retrying or via the
sector ECC recovery
, then we will get our data back
trigger the sector relocation, avoiding potential data loss if the media were to degrade further.
If the media is dead, then we'll won't have our data back,
we'll learn about the problem
rather than later.
How it works
The somewhat less obvious aspect of write verification is that it needs to bypass the file system cache and to try and read the data from actual the device.
The program arranges for this by opening the target file for the second time and requesting a so-called
read access to it.
This doesn't prevent writes from being cached, but ensures that reads are served from the disk.
Going around the cache automatically means that the copying becomes slower.
The degradation is in part mitigated by the
and it's further reduced by the
if it's in effect, but there
a slow down. No miracle there.
How it looks
Once enabled, the write verification setting will show up in the
It will also be mentioned in the completion statement for all non-empty files:
Finally, if a write verification fails, the log will show the following:
Verification failures are
, the program will not retrying the operation in an attempt to correct the problem.
This is by design to keep the issue on the surface and to force investigating it.
In prerelease builds the write verification can be enabled for a job via the right-click menu as shown in the opening screenshot.
In production builds it's likely to be the same, except the Preview submenu will have a different name and it will be visible only if the Ctrl held down.
You can get a prerelease build by switching your installation to the "preview" update channel as described
*/ ?> /* ?>