How often do we need to run verify?
- Thread starter tuxis
- Start date
that is actually not a trivial question to answer, but the most honest one is: as often as you can
the end-goal of verification is to catch errors like bit-rot, which makes the backup un-restorable (because we cannot rely on those chunks anymore) and due to the deduplcated nature, such errors are much more tragic than
normally, since if you do not know a chunk is corrupt, each backup done after will maybe reuse that corrupt chunk, thus make the backup unrestorable.
also even if you detect such a corrupt chunk, you have to make sure that there is at least one backup that verified ok or you have synced your backups to another location and can replace it
note that when a chunk corrupted it is a must to check for hardware errors like a broken disk/controller/cable/memory/etc.
in the future we will have some additional options for verify, such as 'only-unverified' and 'older that x days' so that you can have multiple schedules that fits your backup pattern
(e.g. daily all new unverified, and weekly all backups that are older that 14 days)
What happens if the backup cannot be verified?
this would not work for me; I currently need almost 2 hours for a verification
Last edited:
Hi @dcsapak ,
But if undelaying storage is zfs, then in this case could not be happend, or I am wrong?
Thx. anyway for PBS - is my best backup tool that I see it starting from '90s !
Good luck /Bafta!
Last edited:
Depends how much goes wrong. Some silent bit rot of data which does not get read can also go under the radar with ZFS, at least until the next scrub.
We save that in the manifest, so that it shows up prominently in the datastore content overview (in the future also in the Dashboard).
There are two things we're currently working on to improve verification behavior:
Firstly, send mails out on bad verifications, so that an admin is pro-actively notified about possible issues
Secondly, allow one to setup verification schedules which only verify not yet verified snapshots and/or those snapshots with an "outdated" verification result. This should allow one to cut down verification times by a lot, and as older snapshots are normally not as frequent as newer ones, due to pruning, so the re-verification of old snapshots should not affect as many as verifying the whole datastore does.