I'm using SSD to SSD and SSD to HD on two computers. Never a /vb problem.
Intel SSDs.
Poll - do you use byte-for-byte verification?
-
TeraByte Support
- Posts: 3760
- Joined: Thu May 05, 2011 10:37 pm
Re: Poll - do you use byte-for-byte verification?
You'll get a byte-for-byte failure when the data read back after the backup
is not the same as it was during the backup. PHYLock traps writes before it
goes to the HD and reads what is being replaced and writes that to its cache
then the write goes down to the hard drive. If something is between PHYLock
and the hard drive that is changing the drive, phylock won't be able to see
it. You can use a third party devicetree to see the stack on the disk
drives to see what may be below it. VSS basically does the same thing at a
volume level.
You should follow all steps in
http://www.terabyteunlimited.com/kb/article.php?id=151 (including the
memtest86+ and chkdsk /f).
To a program or OS an SSD drive looks no different than a normal hard drive.
You have sectors from 0-n
If you want to see the changed data dump, up the log level.. /logl:50
should show it - you can also use the findlbaf utility from the ftp site to
attempt to locate what file is being changed.
Of course backing up from boot media could be tried as well. If offline
does it as well, there is for sure a hardware or firmware problem somewhere.
is not the same as it was during the backup. PHYLock traps writes before it
goes to the HD and reads what is being replaced and writes that to its cache
then the write goes down to the hard drive. If something is between PHYLock
and the hard drive that is changing the drive, phylock won't be able to see
it. You can use a third party devicetree to see the stack on the disk
drives to see what may be below it. VSS basically does the same thing at a
volume level.
You should follow all steps in
http://www.terabyteunlimited.com/kb/article.php?id=151 (including the
memtest86+ and chkdsk /f).
To a program or OS an SSD drive looks no different than a normal hard drive.
You have sectors from 0-n
If you want to see the changed data dump, up the log level.. /logl:50
should show it - you can also use the findlbaf utility from the ftp site to
attempt to locate what file is being changed.
Of course backing up from boot media could be tried as well. If offline
does it as well, there is for sure a hardware or firmware problem somewhere.
Re: Poll - do you use byte-for-byte verification?
I have an answer in my case... the SSD has now failed completely. It won't power up at all.
Just as with regular drives, it looks like the TeraByte Image programs can catch a hardware problem before it becomes noticeable any other way.
Just as with regular drives, it looks like the TeraByte Image programs can catch a hardware problem before it becomes noticeable any other way.
Re: Poll - do you use byte-for-byte verification?
Both of the systems that I have seen problems with BFB verification have had Samsung SSDs.
Not sure if that is the issue. In this thread <http://www.terabyteunlimited.com/ucf/vi ... mg11#p6841> I swapped out the Samsung for a Toshiba. In the Samsung notebook, of course it had a Samsung SSD. I was able to get a successful BFB verify with TRIM de-selected, and VSS disabled in this thread <http://www.terabyteunlimited.com/ucf/vi ... 1582#p8107>
Not sure if that is the issue. In this thread <http://www.terabyteunlimited.com/ucf/vi ... mg11#p6841> I swapped out the Samsung for a Toshiba. In the Samsung notebook, of course it had a Samsung SSD. I was able to get a successful BFB verify with TRIM de-selected, and VSS disabled in this thread <http://www.terabyteunlimited.com/ucf/vi ... 1582#p8107>
Re: Poll - do you use byte-for-byte verification?
Since it appears that there are a few of us that have problems with BFB verification with SSDs, I would like to see Terabyte look into this a bit more. Is there any deeper logging that could be enabled? Is there a different way that the BFB can be done? Can the readback be repeated a few times if there is an error to see if the error changes?
Re: Poll - do you use byte-for-byte verification?
Always and without exception. I would not buy backup software that didn't use it.
The risk of an undetected data error is low but not zero (~ 10^-14). In some areas, I want rid of the "but". Backups are one such area:
The first reason is, it's likely a backup could involve copying anything from 10 GB to 200+ GB. Basic maths applies. The risk of a single undetected bit flip or undetected error might be very small, but the risk of such an error when copying ~ 1,600,000,000,000 bits (200 GB) may not be. Also the events aren't independent events. Errors tend to be "bursty", they are not always independent of the taking of a backup (more likely to take a backup if I suspect an issue?). The risk/consequences becomes a factor (cost of extra time to me = zero, cost of dud backup = subjectively very high).
Also perhaps a whole second area of risk is often completely ignored: that even if the hardware is validated and fine, and the odds of hardware error low, the backup software, platform firmware or OS might have a subtle bug that causes errors or non-detection of issues, in some circumstances. For example, suppose there were an undetected race condition in a driver, or the Windows kernel, or PHYLock, or an interaction between the RAID firmware and motherboard, an undetected error condition not being correctly tested, or a logic path that's wrong? If so, VSS or application software, might blissfully continue to create its backup, whether that backup contains junk in some places or not. I'd never know without checking. Backup programs often error out or fail to complete, depending on the system and its use. It isn't much stretch to imagine there could potentially be rare bugs where it should error out (or Windows should pass it an error code) but doesn't.
Hardware is incredibly reliable, but even so, to copy ~ 10^12 bits on multiple occasions, sometimes off near-failing equipment or equipment pushed hard, and be so very sure that all errors will be detected and reported whether due to hardware or software, to the point of not even caring about checking the backup afterwards, and then assuming in addition that there has been no error in any code (driver/OS/VSS/app) that would cause an undetected backup error, when there's no need to take any of those chances since there is no subjective "cost" for me to doing that check in the first place... hmm.
So yes. The peace of mind is worth it. I recheck byte by byte, every time, and only use backup software that can validate byte by byte.
(** To be fair, I can't be sure of the maths of all this, and a lot is subjective, it's a subject of intense research too, but it's enough for me, to simply conclude there *might* be a plausible risk, as mitigation is so easy...)
The risk of an undetected data error is low but not zero (~ 10^-14). In some areas, I want rid of the "but". Backups are one such area:
The first reason is, it's likely a backup could involve copying anything from 10 GB to 200+ GB. Basic maths applies. The risk of a single undetected bit flip or undetected error might be very small, but the risk of such an error when copying ~ 1,600,000,000,000 bits (200 GB) may not be. Also the events aren't independent events. Errors tend to be "bursty", they are not always independent of the taking of a backup (more likely to take a backup if I suspect an issue?). The risk/consequences becomes a factor (cost of extra time to me = zero, cost of dud backup = subjectively very high).
Also perhaps a whole second area of risk is often completely ignored: that even if the hardware is validated and fine, and the odds of hardware error low, the backup software, platform firmware or OS might have a subtle bug that causes errors or non-detection of issues, in some circumstances. For example, suppose there were an undetected race condition in a driver, or the Windows kernel, or PHYLock, or an interaction between the RAID firmware and motherboard, an undetected error condition not being correctly tested, or a logic path that's wrong? If so, VSS or application software, might blissfully continue to create its backup, whether that backup contains junk in some places or not. I'd never know without checking. Backup programs often error out or fail to complete, depending on the system and its use. It isn't much stretch to imagine there could potentially be rare bugs where it should error out (or Windows should pass it an error code) but doesn't.
Hardware is incredibly reliable, but even so, to copy ~ 10^12 bits on multiple occasions, sometimes off near-failing equipment or equipment pushed hard, and be so very sure that all errors will be detected and reported whether due to hardware or software, to the point of not even caring about checking the backup afterwards, and then assuming in addition that there has been no error in any code (driver/OS/VSS/app) that would cause an undetected backup error, when there's no need to take any of those chances since there is no subjective "cost" for me to doing that check in the first place... hmm.
So yes. The peace of mind is worth it. I recheck byte by byte, every time, and only use backup software that can validate byte by byte.
(** To be fair, I can't be sure of the maths of all this, and a lot is subjective, it's a subject of intense research too, but it's enough for me, to simply conclude there *might* be a plausible risk, as mitigation is so easy...)