February 24, 201511 yr ok, a lot has happened, and i have done a lot (i think most of what i have done so far has not been a good idea!) after a stormy night with several power outages, i had a drive that wasn't spinning up, so i figured it was time to transition to larger drives anyway. at this point my config was as follows unraid server 5.0beta-x(?) upgraded a while ago from 4.7 3x 3TB drives for data 1x 3TB drive for parity my first step, since i was upgrading to 6TB drives, was to replace the parity. i removed the parity drive, replaced it with a 6TB drive, and let the array rebuild. all was well then i found one of the drives had about 17 errors during this process, so i pegged that as my problem drive. i removed the drive, replaced it with a new 6TB drive, and let it rebuild all was well i upgraded unraid to the latest stable version 5.0.6 all was well I had read and written files in the array at this point with no issues. last night, nothing out of the ordinary, i tried to paste some files into one of my shares, and i got an access denied message. i tinkered for a while, and could not get anything to work. after several reboots and other attempts at figuring it out, my largest share with over 3K files and 6TB of data is now showing empty! the individual disks when accessed, are showing the files so i don't panic too much. i found a thread describing a fix which is referenced in the wiki using reiserfsck. i followed the instructions there, and it found a few errors and suggested a tree rebuild. long story short, after messing around, the drive in question (drive 3, the new 6tb data drive) turns up blank. again, i panic and have a parity check done (realizing right after i start it that it is the opposite of what i want to do) so after sleeping on it, i realize i still have the old parity and data drive. unfortunately i don't know which is which :-( so, i try hooking them up via a USB enclosure to read them on my windows machine using several utilities suggested in this forum. none of them worked, so i fired up a ubuntu 14 box....no luck there either. ubuntu could not see them so now i figure, let me hook them up to the unraid box via USB so far so good, the disks are seen, but i cannot mount them, and i can't seem to do anything useful with them. I have already made the mistake of trying to rebuild the superblock on one of them, and that didn't work so now i have 2 old drives that work. one is partiy, one is data. i don't know which is which. neither of them can be read in any machine i have connected them to. attempts at mounting them on my unraid computer gives me this: wrong fs type, bad option, bad superblock on /dev/sda, missing codepage or helper program, or other error where do i start? how can i fix this? any help would be greatly appreciated!!
February 24, 201511 yr Do you have backups of all important data? The parity drive doesn't have a file system so it would be unmountable no matter what you tried. From your description it sounds like pretty much everything you did was wrong from the beginning. If you weren't sure all of your data disks was OK, you should never have tried to change the parity disk since that was the only thing that would have allowed you to recover data on a failed data disk. It doesn't sound like the protections built into unRAID are probably going to help much after what you have done, so maybe the best thing would be to take stock of what data you do have. Does it look like your other drives are OK? Probably the simplest thing to do at this point is just try to put all of the drives in as data drives and don't assign any parity drive and see what you have. Any drives that don't mount may be parity, or may be corrupt data. But wait for a second opinion.
February 24, 201511 yr Author i have 2 drives that have been removed and were fully working when i pulled them. one is parity, one has data. my understanding of unraid was that any drive could be removed from the server at any time, and be read like a regular hard drive. this is one of the key reasons of why i went with unraid. i know mistakes have been made, but my goal right now is to try and get the data off of the old drives. the problem is, i don't have any more ports on my motherboard so my only options are a USB enclosure or putting them into another computer. i have tried both and none work. to clarify, the data drive i removed with errors, was still fully readable and working when i removed it. it had not failed, and was green when i removed it. I just knew that it was time to change drives, so i went for it. i don't understand why that was a bad idea.
February 24, 201511 yr ok, a lot has happened, and i have done a lot (i think most of what i have done so far has not been a good idea!) after a stormy night with several power outages, i had a drive that wasn't spinning up, so i figured it was time to transition to larger drives anyway. at this point my config was as follows unraid server 5.0beta-x(?) upgraded a while ago from 4.7 3x 3TB drives for data 1x 3TB drive for parity my first step, since i was upgrading to 6TB drives, was to replace the parity. i removed the parity drive, replaced it with a 6TB drive, and let the array rebuild. all was well then i found one of the drives had about 17 errors during this process, so i pegged that as my problem drive. i removed the drive, replaced it with a new 6TB drive, and let it rebuild all was well i upgraded unraid to the latest stable version 5.0.6 all was well I had read and written files in the array at this point with no issues. last night, nothing out of the ordinary, i tried to paste some files into one of my shares, and i got an access denied message. i tinkered for a while, and could not get anything to work. after several reboots and other attempts at figuring it out, my largest share with over 3K files and 6TB of data is now showing empty! the individual disks when accessed, are showing the files so i don't panic too much. i found a thread describing a fix which is referenced in the wiki using reiserfsck. i followed the instructions there, and it found a few errors and suggested a tree rebuild. long story short, after messing around, the drive in question (drive 3, the new 6tb data drive) turns up blank. again, i panic and have a parity check done (realizing right after i start it that it is the opposite of what i want to do) so after sleeping on it, i realize i still have the old parity and data drive. unfortunately i don't know which is which :-( so, i try hooking them up via a USB enclosure to read them on my windows machine using several utilities suggested in this forum. none of them worked, so i fired up a ubuntu 14 box....no luck there either. ubuntu could not see them so now i figure, let me hook them up to the unraid box via USB so far so good, the disks are seen, but i cannot mount them, and i can't seem to do anything useful with them. I have already made the mistake of trying to rebuild the superblock on one of them, and that didn't work so now i have 2 old drives that work. one is partiy, one is data. i don't know which is which. neither of them can be read in any machine i have connected them to. attempts at mounting them on my unraid computer gives me this: wrong fs type, bad option, bad superblock on /dev/sda, missing codepage or helper program, or other error where do i start? how can i fix this? any help would be greatly appreciated!! Neo, At the beginning of your post, you mention a drive not spinning up anymore (as in it died o assume). Then you say the first step you took was to replace the parity drive. Did you do this before replacing the defective drive and performing a rebuild? If so, that was the first thing you did wrong. When a drive goes bad, the first thing you need to do is replace the failed drive and ONLY the failed drive and perform a rebuild. When you replaced the parity disk after another disk in the array had failed, you lost any chance of rebuilding the data that was lost on the first drive.
February 24, 201511 yr Author i see the confusion. the drive would not spin up, but after 2 reboots it did spin up and was fine after that, but it sounded like it would hard reset at least once every time i booted up. so to clarify, everything was back up and running and working fine BEFORE i replaced the drives. so now i have the 2 drives that were removed (1 data, 1 parity) outside of the array and sitting in my lap. both work, and both should have the data intact, i just don't know which is which. neither is recognized as a valid drive in any system i put them into
February 24, 201511 yr Does unRAID think your current configuration is OK? All drives green? Maybe a screenshot would help clarify your situation.
February 24, 201511 yr Author it does think everything is ok right now, but the drive that was generating reiserfs errors is now blank and formatted. so i need the data that was on that drive to be recovered (unlikely) or get the data of the old drives, which should be easy, but isn't
February 24, 201511 yr i see the confusion. the drive would not spin up, but after 2 reboots it did spin up and was fine after that, but it sounded like it would hard reset at least once every time i booted up. so to clarify, everything was back up and running and working fine BEFORE i replaced the drives. so now i have the 2 drives that were removed (1 data, 1 parity) outside of the array and sitting in my lap. both work, and both should have the data intact, i just don't know which is which. neither is recognized as a valid drive in any system i put them into Ok, that clarifies. Has the array been written to since you removed the first parity disk?
February 24, 201511 yr it does think everything is ok right now, but the drive that was generating reiserfs errors is now blank and formatted. so i need the data that was on that drive to be recovered (unlikely) or get the data of the old drives, which should be easy, but isn't Well the old drive that removed was the one reporting errors after the parity sync with the new drive, right? Could be that the drive really does have some issues. I would also wonder if you use another machine and boot unraid on that machine, can you mount the disks that way?
February 24, 201511 yr Do you mean that the drive is not seen at the BIOS level, or that it is not seen as having a valid file system? If the drive is not seen at the BIOS level then there is little chance of getting any data off it unless you want to pay a significant sum of money to data recovery specialists. If the drive is seen at the BIOS level, then the parity drive has no file system on it so will never be seen as having a valid file system. There is therefore no data that can be recovered from the parity drive. The data drive would only be seen as having a valid file system if the system in question supports Reiserfs - so what type of system are you trying it with?
February 24, 201511 yr When you rebuilt the superblock, did you use -scan-whole-partition and did you use the /dev/sd?1 vs /dev/sd? device? Since the first partition is the reiser partition, you would use the /dev/sd?1 device. In particular, what reiserfsck options were used when trying to recover the drive?
February 24, 201511 yr Author i see the confusion. the drive would not spin up, but after 2 reboots it did spin up and was fine after that, but it sounded like it would hard reset at least once every time i booted up. so to clarify, everything was back up and running and working fine BEFORE i replaced the drives. so now i have the 2 drives that were removed (1 data, 1 parity) outside of the array and sitting in my lap. both work, and both should have the data intact, i just don't know which is which. neither is recognized as a valid drive in any system i put them into Ok, that clarifies. Has the array been written to since you removed the first parity disk? yes, the array has been written to and the current array is most likely a lost cause for recovering that data i think my only hope is figuring out how to salvage the data from the 2 drives that were removed.
February 24, 201511 yr Author it does think everything is ok right now, but the drive that was generating reiserfs errors is now blank and formatted. so i need the data that was on that drive to be recovered (unlikely) or get the data of the old drives, which should be easy, but isn't Well the old drive that removed was the one reporting errors after the parity sync with the new drive, right? Could be that the drive really does have some issues. I would also wonder if you use another machine and boot unraid on that machine, can you mount the disks that way? yes, i believe that the reiserfs errors started on the drive with errors, and were actually carried into the parity of the array and then duplicated onto the new drive. i think that at least some of the data can be recovered from the old drive though. at this point i would be happy to just have a list of files that were on there so i know what was missing. the data isn't irreplaceable
February 24, 201511 yr i see the confusion. the drive would not spin up, but after 2 reboots it did spin up and was fine after that, but it sounded like it would hard reset at least once every time i booted up. so to clarify, everything was back up and running and working fine BEFORE i replaced the drives. so now i have the 2 drives that were removed (1 data, 1 parity) outside of the array and sitting in my lap. both work, and both should have the data intact, i just don't know which is which. neither is recognized as a valid drive in any system i put them into Ok, that clarifies. Has the array been written to since you removed the first parity disk? yes, the array has been written to and the current array is most likely a lost cause for recovering that data i think my only hope is figuring out how to salvage the data from the 2 drives that were removed. Ok, please see weebotechs response and provide feedback. Want to do what we can to try and help you recover any data from the disk you removed.
February 24, 201511 yr Author When you rebuilt the superblock, did you use -scan-whole-partition and did you use the /dev/sd?1 vs /dev/sd? device? Since the first partition is the reiser partition, you would use the /dev/sd?1 device. In particular, what reiserfsck options were used when trying to recover the drive? i did: reiserfsck --rebuild-sb /dev/sda
February 24, 201511 yr Author Do you mean that the drive is not seen at the BIOS level, or that it is not seen as having a valid file system? If the drive is not seen at the BIOS level then there is little chance of getting any data off it unless you want to pay a significant sum of money to data recovery specialists. If the drive is seen at the BIOS level, then the parity drive has no file system on it so will never be seen as having a valid file system. There is therefore no data that can be recovered from the parity drive. The data drive would only be seen as having a valid file system if the system in question supports Reiserfs - so what type of system are you trying it with? yes it is seen at the bios level. I know the parity drive has not recoverable data on it, but neither drive shows a file system so it is difficult for me to determine which was the parity drive.
February 24, 201511 yr When you rebuilt the superblock, did you use -scan-whole-partition and did you use the /dev/sd?1 vs /dev/sd? device? Since the first partition is the reiser partition, you would use the /dev/sd?1 device. In particular, what reiserfsck options were used when trying to recover the drive? i did: reiserfsck --rebuild-sb /dev/sda That would not work as if you use the raw device you have to specify the partition! Using /dev/sda is likely to have corrupted the partition table on the disk. You should have either used /dev/sda1 or put the array into maintenance mode and used one of the /dev/md?? type device names. If the partition table can be recovered, then running reiserfsck with the correct device name will probably recover the majority of the data. I am not sure exactly what the best way is to recover the partition table but hopefully someone can chime in with guidance.
February 24, 201511 yr Author When you rebuilt the superblock, did you use -scan-whole-partition and did you use the /dev/sd?1 vs /dev/sd? device? Since the first partition is the reiser partition, you would use the /dev/sd?1 device. In particular, what reiserfsck options were used when trying to recover the drive? i did: reiserfsck --rebuild-sb /dev/sda That would not work as if you use the raw device you have to specify the partition! Using /dev/sda is likely to have corrupted the partition table on the disk. You should have either used /dev/sda1 or put the array into maintenance mode and used one of the /dev/md?? type device names. this was done on the old drive in the USB enclosure, not the array
February 24, 201511 yr this was done on the old drive in the USB enclosure, not the array OK - so the /dev/md?? devices were not available. However that means the partition had to be specified to get correct behaviour from reiserfsck as it works at the partition level - not the whole disk level.
February 24, 201511 yr Author this was done on the old drive in the USB enclosure, not the array OK - so the /dev/md?? devices were not available. However that means the partition had to be specified to get correct behaviour from reiserfsck as it works at the partition level - not the whole disk level. most of the info i have given in my original post is basically just for background. I think my real question is: i have 2 drives, one is parity, one is data. nether can be read in a linux computer, both show up as drives via command line. i need to figure out which one is the data drive, and find out how to mount and read it in a linux machine that supports the reiserfs i am using an unraid server as my linux machine using that as the basis of my problem, would would you suggest?
February 24, 201511 yr As I mentioned earlier you have almost certainly destroyed the partition table on the data disk by running a reiserfsck --rebuild-sb with the wrong device name, and that will stop the disk being mounted on any system. If you are lucky then someone (not me I am afraid as this is beyond my expertise level) will be able to chime in with a way to look at particular disk offsets to determine which was the data disk, and also where the partition started. If that information can be determined then the partition table can be rebuilt.
February 24, 201511 yr Author As I mentioned earlier you have almost certainly destroyed the partition table on the data disk by running a reiserfsck --rebuild-sb with the wrong device name, and that will stop the disk being mounted on any system. If you are lucky then someone (not me I am afraid as this is beyond my expertise level) will be able to chime in with a way to look at particular disk offsets to determine which was the data disk, and also where the partition started. If that information can be determined then the partition table can be rebuilt. i ran that on one of the two drives. at this point there is a 50/50 chance that it was on the old parity drive so there is still a 50/50 chance that the data drive is still recoverable, as it is untouched at this point.
February 24, 201511 yr As I mentioned earlier you have almost certainly destroyed the partition table on the data disk by running a reiserfsck --rebuild-sb with the wrong device name, and that will stop the disk being mounted on any system. If you are lucky then someone (not me I am afraid as this is beyond my expertise level) will be able to chime in with a way to look at particular disk offsets to determine which was the data disk, and also where the partition started. If that information can be determined then the partition table can be rebuilt. i ran that on one of the two drives. at this point there is a 50/50 chance that it was on the old parity drive so there is still a 50/50 chance that the data drive is still recoverable, as it is untouched at this point. Either way it is still unmountable so someone with a more low-level understanding than I have will have to help. I don't really have a lot to add to this but I would like to try to fill in a few more details of how you got to this point in case it might be instructive. You mentioned power outages. Did any of these occur while you were trying to fix your problems, or were they all before? (Get an UPS!) When you restarted after the power outages, did you let unRAID complete the parity check that happens when you have an unsafe shutdown? Did you run preclear on the new drives before trying to use them?
February 24, 201511 yr Author As I mentioned earlier you have almost certainly destroyed the partition table on the data disk by running a reiserfsck --rebuild-sb with the wrong device name, and that will stop the disk being mounted on any system. If you are lucky then someone (not me I am afraid as this is beyond my expertise level) will be able to chime in with a way to look at particular disk offsets to determine which was the data disk, and also where the partition started. If that information can be determined then the partition table can be rebuilt. i ran that on one of the two drives. at this point there is a 50/50 chance that it was on the old parity drive so there is still a 50/50 chance that the data drive is still recoverable, as it is untouched at this point. Either way it is still unmountable so someone with a more low-level understanding than I have will have to help. I don't really have a lot to add to this but I would like to try to fill in a few more details of how you got to this point in case it might be instructive. You mentioned power outages. Did any of these occur while you were trying to fix your problems, or were they all before? (Get an UPS!) When you restarted after the power outages, did you let unRAID complete the parity check that happens when you have an unsafe shutdown? Did you run preclear on the new drives before trying to use them? i had a UPS which eventually died and i had not yet replaced it the best way to answer this is that before i removed those two drives, the entire array was up and running with valid parity and no issues. the drives were replaced as a precautionary measure.
February 24, 201511 yr As I mentioned earlier you have almost certainly destroyed the partition table on the data disk by running a reiserfsck --rebuild-sb with the wrong device name, and that will stop the disk being mounted on any system. If you are lucky then someone (not me I am afraid as this is beyond my expertise level) will be able to chime in with a way to look at particular disk offsets to determine which was the data disk, and also where the partition started. If that information can be determined then the partition table can be rebuilt. i ran that on one of the two drives. at this point there is a 50/50 chance that it was on the old parity drive so there is still a 50/50 chance that the data drive is still recoverable, as it is untouched at this point. Either way it is still unmountable so someone with a more low-level understanding than I have will have to help. I don't really have a lot to add to this but I would like to try to fill in a few more details of how you got to this point in case it might be instructive. You mentioned power outages. Did any of these occur while you were trying to fix your problems, or were they all before? (Get an UPS!) When you restarted after the power outages, did you let unRAID complete the parity check that happens when you have an unsafe shutdown? Did you run preclear on the new drives before trying to use them? i had a UPS which eventually died and i had not yet replaced it the best way to answer this is that before i removed those two drives, the entire array was up and running with valid parity and no issues. the drives were replaced as a precautionary measure. You didn't actually answer all of the questions. If you don't want to for some reason then I will drop it.
Archived
This topic is now archived and is closed to further replies.