Knowledgebase: How Stuff Works
About Verify...
Posted by Andre Kuehnemund on 14 May 2021 0:22
A verify job, run immediately after an archive
or sometime later (through the P5 CLI), will honour the
ArchivePlan setup w.r.t the type of verify checking: at the
moment we offer checksum or file-comparisons verifies.

The checksum verify works as follows:

During the archive, the stream that we generate
while reading the file (see below *) will be checksummed
and the checksum (and its type) will be appended to the
data saved on media (tape, disk).
At the time of verification, we will read the stream back
while calculating the stream checksum and at the end
we will compare the result with the checksum appended
to the end of the data stream.
The purpose of this check is to make sure that we can
read from the media what we have written to the media.
It is quite fast and it does not require access to the
original file.

The file-comparison verify work as follows:

During the archive, the stream that we generate
while reading the file (see below *) will be checksummed
and the checksum (and its type) will be appended to the
data saved on media (tape, disk).
At the time of verification, we will read the stream back
and we will, at the same time, read the file as if we
did during the archive. Both resulting streams will
be compared byte-by-byte.
The purpose of this check is to make sure that we can
read the same data from media that we have read from
the file. This is quite complicated setup, as we have
to do it on the client where the file comes from, so
it requires the transfer of the whole file over the
network and back to the originating client.

*)

Each data-stream that we generate while reading the
file (either during archive or file-comparisons verify)
is a COMPLEX setup consisting of:

a. data-fork
b. any optional user and/or resource forks (Mac, Windows)
c. any optional ACL's
d. any optional extended attributes
e. finder-info record (Mac only)
f. file-id and private fileserver records (Helios fileserver)
g. private fileserver records (Xinet)
e. file modification/create/change times

IF ANY OF THE ABOVE ITEMS CHANGE AFTER WE HAVE WRITTEN THE
FILE TO THE MEDIA, the file-comparison verify will fail.
The checksum verify is not affected.

It is practically impossible for an end-user to figure out what
has changed to the file, as some of those information above
are purely binary items and cannot be (easily) obtained by
user-land utilities.

What we COULD have done is to omit all items on the above list
except the a. In that case, we would effectively reduce validity
of the verify check but allow user to easily understand/inspect
what did eventually change if the file-comparison verify failed.
We did not do that on purpose, because it would defeat the whole
idea of the verify process or at least reduce its quality.
Offering both of the options would make the software and the
setup more complex, and we did not want to do that either.
(0 vote(s))
Helpful
Not helpful

Comments (0)
Post a new comment
 
 
Full Name:
Email:
Comments:
CAPTCHA Verification 
 
Please enter the text you see in the image into the textbox below (we use this to prevent automated submissions).