Both disks do have all the data on them except if you were using X-RAID one of them doesn't have the partition table on it as X-RAID uses a dedicated parity disk. Newer models use distributed parity amongst all the disks.
I just RDP'd to my home PC to check, and I'm using X-RAID. Don't think there's even a choice not to or this NAS.
How can I tell what disk I've removed, parity or not? If I've removed the one with the partition table and I add it again to the array and it gets wiped - what happens? :shock:
Disclaimer: I do intend to backup the data (that's not already backed up offline) just in case. 🙂
If you can read the disk using linux reader and see the data this way, then that is the disk with the partition table on it. If you can't then the partition table is on the other disk. Disk 1 is usually the one with the partition table on it (the left disk)
The readynas will sync the data whichever disk is still in, it doesn't matter.
If you can read the disk using linux reader and see the data this way, then that is the disk with the partition table on it. If you can't then the partition table is on the other disk. Disk 1 is usually the one with the partition table on it (the left disk)
The readynas will sync the data whichever disk is still in, it doesn't matter.
Great.....ok, so that'll just rebuild the PT on the currently installed disk anyway?
And does that mean that if I were to get a disk failure on the disk that DIDN'T have the PT, it would then be unreable with Linux Reader? :shock:
Really sorry for all these questions, but I hope this'll help someone else in the future too.
...the point is that you can rebuild the volume if either disk fails. The nas file system is not designed so that it would be readable outside the nas, although it is possible to do this with some work, just not with with disk 2 in the duo; although this may be possible with the right software and knowledge. With the later 2 bay units you wouldn't be able to read either of the disks with linux reader even though they both have partition tables on them.
The bottom line is that the second disk is not a "backup" and you should not rely on being able to read the nas disks outside the nas itself.
With later 2-bay units you could easily mount the data volume in an ordinary Linux machine if you have one using either disk or both disks (assuming the disks and array are fine).
...the point is that you can rebuild the volume if either disk fails. The nas file system is not designed so that it would be readable outside the nas, although it is possible to do this with some work, just not with with disk 2 in the duo; although this may be possible with the right software and knowledge. With the later 2 bay units you wouldn't be able to read either of the disks with linux reader even though they both have partition tables on them.
The bottom line is that the second disk is not a "backup" and you should not rely on being able to read the nas disks outside the nas itself.
Ah right, so it'll still rebuild anyway, just disk 2 isn't readable - good to know.
mdgm wrote:
With later 2-bay units you could easily mount the data volume in an ordinary Linux machine if you have one using either disk or both disks (assuming the disks and array are fine).
Might be worth investing in a newer one soon then 🙂
When you say "ordinary Linux machine", does that mean they would read with Linux Reader also?
I was referring to e.g. a Debian/Ubuntu x86 machine not a Windows PC running software e.g. Linux Reader. From what vandermerwe said above it sounds like Linux Reader doesn't handle md devices.
Yes, a number of forum members have tried to read a disk from non sparc 2 bay units, without success. I think StephenB has also reached the conclusion that Linux reader only works with the sparc units disks.
I think there is software for Windows that will handle md devices, but not sure if there is a free option.
With Linux you can install the necessary packages if they are not pre-installed and use them all for free.
Sounds like something I should get more familiar with, so I don't get those panic moments when something goes wrong with the NAS, and I'm sat staring at a disk in my hand, wondering what to do next! 😄
Is it worthwhile freeing up as much space on the OS partition now, to avoid any potential future problems? Can I just blitz all the log files? If so, please advise.
Thanks.
Update: I'm copying everything to backup drive now.....11MB/sec zzzzzzzzzzzz
The saga continues...... whilst copying all the data off, and to be fair I had a few folders copying at once, the nas decided it didn't want to leave the shares visible. I went to check the nas physically, and the hard drive light was just flashing, rhythmically. Clearly it wasn't happy, so I tried to gracefully shut it down from the power button. No joy, so had to pull the power lead. When it powered up, it rightfully started a disk check. This started over 9 hours ago, and is still on 2% on a 2tb drive, and the drive light doesn't really imply it's doing much 😞
Any thoughts please anyone? I'm on the verge of just factory resetting it, and copying the data back over, using Linux Reader on the PC, to the blitzed nas.
It sounds like there are issues with the filesystem on the data volume.
You could try booting skipping the filesystem check.
Ah, I saw that as an option of the "boot menu" list. If I skip this, and regain access to the GUI and shares, do you reckon it'll still resync fine if I put the (perfectly fine and readble) disk back into a powered-on NAS.
I've backed up all the data now anyway, but I just want to learn as much from this, rather than just Factory Reset it and start again.
Given the state of the filesystem I would suggest doing a factory reset with both disks in the NAS and restoring the data from backup.
It's looking that way 😞 Looks like another night of progress bar watching for me. Thanks for all the help getting the OS fixed though, it's greatly apppreciated.
Is there a fix or add-on that prevents the log files filling up the OS partition? I thought I read some time ago that you could change things so the files would be written to the DATA partition. This happened to me too last time I tried to do a backup and I had to SSH in and delete the log files. It would be very helpful to have some info on how to correctly deal with settings for the log files.
Is there a fix or add-on that prevents the log files filling up the OS partition? I thought I read some time ago that you could change things so the files would be written to the DATA partition. This happened to me too last time I tried to do a backup and I had to SSH in and delete the log files. It would be very helpful to have some info on how to correctly deal with settings for the log files.
+1
I did think it would be very benefical to have a truncate log file setting in the UI to prevent this happening again in the future. The lack of space actually caused an update to fail initially, which was the start of my long aventure of progress bar watching.
No way of configuring a maximum log file, or log location, via SSH?
The logs are truncated automatically on schedule, apart from backup job logs (you may lose valuable info on backups if you truncate those without being prompted).
However if say entries are made excessively e.g. every second, a log file may fill up the OS partition before it can be truncated.
You can move e.g. the ReadyDLNA cache directory to the data volume.
Moving log files even if possible wouldn't be a good idea. The logs can be crucial in situations where the data volume won't mount and if the data volume doesn't mount and logs are on it then they are useless.
