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.
Made by IO Bureau in Switzerland

Blog / RSS
Follow Twitter
Miscellanea Press kit
Company Imprint

Legal Terms