Release 82 is an upcoming major Bvckup 2 update and it is now
starting to enter the preview update
channel.
First up is a new and important feature - the write verification.
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.
The relative risk of such corruption is exceedingly small,
but the backups tend to push a lot of data around, so the
absolute risk may grow with time to the non-negligible levels.
2. Latent storage media problems
Reading data back effectively acts as a form of
scrubbing
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 and
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,
but we'll learn about the problem now 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
unbuffered 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
asynchronous nature
of the
ultra copier
and it's further reduced by the
delta copying
if it's in effect, but there is a slow down.
No miracle there.
How it looks
Once enabled, the write verification setting will show
up in the Configuration section:
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 non-retryable, 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
here.
First up is a new and important feature - the write verification.
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.The relative risk of such corruption is exceedingly small, but the backups tend to push a lot of data around, so the absolute risk may grow with time to the non-negligible levels.
2. Latent storage media problems
Reading data back effectively acts as a form of scrubbing 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 and 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, but we'll learn about the problem now 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 unbuffered 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 asynchronous nature of the ultra copier and it's further reduced by the delta copying if it's in effect, but there is a slow down. No miracle there.
How it looks
Once enabled, the write verification setting will show up in the Configuration section: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 here.