chairezpnx Posted September 22, 2024 Posted September 22, 2024 (edited) Hi everyone I’m really struggling with my server because I’m out of my element and I’m not sure how to proceed, I ask for a little help (I already read some similar posts about this particular topic and tried some stuff but I’m afraid of definitely losing part or all my data if I keep going (maybe I already did, but I hope not) please bear with me as a explain the situation. The incident Apparently last Friday (I was not in home) there was a huge power surge in my area and all electronic stuff was abruptly shut down (including my server). I must say that I have quality UPS’s for my electronics but the surge was big enough to blow the fuse and eventually shut down the server (3rd world problems). I got home to everything turned off (later my neighbor told me what happened) I feared the worst, so I run to my PC and Server, PC started just fine, but the server required a few tries. The technical part of the story (please help) So, I started the server like normal (after few tries), I have the array configured so it could start automatically, so it did. Every share was there and there was no obvious loss of data, but the parity check also started automatically because of the dirty shut down. I must mention at this point (and maybe this would be the part that ultimately condemns my data), apparently the option to “write corrections to parity” was turned on. During the parity check I turned off every docker container and service (shares were online but as far as I remember I wasn’t really using them), after the parity check ended (about 2 days) it threw a bunch of errors detected but apparently it solved everything. I then proceeded to start some of my containers, specifically jellyfin because I needed to create another account and I noticed that some of my movies and series appeared blurred and they threw an error when I tried to play them, the rest of them show just fine and play with no problem. I looked into the share said files were stored and the files themselves are nowhere to be found, after that I noticed that a whole share was no longer listed on unraid (I could still see it in my windows computer, but I had no access to it). I panicked and stopped the array and give it a good old restart, it restarted indeed but the share and the other files were still missing, after a few minutes one of my Disks showed as Unmountabable: unsupported or no file system I panicked even more and desperate look into forums, some suggested to rebuild the disk, which I did https://forums.unraid.net/topic/142226-unmountable-unsupported-or-no-file-system/ after 16 hours there was no progress, then I read that I should check the filesystem of the drive https://forums.unraid.net/topic/151107-unmountable-unsupported-or-no-file-system/ , which I did, then it suggested that I repair the filesystem but I honestly don’t know if It would damage my data even more. Where I stand right now (the sad realization that I’m just dumb with no answers) As of right now, my server is on safe mode with the array started in Maintenance mode waiting for your instructions; I’ll attach the original log I generated at the time (yesterday if i remember correctly) and the last one I just generated right now. I also pasted below the output to the filesystem check of the drive (i just did this). So here I am, stuck and nowhere to go but the forums, hoping some smarter people could help me and hopping I didn’t irreversibly damage/lost my data by my uninformed actions. I really appreciate any help or even if just took the time to read my long post (sorry, I tend to over explain myself when I’m nervous) Check filesystem status output (-n parameter) Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... ALERT: The filesystem has valuable metadata changes in a log which is being ignored because the -n option was used. Expect spurious inconsistencies which may be resolved by first mounting the filesystem to replay the log. - scan filesystem freespace and inode maps... sb_fdblocks 602758316, counted 619772674 - 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 data fork in ino 260167569 claims free block 32521455 data fork in ino 260182554 claims free block 266339519 - agno = 1 data fork in ino 2887666621 claims free block 360958057 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 3 - agno = 5 - agno = 4 - agno = 2 - agno = 6 - agno = 1 - agno = 7 - agno = 8 - agno = 9 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... bad hash table for directory inode 260179046 (no data entry): would rebuild would rebuild directory inode 260179046 - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify link counts... No modify flag set, skipping filesystem flush and exiting. [Original] - servered-diagnostics-20240921-0836.zip [LAST] - servered-diagnostics-20240922-1049.zip Edited September 22, 2024 by chairezpnx Quote
Solution JorgeB Posted September 22, 2024 Solution Posted September 22, 2024 Run it again without -n or nothing will be done, and if it asks for -L use it. Quote
chairezpnx Posted September 23, 2024 Author Posted September 23, 2024 4 hours ago, JorgeB said: Run it again without -n or nothing will be done, and if it asks for -L use it. Thanks, I just did that and restarted the server; my missing share is back as well as the files that were not available before (I still got missing images for those files on jellyfin for some reason, but that’s not really a problem) I’ll paste below the log that the Check Filesystem tool gave me after it finished, in case is there something else I’m missing , thanks again it was something simple apparently but I didn’t knew better. Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... ALERT: The filesystem has valuable metadata changes in a log which is being destroyed because the -L option was used. - scan filesystem freespace and inode maps... clearing needsrepair flag and regenerating metadata sb_fdblocks 602758316, counted 619772674 - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 data fork in ino 260167569 claims free block 32521455 data fork in ino 260182554 claims free block 266339519 - agno = 1 data fork in ino 2887666621 claims free block 360958057 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 1 - agno = 5 - agno = 2 - agno = 4 - agno = 3 - agno = 6 - agno = 7 - agno = 0 - agno = 8 - agno = 9 clearing reflink flag on inodes when possible Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... bad hash table for directory inode 260179046 (no data entry): rebuilding rebuilding directory inode 260179046 - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... Maximum metadata LSN (2:4138746) is ahead of log (1:2). Format log to cycle 5. 1 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.