What's the problem, the output from cat /proc/mdstat says the array is active, so it should be listed under raid management
Beiträge von geaves
-
-
I couldn't say, the one who can answer you best is Geaves
Not sure, my thought was to remove one of drives that was reading no uptodate device, restart the server and look at mdstat and mdadm --detail was the other drive with no uptodate device now being read correctly and was part of the array again.
But if it still registered with the same error and as a spare then the array is toast and there's nothing more to be done.
The difficulty we have as a forum of users is information about what hardware works and what hardware to avoid, or use at own risk. The second problem is the cheap Chinese stuff which has no name, if users want to extend their drive capacity a raid card flashed to IT mode is a safer bet that than these pcie expansion cards.
-
Well thanks guys, I'll bow out of this one then, I really should ask before I get involved what hardware is the raid set up on
Courtyard yes you were lucky, sometimes that happens, but when it goes wrong it goes wrong big time, but I commend you for having a backup even if it's not a complete backup, you have something to restore
-
Ok you've restarted the server as the drive references have changed
The drives in the array are currently [cdef] sdd and sdf are showing as spares, this is one of the issues, the second is #9 the error -> no uptodate device for slot 1 and the same for slot 3
Going back to your initial post where you stated Steam reported disk errors, this could be i/o errors which could be related to hardware issues where the data being copied is experiencing intermittent write problems to the drive/s.
This could be either the drive/s themselves or the connectivity of the drive, sata cable, power cable, backplane (backplane is a drive bay where a drive is plugged in i.e. 4 port drive bay these typically have/use a backplane.
Can you give some info in relation to how the drives are connected, this might be a hardware issue.
But I don't get it... Why
If this is hardware related it would explain why it 'just happened' if it's drive related one would have expected SMART issues warning of a possible problem
-
mount -t ext4 /dev/md0 /mnt/md0
good luck with that, OMV does not mount it's filesystems under /mnt
-
Perhaps more information in your first post would have been helpful, especially regarding hardware and testing.
AFAIK the implementation of a BTRFS raid is now based upon profiles and not mdadm with the BTRFS file system on top, which a user could do previously versions
If you implemented the raid setup using debian so that you could achieve a raid boot device and you create the btrfs there this might explain the problem. But, OMV uses the full block device (drive) to create an mdadm array and btrfs profiles so in the GUI there is no option to select partitions.
-
Added to that the drive sizes are mismatched
-
What hardware are you running OMV on
-
Well there's nothing to work with, there should be some output from cat /proc/mdstat and mdadm --detail and there isn't, but there could be some corruption to the omv device.
First try simply restarting the server from OMV's GUI, check raid management and cat /proc/mdstat if it's still in the same state (you're looking for some output) then ->
Disconnect all the drives and reinstall on a another drive/usb flash drive, set up and update OMV, shut down and connect the data drives and check again
-
The boot-drive (a SSD) was no longer sda but instead sdc, and the HDDs in the RAID was no longer sdb, sdc and sdd but instead sda, sdb and sdd
That doesn't matter it's the order in which the o/s detects each device.
Why shutdown, the purpose of a server is that it's left running.
That array is inactive so ssh into omv and run:
mdadm --stop /dev/md0
mdadm --assemble --force --verbose /dev/md0 /dev/sd[abd]
the array should rebuild
-
Looking at that output it's not recoverable, even though it's it's marked as clean, it's clean because 2 drives are registered as part of the array and 2 as spares, and I'm guessing you don't have a backup.
Run this on each drive, mdadm --examine /dev/sd? replace the ? with the drives reference e.g. /dev/sdb etc. post in separate code boxes need to see event count
-
However, if the "Balance Tool" is used once (even accidentally) that might explode the Docker folder over all drives in the array, ruining the Docker install.
Ah, didn't know that, I just assumed one could just use a single drive within the pool if a single was not available, won't mention that one again
-
mdadm --stop /dev/md127
mdadm --assemble --force --verbose /dev/md127 /dev/sd[bcde]
any errors post in full please, but it should be ok
that should reassemble the array, you may have to mount it in file system once the rebuild has completed or just reboot, but it may come back up without intervention
-
Posting a screenshot is not very helpful you need to ssh into OMV, copy and paste the output into a code box so it's readable
Code box, this </> on the forum toolbar.
But a quick look tells me the array is inactive
-
Any suggestion how can we bring back in this situation the last part of my NAS, the 'md2'
No, not possible......a Raid5 allows for one drive (partition) failure within an array, 2 and the array is toast, drive failure could be the drive going dead, intermittent i/o errors or superblock errors.
Normally there is a backup superblock on the drive/partition which one can attempt to restore to recover the superblock, but I have found attempting with other users on here has never worked. In your case this line:->
mdadm: No super block found on /dev/sdd1 (Expected magic a92b4efc, got 00000000)
gives zeros that's something I've never seen before on here nor from real world experience.
You could try searching for mdadm no super block found and you could try the various suggestions you will find but IMHO md2 is toast and any data on it has gone.
---------------------------------------------------------------------------------------------------------------------------------------------------
If you have backed up your data from the other two arrays to one of your 6TB drives at least that's a step in the right direction
The problem you have is your drive size mis match, from the information you have supplied
3 x 500Gb
2 x 2TB
2 x 3TB
2 x 6TB
I can see now why your friend did what he did and use partitions to maximise the space available, but as you've discovered when things go wrong it's spreads across all the arrays.
OMV uses the full block device (drive) to create an array using the GUI (OMV uses the KIS principle)
A Raid5 is made up of a minimum of 3 drives, lets say you create a Raid5 from 2 x 2TB and 2 x 3TB, the array will be create based upon the smallest drive/s within the array, so 2 x 2TB and 2 x 3TB will give you -> 6TB data capacity. But what you could do in the future is to replace each of the 2TB drives with 3TB drives and grow the array, giving you 9TB data capacity.
Your 6TB drives would then be used for data backup, this is a common failing amongst home users, they believe because they are using a Raid a backup is not necessary.
As for the 500GB drives they are really not worth using, I use a 300GB laptop drive in my system but that is purely for docker, docker compose and container configs as I use zfs.
Another option is to use mergerfs this would pool the 2 x 2TB and 2 x 3TB giving you 10TB of space, most use mergerfs with snapraid, however, snapraid was written primarily for use with large media files, whereby the data is not being changed on a regular basis. This is another learning curve and should not be used as a 'that sounds like a good idea'
I don't know enough about mergerfs but I'll tag a couple of users who may be able to help crashtest chente one caveat using mergerfs you will need to use one of those 500GB drives for docker, docker compose and docker configs, rather than point docker configs to a single drive within the pool. The 6TB drives would still be your backup drives and this can easily be set up using rsync.
-
No I don't see my array only in detail.
Post an image of raid management
-
I tried to add it in the GUI to extend my volume but it remains as spare
to add it to an array you would grow the array, does the drive show in the list of drives if click remove -
Ok, looking at the output you have a spare in /dev/md1 that drive is dev/sdh whereas in your first post the drive was /dev/sdb that would suggest the system has been rebooted.
If you are looking at adding /dev/sdh to the array /dev/md1 as a working data drive you can't until it's actually failed then removed from the array so it's no longer an active spare.
TBH this must have been added manually, I don't think omv allows a spare to be added using the GUI
In raid management you can remove a drive from an array, select the array and from the menu click remove, if the spare shows in there then is can be removed from the array, if it doesn't it's the command line
Please set your omv version in your first post
-
I'm sorry but your post is a little confusing, post the output of the following using a code box this symbol </> for each command;
cat /proc/mdstat
blkid
mdadm --detail --scan --verbose
-
If you compare each output /dev/sdb (partitions /dev/sdb1 /dev/sdb2) are missing from md126 and md127, this would suggest a failed drive
