Jump to content

HELP PLEASE????


Archivist

Recommended Posts

Posted

I think I just "LOST" my entire Movie etc. Collection of Videos.  I just re-configured my Server after consolidating my Movies Collection on a single 5TB drive.  In removing a couple of 1TB drives and adding another 2TB drive for replacement, I expected to have to change the configuration and somehow reversed the Parity (5TB drive ID).  When the Array started it went immediately to Parity Check and as soon as I saw my Movie Drive was "unformated" I stopped the system & Parity Check.  When I corrected my error, it now shows the Movie Drive as Unformatted? :-[

 

Is there anyway to correct this problem - PLEASE!

 

Dave

  • Replies 69
  • Created
  • Last Reply
Posted

Sounds like you may have put your data drive in the parity slot and it got overwritten by parity.

 

Post a screenshot of Main and go to Tools - Diagnostics and post the complete diagnostics zip.

Posted

looks like this has happened more than once recently.

Maybe LimeTech should build in a fail safe where UnRaid remembers the S# of the parity and gives a big warning and/or won't allow the array to start if it doesn't match without you confirming you changed it.

Posted

Sounds like you may have put your data drive in the parity slot and it got overwritten by parity.

 

Post a screenshot of Main and go to Tools - Diagnostics and post the complete diagnostics zip.

 

Hi Trurl - Thanks for the response, I think that's actually what happened for perhaps 10 seconds.  I stopped the Parity Check as soon as I saw that my Data Drive was "unformatted".  I could/can afford to lose a few files but hopefully :'( not the entire drive.

 

I've attached 3 Screen Shots - 1-Original Setup & 2/3-Current Status (in Maintenance  Mode w/o starting a Parity Check/Sync.  The latter shows that Disks 3/4 are in Auto mode.  Disk 3 is an "old" good Parity Disk from 4.7 but the original disks have been re-purposed for V 6.02 and I was preparing to add it to the Array and format it as XFS.  Disk 1 from the original V 6.02 had been "emptied" (consld8) and reformatted to XFS and was being placed as a Cache drive. 

 

I've also included the complete diagnostics Zip file you suggested.

 

Maybe LimeTech should build in a fail safe where UnRaid remembers the S# of the parity and gives a big warning and/or won't allow the array to start if it doesn't match without you confirming you changed it.

 

Hi Russ - A BIG Thumbs Up on this Idea!

 

Thanks to you both for responding, hope there is an answer!

 

Dave

 

PS - Will update w/additional attachments d/t size limits

Screen_Shot_2015-10-17_at_3_34.25_PM.png.bbe4a640d70368fcd7ce80e7101ac15c.png

Screen_Shot_2015-10-17_at_3_34.25_PM.png.e194c59b649af2a27388aaa1a53d640f.png

tower-diagnostics-20151027-1538.zip

Posted

 

Hi Trurl,

 

I reviewed the Check Disk Filesystems and was already in Maintenance Mode, but my Disk4 (5TB (now)) is listed as "Auto" not XFS.  Do I need to change it with the Array stopped first to XFS then attempt the "Repair"?  Or should this be done from a Command Line?  If so should the Array be stopped and what command would you recommend?

 

When I "clicked" on Disk4 and went to the next page, it just gave me options to look at the Smart Data, but nothing via the GUI (V6) to Check or Repair.  I do see that section on one of the XFS drives.

 

Dave

Posted

 

Hi Trurl,

 

I reviewed the Check Disk Filesystems and was already in Maintenance Mode, but my Disk4 (5TB (now)) is listed as "Auto" not XFS.  Do I need to change it with the Array stopped first to XFS then attempt the "Repair"?  Or should this be done from a Command Line?  If so should the Array be stopped and what command would you recommend?

 

When I "clicked" on Disk4 and went to the next page, it just gave me options to look at the Smart Data, but nothing via the GUI (V6) to Check or Repair.  I do see that section on one of the XFS drives.

 

Dave

No, don't change it to XFS. I think Auto just means use the default filesystem when formatting, but you don't want to format anything. unRAID probably thinks the drive is unformatted already, but you don't want it to format it, you want to try to repair its format instead.

 

If you know it is supposed to be XFS, then just use the XFS repair from the command line. No personal experience with this.

Posted

 

Hi Trurl,

 

I reviewed the Check Disk Filesystems and was already in Maintenance Mode, but my Disk4 (5TB (now)) is listed as "Auto" not XFS.  Do I need to change it with the Array stopped first to XFS then attempt the "Repair"?  Or should this be done from a Command Line?  If so should the Array be stopped and what command would you recommend?

 

When I "clicked" on Disk4 and went to the next page, it just gave me options to look at the Smart Data, but nothing via the GUI (V6) to Check or Repair.  I do see that section on one of the XFS drives.

 

Dave

No, don't change it to XFS. I think Auto just means use the default filesystem when formatting, but you don't want to format anything. unRAID probably thinks the drive is unformatted already, but you don't want it to format it, you want to try to repair its format instead.

 

If you know it is supposed to be XFS, then just use the XFS repair from the command line. No personal experience with this.

 

Thanks Trurl for the suggestion, I've read about it on the site, but am not quite sure how to invoke the command. 

 

Do you know if it's built into UnRaid or has to be downloaded and put on the Flash drive.  Also whether the Array needs to be in Maintenance Mode or totally stopped to invoke. 

 

I was also a bit confused in reading the command whether I use /mnt/disk4 or sdb/partition 1 etc.

 

Dave 

 

Edit - Has anyone had experience invoking this program -xfs_repair with good results?

 

Edit 2 - Trurl or Anyone, since my "Parity" drive has to be recreated (necessary d/t config change anyway), should I disconnect all other drives except Drive4 the one with the error.

Posted

Thanks Trurl for the suggestion, I've read about it on the site, but am not quite sure how to invoke the command. 

Normally we would recommend doing repairs via the GUI, but as yours is more than minor file system corruption then I would recommend doing it via the command line from a console/telnet session as you are more likely to get useful feedback.

 

Do you know if it's built into UnRaid or has to be downloaded and put on the Flash drive.  Also whether the Array needs to be in Maintenance Mode or totally stopped to invoke. 

The repair tools are built into unRAID - no need to download anything extra.

 

I was also a bit confused in reading the command whether I use /mnt/disk4 or sdb/partition 1 etc.
Normally one would run with the array in Maintenance mode and use the /dev/md4 device so that parity is maintained.    However in your case you do not have valid parity so you will need to run against the raw device (e.g. something like /dev/sdb1).  The command would therefore be something like
[code]xfs_repair /dev/sdb1

(assuming your device is /dev/sdb)

 

Edit - Has anyone had experience invoking this program -xfs_repair with good results?

I have used xfs_repair successfully for normal file system corruption.  Not sure however whether it will handle the scenario you have managed to get into.  It is certainly not as good as reiserfsck in recovering from extreme corruption.  I do not know if we have any feedback yet from recovering from the particular scenario you have where a significant part of the start of the disk has been overwritten.  I would expect there to be some data loss but you may be lucky.  You are also likely to end up with quite a few files in the lost+found folder if the files can be found but the directory information giving their names cannot be found.

 

When you run xfs_repair then I would expect it to start by saying it cannot find the superblock (as it has been overwritten with parity information) and then start scanning the disk for a backup copy.  As you stopped the parity sync quickly it should find it but that may take some time.

 

Edit 2 - Trurl or Anyone, since my "Parity" drive has to be recreated (necessary d/t config change anyway), should I disconnect all other drives except Drive4 the one with the error.

This probably makes sense to avoid any accidents during the process.  For instance running xfs_repair against a drive that is not in XFS format could do some damage.  Note that the device name may change if you have unplugged the other drives although if you only have the USB drive and one drive plugged in it is very likely to end up as /dev/sdb.
Posted

itimpi,

 

Thank you very much for your great response.  Last night I totally stopped the Array (out of Maintenance mode) after my 2nd edit.  Thinking about the situation and trying to read about xfx_repair, it just made sense to disconnect all the other drives and not risk creating a bigger problem :-\.  If I only want the drive in question to be worked on, do I need to do a "new config" then add it to the "system" in the non-parity slot?  Seems logical, but then what I did just happened in the same way - duh - :o.  From my reading I think I should run "xfs_repair -n" first just to see what would be corrected and just how bad the situation is.  Will let everyone know my results!

 

Dave

Posted

If you are going to run xfs_repair from the command line then there is no need to add it to the array.  In fact I would recommend that you do not in case unRAID tries to do something during the add since it will not recognise it as a formatted disk.

Posted

Just a thought.

Aside from trying to repair your data disk if all your other disk or ok and your parity drive is ok can't you just rebuild the data disk that got trashed if you put everything back the way it was originally? or if you have a spare to replace the trashed disk with and rebuild that. Do you have a backup of your flash before moving the drives to boot from?

Posted

Just a thought.

Aside from trying to repair your data disk if all your other disk or ok and your parity drive is ok can't you just rebuild the data disk that got trashed if you put everything back the way it was originally? or if you have a spare to replace the trashed disk with and rebuild that. Do you have a backup of your flash before moving the drives to boot from?

If he has a backup of config/super.dat from before that might work. Otherwise you can't get the drives back in those slots without New Config.
Posted

Just a thought.

Aside from trying to repair your data disk if all your other disk or ok and your parity drive is ok can't you just rebuild the data disk that got trashed if you put everything back the way it was originally? or if you have a spare to replace the trashed disk with and rebuild that. Do you have a backup of your flash before moving the drives to boot from?

If he has a backup of config/super.dat from before that might work. Otherwise you can't get the drives back in those slots without New Config.

It might be possible to do the following:

  • Do a New Config and assign drives with a replacement in place of the problem drive and the correct parity disk in place.
  • Check the "trust parity" box.
  • Start the array to get unRAID to recognise the new drive configuration, and immediately stop it again
  • Set the problem drive to "Unassigned".
  • Start the array to get unRAID to 'forget' the drive serial number.  At this point unRAID will be emulating the missing drive using the other drives plus parity so it might be worth seeing if the files on that disk now appear.  With any luck they will.
  • Stop the array and assign the problem disk.
  • Start the array which will cause a rebuild to happen onto the problem disk.

Ideally the above sequence should be tried with a spare disk in the slot for the problem disk as that leaves it free for any other attempts at data recovery.  However if at the point you started the array with the disk 'missing' and the files appeared to be on he emulated disk it would probably do no harm to rebuild onto the original problem disk as it is probably going to rebuild it with good data anyway.

 

Anyone see any reason why the above would not work - I may well have missed something.

Posted

Just a thought.

Aside from trying to repair your data disk if all your other disk or ok and your parity drive is ok can't you just rebuild the data disk that got trashed if you put everything back the way it was originally? or if you have a spare to replace the trashed disk with and rebuild that. Do you have a backup of your flash before moving the drives to boot from?

If he has a backup of config/super.dat from before that might work. Otherwise you can't get the drives back in those slots without New Config.

It might be possible to do the following:

  • Do a New Config and assign drives with a replacement in place of the problem drive and the correct parity disk in place.
  • Check the "trust parity" box.
  • Start the array to get unRAID to recognise the new drive configuration, and immediately stop it again
  • Set the problem drive to "Unassigned".
  • Start the array to get unRAID to 'forget' the drive serial number.  At this point unRAID will be emulating the missing drive using the other drives plus parity so it might be worth seeing if the files on that disk now appear.  With any luck they will.
  • Stop the array and assign the problem disk.
  • Start the array which will cause a rebuild to happen onto the problem disk.

Ideally the above sequence should be tried with a spare disk in the slot for the problem disk as that leaves it free for any other attempts at data recovery.  However if at the point you started the array with the disk 'missing' and the files appeared to be on he emulated disk it would probably do no harm to rebuild onto the original problem disk as it is probably going to rebuild it with good data anyway.

 

Anyone see any reason why the above would not work - I may well have missed something.

 

Hi trurl, itimpi, Russ Uno,

 

Thanks for the info and suggestions.  Unfortunately as mentioned in an earlier post, there was no current Valid Parity.  I created the problem by removing 2 1-TB drives, adding 2 2-TB drives and the 5 TB drive and creating a new Config thus eliminating the possibility of returning to the original 2 x 1TB drives 2 x 2TB drives and the 5 TB drive in question.  That plus the fact that the Parity/5TB were accidentally swapped for even a brief period, probably caused the Parity drive to be overwritten in some fashion would have made replacing a "bad" drive (i.e. my Movies 5TB) unsuccessful assuming that I had another 5TB drive to use (I do not yet).  Yes I have ordered another 5TB drive but don't expect to see it for another week, so if xfs_repair fails, that may be my only option.

 

As it stands, I have just completed a 3 hour +/- xfs_repair -n /dev/sdb1 review/check of the 5TB drive and have posted the results as attachments.  As anticipated the primary Superblock had a "bad magic number".  Thankfully after all that time searching the disk bit by bit, if found a "Secondary Superblock".  If all goes well, xfs_repair can now replace the Primary Superblock by copying the Secondary Superblock and my data (hopefully - all or most all) will be found and restored.

 

That remains to be seen :o!  Will update everyone as soon as I get results.  Finally I would like to commend everyone for their willingness to offer suggestions and hopefully solutions.  I do think the Russ had a great suggestion, that Lime-Tech put in a mechanism to somehow notify the User if a Parity Drive is either not found and/or about to be overridden.

 

Thanks and regards to all, wish me luck!

 

Dave

Screen_Shot_2015-10-28_at_5_59.41_PM.png.0adb92ff02b9716bd127d3fe7ff8ce4b.png

Screen_Shot_2015-10-28_at_6_00.12_PM.png.95296d7731003756bfe5711f7e3291dd.png

Posted

Update and more ?  "xfs_repair" has done its thing!  Well sorta, I printed (pdf style) the Shell Report and it was 237 pages long with lots of corruptions inode re-writes and missing/corrupted sub-directories etc.  Truly, I'm not sure what that means and whether the has been saved or is beyond repair.  I can attempt to copy some of the relevant info for anyone with interest, though not sure how to deliver the data.

 

For the next move, I would love suggestions to the following (highlighted command):

 

Note - stripe unit (0) and width (0) were copied from a backup superblock.

Please reset with mount -o sunit=<value>,swidth=<value> if necessary

Metadata corruption detected at block 0x1ea3db140/0x1000

libxfs_writebufr: write verifer failed on bno 0x1ea3db140/0x1000

Metadata corruption detected at block 0x8015fde8/0x1000

libxfs_writebufr: write verifer failed on bno 0x8015fde8/0x1000

Metadata corruption detected at block 0x2008bc470/0x1000

libxfs_writebufr: write verifer failed on bno 0x2008bc470/0x1000

Metadata corruption detected at block 0x204363698/0x1000

libxfs_writebufr: write verifer failed on bno 0x204363698/0x1000

Metadata corruption detected at block 0x801b5460/0x1000l

ibxfs_writebufr: write verifer failed on bno 0x801b5460/0x1000

Metadata corruption detected at block 0x10d406620/0x1000

libxfs_writebufr: write verifer failed on bno 0x10d406620/0x1000

Metadata corruption detected at block 0x1013bd440/0x1000

libxfs_writebufr: write verifer failed on bno 0x1013bd440/0x1000

Metadata corruption detected at block 0x1013bd478/0x1000

libxfs_writebufr: write verifer failed on bno 0x1013bd478/0x1000

Metadata corruption detected at block 0x800be3d8/0x1000

libxfs_writebufr: write verifer failed on bno 0x800be3d8/0x1000

Metadata corruption detected at block 0x204363698/0x1000

libxfs_writebufr: write verifer failed on bno 0x204363698/0x1000

Metadata corruption detected at block 0x2008bc470/0x1000

libxfs_writebufr: write verifer failed on bno 0x2008bc470/0x1000

Metadata corruption detected at block 0x1ea3db140/0x1000

libxfs_writebufr: write verifer failed on bno 0x1ea3db140/0x1000

Metadata corruption detected at block 0x10d406620/0x1000

libxfs_writebufr: write verifer failed on bno 0x10d406620/0x1000

Metadata corruption detected at block 0x1013bd478/0x1000

libxfs_writebufr: write verifer failed on bno 0x1013bd478/0x1000

Metadata corruption detected at block 0x1013bd440/0x1000

libxfs_writebufr: write verifer failed on bno 0x1013bd440/0x1000

Metadata corruption detected at block 0x801b5460/0x1000

libxfs_writebufr: write verifer failed on bno 0x801b5460/0x1000

Metadata corruption detected at block 0x8015fde8/0x1000

libxfs_writebufr: write verifer failed on bno 0x8015fde8/0x1000

Metadata corruption detected at block 0x800be3d8/0x1000

libxfs_writebufr: write verifer failed on bno 0x800be3d8/0x1000

done

root@Tower:~#

 

Again, thanks to all for past suggestion and any future recommendations.

 

Dave         

Posted

Why not recover the files from the original drives? I see that you repurposed some of them, but is it possible some of the files still might be ok?

 

Thanks jonathanm,

 

Good suggestion, but I had used "consld8" [diskmv -- A set of utilities to move files between disks] which transferred all of my data from my old drives to the one that became corrupted by my STUPIDITY :P (there I said it)!  There is nothing that can be recovered from previous drives or viewed as they were in effect emptied of data by that program.

 

Thanks for the idea, sorry that I couldn't make use of it.

 

Dave

Posted
Why not recover the files from the original drives? I see that you repurposed some of them, but is it possible some of the files still might be ok?
There is nothing that can be recovered from previous drives or viewed as they were in effect emptied of data by that program.
Has anything been written to those drives since they were emptied? If they were reiserfs formatted, there is a good chance they can be fully rebuilt with a reiserfsck scan-whole-partition command.
Posted
Has anything been written to those drives since they were emptied? If they were reiserfs formatted, there is a good chance they can be fully rebuilt with a reiserfsck scan-whole-partition command.

 

Sorry, but the drives were converted to XFS prior to removing most from the Array.

 

All for naught!

Posted

Latest Status & Update - XFS_Repair did its work as prescribed however it appears that all the data that still exists on the disk (now disk4 the 5TB) has been placed into a Lost+Found coded directory (i.e. 2147483809 through 8909186386).  Interestingly, when looking at the Array (started) it lists Disk4 separately along with Lost+Found within the Array.  From a very brief scan of the numerical folders above, some seem to have Data (i.e. 214...809 shows Abba).  I'm still looking for my Movies.

 

While I'd like to recover the Music, My Movies are far more important to me.  Does anyone know of a way to now go from the Lost+Found directories back to their respective "named" sub-directories and locations?  Renaming each of these sub-directories then separating them if possible would be very difficult.

 

Looking forward to replies.

 

Dave

Posted

Latest Status & Update - XFS_Repair did its work as prescribed however it appears that all the data that still exists on the disk (now disk4 the 5TB) has been placed into a Lost+Found coded directory (i.e. 2147483809 through 8909186386).  Interestingly, when looking at the Array (started) it lists Disk4 separately along with Lost+Found within the Array.  From a very brief scan of the numerical folders above, some seem to have Data (i.e. 214...809 shows Abba).  I'm still looking for my Movies.

 

While I'd like to recover the Music, My Movies are far more important to me.  Does anyone know of a way to now go from the Lost+Found directories back to their respective "named" sub-directories and locations?  Renaming each of these sub-directories then separating them if possible would be very difficult.

I am afraid that once items end up in the lost+found folder that means that the directory information that named the files/folders cannot be found.  You can only correct the items by inspection and manual renaming.

 

The 'file' command can be useful as a first start in identifying the file types but you still need to work out the correct names yourself.

Posted

 

I am afraid that once items end up in the lost+found folder that means that the directory information that named the files/folders cannot be found.  You can only correct the items by inspection and manual renaming.

 

The 'file' command can be useful as a first start in identifying the file types but you still need to work out the correct names yourself.

 

Thanks itimpi, I was sorely afraid :-\ of that.  Not exactly sure what you mean by "File" command?  I can see some of the Music Files in various directories (ie ABBA) and have found a few Audio.TS & Video.Vob directories both with or without Names.  It is amazing that only a few seconds basically destroyed years of work!

 

If you are anyone else has a suggestion, I'd be most happy to try virtually anything.

 

Dave

Posted

 

I am afraid that once items end up in the lost+found folder that means that the directory information that named the files/folders cannot be found.  You can only correct the items by inspection and manual renaming.

 

The 'file' command can be useful as a first start in identifying the file types but you still need to work out the correct names yourself.

 

Thanks itimpi, I was sorely afraid :-\ of that.  Not exactly sure what you mean by "File" command?  I can see some of the Music Files in various directories (ie ABBA) and have found a few Audio.TS & Video.Vob directories both with or without Names.  It is amazing that only a few seconds basically destroyed years of work!

 

If you are anyone else has a suggestion, I'd be most happy to try virtually anything.

 

Dave

Linux file command

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...