Disk Unmountable After Outage

[trionify]

Hello,

 

Earlier today I was playing around with my networking and accidently partially unplugged my router (While UNRAID was performing cloud backups). Didn't think much of it so I plugged it back in. Coming back to UNRAID, I noticed one of my shares was missing, and the backup started to fail.

 

Turns out disk3 had issues and no data could be read off of it. I've tried rebooting (twice), and currently running SMART tests on all disks.

 

My last re-mount of UNRAID indicates disk3 is unmountable and needs to be formatted. Is there anyway I can retrieve my data? I do not have a backup of it - it was running at the time!

 

Greatly appreciate any help.. attached are diagnostics and logs.

 

Unraid version: 6.2

skynet-diagnostics-20160924-1511.zip

skynet-syslog-20160924-1516.zip

[Squid]

https://lime-technology.com/wiki/index.php/Check_Disk_Filesystems#Checking_and_fixing_drives_in_the_webGui

[trionify]

https://lime-technology.com/wiki/index.php/Check_Disk_Filesystems#Checking_and_fixing_drives_in_the_webGui

 

Thanks, running the check right now with -nv. Hope this can help fix my issue.

[trionify]

Here are the results of the check.

 

Phase 1 - find and verify superblock...
        - block cache size set to 3019632 entries
Phase 2 - using internal log
        - zero log...
zero_log: head block 3642972 tail block 3642681
        - scan filesystem freespace and inode maps...
Metadata corruption detected at xfs_agf block 0x74702f99/0x200
flfirst 118 in agf 1 too large (max = 118)
agf 118 freelist blocks bad, skipping freelist scan
sb_icount 130944, counted 132544
sb_ifree 41932, counted 36701
sb_fdblocks 130966721, counted 129739799
        - 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
        - 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 = 3
        - agno = 2
No modify flag set, skipping phase 5
Phase 6 - check inode connectivity...
        - traversing filesystem ...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - traversal finished ...
        - moving disconnected inodes to lost+found ...
Phase 7 - verify link counts...
No modify flag set, skipping filesystem flush and exiting.

        XFS_REPAIR Summary    Sat Sep 24 15:26:37 2016

Phase		Start		End		Duration
Phase 1:	09/24 15:26:10	09/24 15:26:10
Phase 2:	09/24 15:26:10	09/24 15:26:13	3 seconds
Phase 3:	09/24 15:26:13	09/24 15:26:28	15 seconds
Phase 4:	09/24 15:26:28	09/24 15:26:28
Phase 5:	Skipped
Phase 6:	09/24 15:26:28	09/24 15:26:37	9 seconds
Phase 7:	09/24 15:26:37	09/24 15:26:37

Total run time: 27 seconds

 

If I understand the documentation correctly, it created a lost+found folder because the corruption is slightly more significant?

[Squid]

lost+found will be files that xfs knows existed on the drive, but can't figure out which folder or filename they were.  You can open them and see what they were and put them where they belong

[trionify]

lost+found will be files that xfs knows existed on the drive, but can't figure out which folder or filename they were.  You can open them and see what they were and put them where they belong

 

Thanks for your help. I just ran the repair again with '-L', no lost and found on my disk anymore. But it's able to mount and I think everything is there.