[SOLVED] My unRAID is a MESS... Please HELP!

[Joseph]

8 minutes ago, pwm said:

No, you can have more lost files.

 

And you don't know if other files are intact or not - XFS can checksum the meta-data but not the file data.

 

That is a reason why it's good to keep hashes for all static files, allowing you to regularly validate the file content.

And - of course - why it's also good to have a working backup scheme that takes into account file changes and not just overwrites a good backup file with a corrupted copy.

ok... so I definitely have my work cut out for me in 2018 by building a backup server and implementing a backup scheme.

 

I think at this point I'm just going to shut it down and will wait to rebuild disk3 and disk5 until after the new year when I have more time to give my attention to it... too much going on right now to deal with another 'crisis' if one were to happen this weekend.

 

Thanks for your assistance!

[JorgeB]

IMO your best bet to recover as much as possible would be to format current emulated disk5, but before copy current lost+found folder if you see some usable data there, mount actual disk5 and copy all data from it, since although the previous rebuild failed it might still have some good data, then overwrite it with the old backup disk5, doing this should make all old data (on the backup) OK with hopefully some new data not on the old disk also OK.

 

[Joseph]

7 hours ago, johnnie.black said:

IMO your best bet to recover as much as possible would be to format current emulated disk5, but before copy current lost+found folder if you see some usable data there, mount actual disk5 and copy all data from it, since although the previous rebuild failed it might still have some good data, then overwrite it with the old backup disk5, doing this should make all old data (on the backup) OK with hopefully some new data not on the old disk also OK.

 

sounds like a plan. Will attempt sometime in the next week or so.

[Joseph]

On 12/31/2017 at 2:34 AM, johnnie.black said:

IMO your best bet to recover as much as possible would be to format current emulated disk5, but before copy current lost+found folder if you see some usable data there, mount actual disk5 and copy all data from it, since although the previous rebuild failed it might still have some good data, then overwrite it with the old backup disk5, doing this should make all old data (on the backup) OK with hopefully some new data not on the old disk also OK.

 

 

UPDATE:

 

* Disk3 has been rebuilt (again, nothing on it, because of... format! grr!)

* Contents of emulated Disk5 have been moved onto physical Disk3.

* 'OLD' Physical Disk5 is in a USB carriage and I'm trying to get it to mount, to attempt your above suggestion; however for some reason it won't.

* An icon I clicked on from the unRAID main page started an xfs_repair on it and here's what it reports:

FS: xfs

/sbin/xfs_repair -n /dev/sdq1 2>&1

Phase 1 - find and verify superblock...
Phase 2 - using internal log
- zero log...
- scan filesystem freespace and inode maps...
- found root inode chunk
Phase 3 - for each AG...
- scan (but don't clear) agi unlinked lists...
- process known inodes and perform inode discovery...
- agno = 0
- agno = 1
- agno = 2
- agno = 3
- agno = 4
- agno = 5
- process newly discovered inodes...
Phase 4 - check for duplicate blocks...
- setting up duplicate extent list...
- check for inodes claiming duplicate blocks...
- agno = 0
- agno = 1
- agno = 2
- agno = 4
- agno = 5
- agno = 3
No modify flag set, skipping phase 5
Phase 6 - check inode connectivity...
- traversing filesystem ...
- traversal finished ...
- moving disconnected inodes to lost+found ...
Phase 7 - verify link counts...
No modify flag set, skipping filesystem flush and exiting.

And a shining green button when the cursor is on it -- daring me to push it -- that says "Run with CORRECT flag"

If memory serves this is the same procedure I went through with the Disk5 emulated disk. So, my thoughts are to skip this step and just use the backup disk to refresh the Disk5 contents now residing on Disk3. But what are your thoughts?

 

As always, your input is MUCH MUCH MUCH appreciated!!!

 

Thank you!!

[JorgeB]

You should remove to no modify flag and try to fix, damage might be minimal, and not the same as the emulated disk which was severely corrupt.

[Joseph]

On 1/15/2018 at 5:04 AM, johnnie.black said:

You should remove to no modify flag and try to fix, damage might be minimal, and not the same as the emulated disk which was severely corrupt.

 

UPDATE:

* Rebuilt disk3 by parity

* Moved emulated contents of disk5 to disk3

* Moved contents of old disk5 to disk3

* Rebuilt disk5 by parity

 

Next Steps: Copy contents of the 'backup' disk5 to disk5; try to recover contents of disk3

 

So it looks like things are slowly getting back to 'normal' (minus the initial format of disk3 fiasco)... before marking the issue as solved is there something I can do to test to ensure replacing the power supply was the solution?

 

[JorgeB]

4 minutes ago, Joseph said:

is there something I can do to test to ensure replacing the power supply was the solution?

Only time will tell, just keep using the server normally.

[Joseph]

1 minute ago, johnnie.black said:

Only time will tell, just keep using the server normally.

Thanks again!! Marking as solved.

[Joseph]

I found a tool online that is helping to identify corrupt media from the failed disk3 recovered files. As I understand, the tool remuxes the video and keeps a log for each attempt. The logs then reveal if it had to abort because of an error. I made a .bat file to run it on a folder. It might be a benefit to someone else if they find themselves in a similar situation (see attached) fyi, found here:

https://hardforum.com/threads/test-corrupt-mkvs.1640664/

for %%I in (PATH\*.mkv) do (
eac3to.exe "%%I" -check
)

replace PATH with the actual path.

the tool must be run from a different location than the PATH

 

If someone smarter than me can figure out how to move the files that failed to another folder, please let me know.

eac3to.zip

eac3bat.bat