I lost a drive to a head crash. I've been trying to recover the drive and I only get about 5% of the data back. The rest are .unrecoverable. The movies I can re-rip my DVDs/Bluerays, my pictures I cannot reproduce!
Please help!
Here is the top of my config:
'# Defines the file to use as Parity storage
parity P:\SnapRAID.parity
'# Defines the file to use as Q-Parity storage
'#q-parity F:\qar\q-parity\SnapRAID.Q.parity
'# Defines the file to use as content list
'# content C:\SnapRAID.content
'# content Z:\SnapRAID.content
content G:\SnapRAID.content
content P:\SnapRAID.content
'# Defines the data disks to use
'# The order is relevant for parity, do not change it
disk d0 C:
disk d1 Z:
disk d2 G:
Here is an error that I'm getting:
unrecoverable:24353:d0:Users/Mldkfa/AppData/Local/Google/Chrome/User Data/Default/Session Storage/000542.ldb: Unrecoverable error at position 0
unrecoverable:24353:d1:Media/Movies/Sorted/Beer Wars (2009)/Beer Wars (2009).avi: Unrecoverable error at position 1795
Error opening file 'C:/Users/Mldkfa/AppData/Local/Google/Chrome/User Data/Default/Session Storage/000545.ldb'. No such file or directory [2].
error:24354:d0:Users/Mldkfa/AppData/Local/Google/Chrome/User Data/Default/Session Storage/000545.ldb: Open error at position 0
error:24354:d1:Media/Movies/Sorted/Beer Wars (2009)/Beer Wars (2009).avi: Data error at position 1796
entry:0:block:known:bad:d0:Users/Mldkfa/AppData/Local/Google/Chrome/User Data/Default/Session Storage/000545.ldb:0:
entry:1:block:known:bad:d1:Media/Movies/Sorted/Beer Wars (2009)/Beer Wars (2009).avi:1796:
strategy_error:24354: No strategy to recover from 2 failures with 1 parity with hash
recover_sync:24354:2: Failed with no attempts
recover_unsync:24354:2: Skipped for nothing unsynched
Last edit: mldkfa 2015-04-14
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Your C drive should not be a data drive. The contents change far too frequently, and that causes exactly what you have now witnessed. The parity is out of sync because the files it relied on no longer exist. Look through the rest of the log and I'm sure you'll see every unrecoverable file is associated with something like this line:
Error opening file 'C:/Users/Mldkfa/AppData/Local/Google/Chrome/User Data/Default/Session Storage/000545.ldb'. No such file or directory [2].
That's a temp file that used to exist on your C drive (at the time of the last sync) but no longer does.
Unfortunately there's very little to no chance of you recovering d1 from parity at this point. Your best bet is professional data recovery on the failed drive. And then re-configure SnapRAID properly for future usage.
Last edit: Quaraxkad 2015-04-15
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It might be helpful if SnapRAID printed a warning message if it looks like you have included the root directory of a boot drive in your RAID. That is a rookie mistake that should be able to be detected and warned about.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the input. I only backed up my user directory on my c drive. But I don't even care about recovery of my C (since it never went bad). All I'm looking for is data on my Z.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
First you need to stop changing anything until you understand what's going on. This includes even booting the system in most cases, especially if you included the boot drive as data drive.
Now the idea is that in order to recover each small part of a file you need a part from the parity and parts from every other disk in your case with one parity (well, if the disks are unequally filled you don't always need parts from each and every good disk but those are details). Snapraid will tell you what it needs for every file.
The parts from the good disks might be missing because the file was deleted or because the file was changed. If you can recover the file(s) that snapraid wants on the good disk then it would be able to reconstruct the file from the missing/bad disk. It is as simple as that. Of course, some files are just temporary and their content is gone for sure. But maybe some were just moved to some other place or are some "common" files you can get again.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Your content file that you pasted shows otherwise. But in either case, the User directory is actually the worst part to be included in a snapshot parity system. It's the folder that contains files that change very frequently and are deleted very often. Any time this happens without an immediate SnapRAID sync, the parity is invalidated for that portion of "blocks"
Restoring both C and Z from a LiveCD is impossible, unless you had already been using two parity drives. Since you only had one, you're out of luck. The only possibility aside from professional recovery on the bad drive is to search through the log file, try to recover all of the files on the C drive that the log complains about being missing. You will do this manually, not with SnapRAID but with data recovery software like GetDataBack. Then run the SnapRAID fix again. This is extremely unlikely to be of any significant success though, because since the missing files are on the C drive they have probably been deleted and overwritten or changed multiple times over and not recoverable by any means. The longer you continue to use your system (or even keep it powered on) the lower your chances of success here.
Last edit: Quaraxkad 2015-04-15
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I really feel for the loss of your data, it's never fun to go through.
There is hard lesson here that you may or may not have heard of before, but it's the following: RAID is not a substitute for a backup.
I would suggest subscribing to a service like CrashPlan (can get it for 5$ a month) and it will backup all your data to the cloud, encrypted, without any storage limits. If you have a catastrophic failure like you did recently, it would be a nuisance yes, but you would not have lost your data. If your data has any value to you, the 5$ is essentially the equivalent of Car insurance. You pay it, if something happens, you're covered. I use CrashPlan to backup my media server (21TB currently) and have the family plan which lets me backup 10 computers, and that costs me about 80$ a year (got it on sale during black friday promo). I also backup my laptop, my pictures, my wife's laptop, a mac mini and a few other boxes. It's a cheap insurance plan.
Do not mistake RAID for being a backup, even Snapshot RAID solutions like SnapRAID. You absolutely must have a second copy of your data somewhere, preferably off site from your home/where you have your primary data.
But do not blame Andrea or SnapRAID for this, even though it may be easy to do in this moment of frustration.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
SnapRAID is not to blame here... While the documentation probably does not specifically tell you not to include your system drive, it does explain the limitations of snapshot parity. One of which is that it's intended for data that changes infrequently. This is inherent to snapshot parity systems and not SnapRAID itself.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The documentation does mention this under limitations:
"The main one is that if a disk fails, and you haven't recently synced, you may not able to do a complete recover. More specifically, you may be unable to recover up to the size of the amount of the changed or deleted files from the last sync operation. This happens even if the files changed or deleted are not in the failed disk."
The FAQ also says not to use it for boot disks, albeit for different reasons.
And I bet the problem I mentioned there (middle bullet and also later):
"In fact there are people (on this forum) ALREADY doing that (keeping the incomplete to**ent downloads together with the more permanent files on snapraid data disks), compromising the chances for recovery for OTHER data disks."
is precisely what happened here. Chrome data isn't that much total size, but big downloads are a different story.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Don't let the bastards get you down. Maybe ask Andrea if it's possible
to give people edit access to the Sourceforge Wiki. If a couple people
start contributing, I'm sure others will chime in. There will likely be
flame wars, but end of the day, it may at least produce something that
Andrea can draw from for the manual, written from a user's perspective.
There's a lot of good info in the forums, but it's buried and often
redundant. Next time a noob asks why he ran out of parity space,
someone can just point him at the relevant wiki section, instead of
wasting precious keystrokes coming up with new and exciting ways of
telling him he's an idiot.
I wouldn't mind seeing a Theory of Operation section, personally. I
probably don't fully understand all the ins-and-outs of what's going on
under the hood, myself.
On 4/18/2015 12:50 AM, John wrote:
The documentation does mention this under limitations:
"The main one is that if a disk fails, and you haven't recently synced, you may not able to do a complete recover. More specifically, you may be unable to recover up to the size of the amount of the changed or deleted files from the last sync operation. This happens even if the files changed or deleted are not in the failed disk."
The FAQ also says not to use it for boot disks, albeit for different reasons.
And I bet the problem I mentioned there (middle bullet and also later):
"In fact there are people (on this forum) ALREADY doing that (keeping the incomplete to**ent downloads together with the more permanent files on snapraid data disks), compromising the chances for recovery for OTHER data disks."
is precisely what happened here. Chrome data isn't that much total size, but big downloads are a different story.
Help Help!
I lost a drive to a head crash. I've been trying to recover the drive and I only get about 5% of the data back. The rest are .unrecoverable. The movies I can re-rip my DVDs/Bluerays, my pictures I cannot reproduce!
Please help!
Here is the top of my config:
'# Defines the file to use as Parity storage
parity P:\SnapRAID.parity
'# Defines the file to use as Q-Parity storage
'#q-parity F:\qar\q-parity\SnapRAID.Q.parity
'# Defines the file to use as content list
'# content C:\SnapRAID.content
'# content Z:\SnapRAID.content
content G:\SnapRAID.content
content P:\SnapRAID.content
'# Defines the data disks to use
'# The order is relevant for parity, do not change it
disk d0 C:
disk d1 Z:
disk d2 G:
Here is an error that I'm getting:
unrecoverable:24353:d0:Users/Mldkfa/AppData/Local/Google/Chrome/User Data/Default/Session Storage/000542.ldb: Unrecoverable error at position 0
unrecoverable:24353:d1:Media/Movies/Sorted/Beer Wars (2009)/Beer Wars (2009).avi: Unrecoverable error at position 1795
Error opening file 'C:/Users/Mldkfa/AppData/Local/Google/Chrome/User Data/Default/Session Storage/000545.ldb'. No such file or directory [2].
error:24354:d0:Users/Mldkfa/AppData/Local/Google/Chrome/User Data/Default/Session Storage/000545.ldb: Open error at position 0
error:24354:d1:Media/Movies/Sorted/Beer Wars (2009)/Beer Wars (2009).avi: Data error at position 1796
entry:0:block:known:bad:d0:Users/Mldkfa/AppData/Local/Google/Chrome/User Data/Default/Session Storage/000545.ldb:0:
entry:1:block:known:bad:d1:Media/Movies/Sorted/Beer Wars (2009)/Beer Wars (2009).avi:1796:
strategy_error:24354: No strategy to recover from 2 failures with 1 parity with hash
recover_sync:24354:2: Failed with no attempts
recover_unsync:24354:2: Skipped for nothing unsynched
Last edit: mldkfa 2015-04-14
Your C drive should not be a data drive. The contents change far too frequently, and that causes exactly what you have now witnessed. The parity is out of sync because the files it relied on no longer exist. Look through the rest of the log and I'm sure you'll see every unrecoverable file is associated with something like this line:
Error opening file 'C:/Users/Mldkfa/AppData/Local/Google/Chrome/User Data/Default/Session Storage/000545.ldb'. No such file or directory [2].
That's a temp file that used to exist on your C drive (at the time of the last sync) but no longer does.
Unfortunately there's very little to no chance of you recovering d1 from parity at this point. Your best bet is professional data recovery on the failed drive. And then re-configure SnapRAID properly for future usage.
Last edit: Quaraxkad 2015-04-15
It might be helpful if SnapRAID printed a warning message if it looks like you have included the root directory of a boot drive in your RAID. That is a rookie mistake that should be able to be detected and warned about.
Thanks for the input. I only backed up my user directory on my c drive. But I don't even care about recovery of my C (since it never went bad). All I'm looking for is data on my Z.
Random thought. If I booted to a livecd linux or windows environment and tried to restore both my C and my Z drive, could that restore the parity?
First you need to stop changing anything until you understand what's going on. This includes even booting the system in most cases, especially if you included the boot drive as data drive.
Now the idea is that in order to recover each small part of a file you need a part from the parity and parts from every other disk in your case with one parity (well, if the disks are unequally filled you don't always need parts from each and every good disk but those are details). Snapraid will tell you what it needs for every file.
The parts from the good disks might be missing because the file was deleted or because the file was changed. If you can recover the file(s) that snapraid wants on the good disk then it would be able to reconstruct the file from the missing/bad disk. It is as simple as that. Of course, some files are just temporary and their content is gone for sure. But maybe some were just moved to some other place or are some "common" files you can get again.
Your content file that you pasted shows otherwise. But in either case, the User directory is actually the worst part to be included in a snapshot parity system. It's the folder that contains files that change very frequently and are deleted very often. Any time this happens without an immediate SnapRAID sync, the parity is invalidated for that portion of "blocks"
Restoring both C and Z from a LiveCD is impossible, unless you had already been using two parity drives. Since you only had one, you're out of luck. The only possibility aside from professional recovery on the bad drive is to search through the log file, try to recover all of the files on the C drive that the log complains about being missing. You will do this manually, not with SnapRAID but with data recovery software like GetDataBack. Then run the SnapRAID fix again. This is extremely unlikely to be of any significant success though, because since the missing files are on the C drive they have probably been deleted and overwritten or changed multiple times over and not recoverable by any means. The longer you continue to use your system (or even keep it powered on) the lower your chances of success here.
Last edit: Quaraxkad 2015-04-15
so yeah.. not a fan of snapraid. I followed all the documentation when setting this up and now I'm left with lost photos.
I really feel for the loss of your data, it's never fun to go through.
There is hard lesson here that you may or may not have heard of before, but it's the following: RAID is not a substitute for a backup.
I would suggest subscribing to a service like CrashPlan (can get it for 5$ a month) and it will backup all your data to the cloud, encrypted, without any storage limits. If you have a catastrophic failure like you did recently, it would be a nuisance yes, but you would not have lost your data. If your data has any value to you, the 5$ is essentially the equivalent of Car insurance. You pay it, if something happens, you're covered. I use CrashPlan to backup my media server (21TB currently) and have the family plan which lets me backup 10 computers, and that costs me about 80$ a year (got it on sale during black friday promo). I also backup my laptop, my pictures, my wife's laptop, a mac mini and a few other boxes. It's a cheap insurance plan.
Do not mistake RAID for being a backup, even Snapshot RAID solutions like SnapRAID. You absolutely must have a second copy of your data somewhere, preferably off site from your home/where you have your primary data.
But do not blame Andrea or SnapRAID for this, even though it may be easy to do in this moment of frustration.
SnapRAID is not to blame here... While the documentation probably does not specifically tell you not to include your system drive, it does explain the limitations of snapshot parity. One of which is that it's intended for data that changes infrequently. This is inherent to snapshot parity systems and not SnapRAID itself.
The documentation does mention this under limitations:
"The main one is that if a disk fails, and you haven't recently synced, you may not able to do a complete recover. More specifically, you may be unable to recover up to the size of the amount of the changed or deleted files from the last sync operation. This happens even if the files changed or deleted are not in the failed disk."
The FAQ also says not to use it for boot disks, albeit for different reasons.
But yes, we could probably improve this for newcomers, I did try to start a "best practices" document for snapraid but it went down in flames more or less (no) thanks to a rude person: https://sourceforge.net/p/snapraid/discussion/1677233/thread/ea4c40ee/
And I bet the problem I mentioned there (middle bullet and also later):
"In fact there are people (on this forum) ALREADY doing that (keeping the incomplete to**ent downloads together with the more permanent files on snapraid data disks), compromising the chances for recovery for OTHER data disks."
is precisely what happened here. Chrome data isn't that much total size, but big downloads are a different story.
Don't let the bastards get you down. Maybe ask Andrea if it's possible
to give people edit access to the Sourceforge Wiki. If a couple people
start contributing, I'm sure others will chime in. There will likely be
flame wars, but end of the day, it may at least produce something that
Andrea can draw from for the manual, written from a user's perspective.
There's a lot of good info in the forums, but it's buried and often
redundant. Next time a noob asks why he ran out of parity space,
someone can just point him at the relevant wiki section, instead of
wasting precious keystrokes coming up with new and exciting ways of
telling him he's an idiot.
I wouldn't mind seeing a Theory of Operation section, personally. I
probably don't fully understand all the ins-and-outs of what's going on
under the hood, myself.
On 4/18/2015 12:50 AM, John wrote: