This topic has been marked solved and closed to new posts due to inactivity. We hope you'll join the conversation by posting to an open topic or starting a new one.
root@Ultra:/# mount --bind / /mnt
root@Ultra:/# du -h --max-depth=1 /mnt
1.8G /mnt/data
There's your issue... /mnt/data should be empty.
Do you have replicate jobs running? It's common that it pushes data to /data even though the data volume is not mounted, filling up the OS volume.
Then, once the data volume is mounted on /data, you can no longer see what was in the folder itself but the OS volume is still full.
As you have temporarily mounted the OS volume back to /mnt, you should check what's in /mnt/data and clear it to free up space on your OS volume. WARNING: Be careful what you're doing, you want to clear /mnt/data, NOT /data (where your actual data volume is mounted)!
Well, of course you aren't entitled to normal support (even if you are willing to pay), since you are running OS 6 on a legacy ReadyNAS. Netgear can offer you a data recovery contract, but that would be pretty expensive.
Perhaps a Netgear mod here will reach out to you and offer to take a look.
The screenshot shows two RAID arrays which correspond to the members of the BTRFS volume created by X-RAID:
md127 = (RAID5) 4x2TB
md126 = (RAID5) 3x1TB
If you download the logs and look inside systemd-journal.log, you should see some lines with "kernel: md" with information about sda3, sdb3, sdc3, sdd3, md127, sdb4, sdc4, sdd4 and md126.
If you share here, it would help understand the current status of your RAID arrays.
In any case, contact NETGEAR Support for a Data Recovery Contract is probably the best chance to get your data back / fix the RAID arrays if you don't have (much) experience with mdadm stuff.
should a disc with high count make the whole raid collapse? And without any warning?
I am NOT saying this is the case here. But the sake of the argument, if you take the case of an erroring disk that corrupts the RAID array, yes a single disk can bring down the whole volume.
There is a lot of misconception around the level of protection given by RAID technologies. Maybe product marketing is partially responsible for the myth that RAID redundancy is enough protection, but technically it's far from being enough. Nothing replaces a good external/offsite backup.
Even regarding backups, there is a lot of misconception. For example, "syncing" between two devices is not a backup. It's quite the opposite, you increase the surface of vulnerability.
The best option for data redundancy is a mix of all things, with the right balance. RAID redundancy, external backups, snapshots/versioning, checksums, etc.
Disaster Recovery and High Availability are yet completely different things. Taking the example of an imaginary and very resilient backup guarantying data integrity. It may allow to recover specific files to an absolute certainty which would make it an amazing backup solution, but may be a pain to recover all data at once or require a huge amount of time to complete, which would make it a terrible solution for DR. A backup has nothing to do with HA.
In your case, based on the logs you showed, as soon as mdadm starts assembling the second sub-array, the kernel spews a lot of call traces. This is exactly the type of situation that RAID redundancy can't protect you against.
I do not know what is happening and one would need to investigate directly on the machine to understand it and explain to you if possible.
I know I'm not solving your problem, but I hope this helps you understand the situation anyway.
