Optimization of verify option and some questions


Author
Message
Andreas K
Andreas K
New Member
New Member (24 reputation)New Member (24 reputation)New Member (24 reputation)New Member (24 reputation)New Member (24 reputation)New Member (24 reputation)New Member (24 reputation)New Member (24 reputation)New Member (24 reputation)
Group: Forum Members
Posts: 19, Visits: 34
Could the verify operation eventually be optimized in terms of speed and functionality.

Szenario: I needed to replace my 512GB SSD with a 1TB SSD
- I have a G/F/S backup of my Windows SSD

The objective from my personal experience is this:
1. check whether the file integrity of the last backup is ok, otherwise it makes no sense to restore using this image
2. copy the disk image to the new bigger SSD (thankfully macrium allows here to resize the partition, because I have a larger SSD)
3. validate data written to new SSD, whether they match with the disk image

to point 1 a question:
When restoring the latest backup there is a tick box "validate image before restore".
It would be interesting for me why it takes much time.
Do you check the integrity of the archive thoroughly and re-calculate / check the checksum of each file in the disk image to ensure, that all data is valid ?

to point 2 a thanks and a question for a little enhancement:
its nice to be able to resize the partition on the target disk
Feature request: for SSDs and overprovisioning it would be nice if you could present the unpartitioned space at the end of the disk also as percentag value.
Would be nice if a user wants to choose other values like i.e. 10% which is easier to calculate in memory.

now the most important point 3. I think here is a real gap / something important missing:
I am missing here an option to validate what has been written to disk agains the backup image. I think this is required to ensure that neither a transmission error via SATA occurred or that maybe data has been written to a bogus block on the medium, be it hard disk or SSD.
I tried to workaround this by using the validate disk image function of Macrium.
This took very long again AND I fear that this didn't compare backup image with content on the new SSD.
So there seems to be something missing.

Proposal: to speed-up this verification of data written to disk I propose, that a fair amount of data will be read directly from disk as it has been written.
Because then you still have the data in memory from the disk image which is being read.
I think this might be quicker than doing a completely separate validation between backup image and what was written to disk,
which would require again, that the disk image data becomes decompressed ..
I think this could safe i/o and CPU time if the verification would be directly done while writing to the disk.
But maybe in big enough chunks, that it works efficient...

What do you think about this ?

Nick
Nick
Macrium Representative
Macrium Representative (2.5K reputation)Macrium Representative (2.5K reputation)Macrium Representative (2.5K reputation)Macrium Representative (2.5K reputation)Macrium Representative (2.5K reputation)Macrium Representative (2.5K reputation)Macrium Representative (2.5K reputation)Macrium Representative (2.5K reputation)Macrium Representative (2.5K reputation)
Group: Administrators
Posts: 1.4K, Visits: 7.9K
Andreas K - 1 December 2017 12:05 PM
Could the verify operation eventually be optimized in terms of speed and functionality.

Szenario: I needed to replace my 512GB SSD with a 1TB SSD
- I have a G/F/S backup of my Windows SSD

The objective from my personal experience is this:
1. check whether the file integrity of the last backup is ok, otherwise it makes no sense to restore using this image
2. copy the disk image to the new bigger SSD (thankfully macrium allows here to resize the partition, because I have a larger SSD)
3. validate data written to new SSD, whether they match with the disk image

to point 1 a question:
When restoring the latest backup there is a tick box "validate image before restore".
It would be interesting for me why it takes much time.
Do you check the integrity of the archive thoroughly and re-calculate / check the checksum of each file in the disk image to ensure, that all data is valid ?

to point 2 a thanks and a question for a little enhancement:
its nice to be able to resize the partition on the target disk
Feature request: for SSDs and overprovisioning it would be nice if you could present the unpartitioned space at the end of the disk also as percentag value.
Would be nice if a user wants to choose other values like i.e. 10% which is easier to calculate in memory.

now the most important point 3. I think here is a real gap / something important missing:
I am missing here an option to validate what has been written to disk agains the backup image. I think this is required to ensure that neither a transmission error via SATA occurred or that maybe data has been written to a bogus block on the medium, be it hard disk or SSD.
I tried to workaround this by using the validate disk image function of Macrium.
This took very long again AND I fear that this didn't compare backup image with content on the new SSD.
So there seems to be something missing.

Proposal: to speed-up this verification of data written to disk I propose, that a fair amount of data will be read directly from disk as it has been written.
Because then you still have the data in memory from the disk image which is being read.
I think this might be quicker than doing a completely separate validation between backup image and what was written to disk,
which would require again, that the disk image data becomes decompressed ..
I think this could safe i/o and CPU time if the verification would be directly done while writing to the disk.
But maybe in big enough chunks, that it works efficient...

What do you think about this ?

Thanks for posting. Please see this KB article that explains how verification works:

https://knowledgebase.macrium.com/display/KNOW7/_HOW_VERIFY_WORKS

Kind Regards

Nick - Macrium Support

Andreas K
Andreas K
New Member
New Member (24 reputation)New Member (24 reputation)New Member (24 reputation)New Member (24 reputation)New Member (24 reputation)New Member (24 reputation)New Member (24 reputation)New Member (24 reputation)New Member (24 reputation)
Group: Forum Members
Posts: 19, Visits: 34
Thanks for the link. Interesting to read.

But whats more important ... I want to make you aware of, that there is something important missing in your product when it comes to data recovery.

I agree that its important to check the integrity of the backup file before restoring anything to disk.
This is possible with Macrium, so far so nice.

But whats missing is a final check, whether the recovered data arrived in good shape on the destination disk/partition.
So it should be possible to have the option that the recovered data of disk is finally checked against the backup file.

Only by this you can be sure, that no transmission error occurred and no bit flipped during transmission.


Nick
Nick
Macrium Representative
Macrium Representative (2.5K reputation)Macrium Representative (2.5K reputation)Macrium Representative (2.5K reputation)Macrium Representative (2.5K reputation)Macrium Representative (2.5K reputation)Macrium Representative (2.5K reputation)Macrium Representative (2.5K reputation)Macrium Representative (2.5K reputation)Macrium Representative (2.5K reputation)
Group: Administrators
Posts: 1.4K, Visits: 7.9K
Andreas K - 3 December 2017 3:36 PM
Thanks for the link. Interesting to read.

But whats more important ... I want to make you aware of, that there is something important missing in your product when it comes to data recovery.

I agree that its important to check the integrity of the backup file before restoring anything to disk.
This is possible with Macrium, so far so nice.

But whats missing is a final check, whether the recovered data arrived in good shape on the destination disk/partition.
So it should be possible to have the option that the recovered data of disk is finally checked against the backup file.

Only by this you can be sure, that no transmission error occurred and no bit flipped during transmission.


Apologies, I missed this when reading your initial post.  

Verifying the last part of the data transfer, i.e, RAM to internal disk is in effect verifying the integrity of your system, not just the restore. If it isn't possible to accurately write from RAM to disk without corruption then there is a serious problem that would undoubtedly prevent Windows from running normally at any time. I'm not convinced that image restore is the time for checking system integrity like this, and if this really is a concern then it's possibly wise to check your system memory regularly. 

Kind Regards

Nick - Macrium Support

jphughan
jphughan
Most Valuable Professional
Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)
Group: Forum Members
Posts: 3K, Visits: 21K
Building on Nick's answer, if the SATA cable and/or the system memory can't be trusted, then not only would you have far more widespread problems, but it would seem pointless to even attempt the verification you're proposing.  For example, if a faulty SATA cable caused bits to be flipped randomly, then you could have a situation where the data was written to disk correctly, but when it was read back for verification, a bit was flipped, in which case Reflect would incorrectly declare a verification failure even though the data was in fact accurate on the disk itself and might have been read back properly on a subsequent attempt -- or you could even have data that's incorrect on disk but gets flipped when read back such that it appeared correct.  These same risks would exist if you had unreliable memory.  I don't think reading every sector multiple times during verification to ensure consistent results would be feasible -- would you really want verification to take 2-3x longer?  With respect to bad sectors of the drive, the HDD controller is responsible for managing that problem; if a drive notices that it's having trouble reading/writing a sector, then the controller will autonomously swap that sector out for a spare sector without any action required by the OS/application.

The bottom line is that if you can't trust that the components required to perform a verification are operating reliably, then you can't trust the result of the verification, positive or negative.  If you're thinking, "Well if you could trust all of the involved components 100%, then there would be no need to verify when creating a backup either, and yet that option exists and sometimes even detects problems," then I believe the answer there is that creating an image backup is more complex, since they can involve compression, encryption, indexes, and of course packaging everything into a container file -- but even with all of that, Macrium's KB article about verification estimates that less than 0.1% of systems would have problems that would lead to verification failure.  By comparison, restoring to disk involves none of the factors I just mentioned, which I suspect is why clone operations do not provide an option to verify that the target was written out correctly.

Edited 3 December 2017 10:21 PM by jphughan
jphughan
jphughan
Most Valuable Professional
Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)
Group: Forum Members
Posts: 3K, Visits: 21K
Also, with respect to your point about verifying before a restore because you want to "check whether the file integrity of the last backup is ok, otherwise it makes no sense to restore using this image", @Nick correct me if I'm wrong here, but my understanding is that if a problem existed in the backup file(s) being restored that would cause a verification failure, then if the restore were performed without verifying first, the restore would still fail when Reflect reached the problem area; Reflect would not simply restore bad data and tell the user everything was ok.

As I understand it, the purpose of a pre-restore verification is for situations where you might have a somewhat working system before you perform a restore, but if you began a restore without verifying first and it failed, now you're left with a target in a completely unusable state, whereas a verification beforehand would have thrown a warning and kept your target intact, such as it was.  But if the data currently on the target is considered useless anyway (or the target is empty), then there isn't any real benefit to a pre-restore verification.  Sure, verifying beforehand avoids wasting time performing an ill-fated restore, but given the time it takes to verify and the statistical unlikelihood of a verification failure, it seems that you'd save time overall by skipping the verify and risking a highly unlikely bad restore rather than always extending your total restore times by running a verify first.

Edited 3 December 2017 10:15 PM by jphughan
Andreas K
Andreas K
New Member
New Member (24 reputation)New Member (24 reputation)New Member (24 reputation)New Member (24 reputation)New Member (24 reputation)New Member (24 reputation)New Member (24 reputation)New Member (24 reputation)New Member (24 reputation)
Group: Forum Members
Posts: 19, Visits: 34
I think your argumentation in terms of HW failures is very wrong.

For backup and recovery its all about to validate whether data from source reached destination in good shape.

1. You offer this option already when making backups by the option
"Verify image or backup file directly after creation"
in the advanced settings.

2. This is missing for the opposite direction, if you restore a backup to disk.
"verify data after recovery".
And this is to validate /guarantee, that the recovery was 100%.
Same story as point 1

With your, sorry  faulty , argumentation you could already put the verification in point 1 into question.
But that would also be wrong.

Please support user to be able to validate the results of data recovery from an image to disk
by adding an option to validate recovered data to disk against the source (the image file).

Many thanks


jphughan
jphughan
Most Valuable Professional
Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)
Group: Forum Members
Posts: 3K, Visits: 21K
Andreas K - 4 December 2017 7:39 AM
With your, sorry  faulty , argumentation you could already put the verification in point 1 into question.
But that would also be wrong.

Actually, if the SATA/USB cabling or memory was affected in the way I described above, then that does put the existing verification mechanism into question; that's not wrong at all.  Again, if you can't be certain that the bits the CPU receives for performing verification are the same bits that actually exist on the disk, then it's impossible to perform a verification with 100% certainty about the result.

Edited 4 December 2017 2:23 PM by jphughan
john.p
john.p
Macrium Representative
Macrium Representative (88 reputation)Macrium Representative (88 reputation)Macrium Representative (88 reputation)Macrium Representative (88 reputation)Macrium Representative (88 reputation)Macrium Representative (88 reputation)Macrium Representative (88 reputation)Macrium Representative (88 reputation)Macrium Representative (88 reputation)
Group: Administrators
Posts: 27, Visits: 120
Hi,

In reply to Andreas,

To clarify the backup and restore operations ...

During backup, there are two data paths,
1) Source disk to memory - There is no mechanism to verify that sectors read from the the source disk are not corrupt.
2) Memory to image file - Data blocks written are check-summed and indexed. Given that the CPU/Memory is operating correctly, this gives assurance that the image file is consistent with the memory copy of the source disk.

During a restore, again there are also two data paths,
1) Image file to memory. The checksums are recalculated and compared with those generated at backup time, giving assurance that the image file is consistent with original memory copy of the source.
2) Memory to target disk. This data path not verified for the following reasons.
a) It would incur a huge performance penalty (non-buffered reads would be needed to remove cache effects) whilst still not giving an assurance of a restore that is, or will remain, error free .
b) It is consistent with the backup process.
c) Hardware verification is a very different domain better served by specialist tools.

If you concerned about stronger data integrity assurances, the only real solutions lie in hardware such as ECC memory and a RAID configuration that includes check summing.

Kind regards,
John P.
Andreas K
Andreas K
New Member
New Member (24 reputation)New Member (24 reputation)New Member (24 reputation)New Member (24 reputation)New Member (24 reputation)New Member (24 reputation)New Member (24 reputation)New Member (24 reputation)New Member (24 reputation)
Group: Forum Members
Posts: 19, Visits: 34
@John P.


We agree on the point that you tell that restore also has 2 data paths
I also fully agree that the option makes sensse to be used to check integrity of the stored image file 1st.
We are not that far from each other.

Maybe we have a only a misunderstanding in regards to the final check after the 2nd "data path".

All that I demand is a clickable option, that after the image has been written to disk (2nd data path)
the data is read again from the disk and to be compared to the image file from which it has been restored,
to ensure that all has really been written to disk properly.
Please dont tell me this is rocket science.
This is an easy and straight forward process to check, that during the 2nd data path nothing wrong happened.

And I do not talk about some "tricky"  hardware verification, simply a comparison whether the data on disk is still equal
compared to the souce, the backup image. You could implement that as an additional / optional check that will be
performed at the very end of a data restore to disk.

Forget about my fancy ideas to do or combine this already in the second path.

Make it simply a final check, then you have absolutely no complexity in programming this

But currently this final check is simply MISSING in your product..

You have such a nice product, which is in many aspects so much better compared to the competition.

But this final check is simply missing and makes recovery simply lets say "vague".
I would definitively regard a final comparison run as best practice to ensure that all was written properly to disk.








GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...




Similar Topics

Reading This Topic

Login

Explore
Messages
Mentions
Search