Dazza993

Thanks @itimpi I've download a licensed copy of UFS explorer and gradually moving data from the reformatted drive onto a removable SSD attached to my Mac and then moving data back to the array. I've seen some files are corrupted still but something is better than nothing. Thanks to all for your input, advice and guidance.

Thanks @itimpi I'll give UFS explorer a try on my Mac once I get back from holiday.

Thanks for the continued support on this subject. The 14tb that I thought might have updated from the parity drive was unusable due to the filesystem mismatch to to get my array in a working condition that's formatted as XFS. As I have the Plus license of unRaid so would it be worth trying the 6tb drive originally formatted with reiserfs into the array? I'm guessing if it won't mount as an unassigned drive it won't mount as part of the array. If that prompts to be formatted as ReiserFS , would that overwrite all of the disk or does it just flag part of the disk as the filesystem to use? I could tolerate a partial loss of data so long as that approach got most of the data back, or would I be best using UFS explorer, and if I do decide to get that, how does that work? Can it be a plug in or dockerised app for Unraid, or can I install that on Mac OSX or does it need windows - and if it's the latter two, I guess I need to put the drive into an external caddy and connect to either my Mac or a Windows PC? Thanks in advance again.

When I tried to mount the original 6gb drive that I messed up, which is now shows in unassigned devices I get this when I try to mount it Does this give any clues to what might be wrong?

The rebuilt against the new drive finished but it shows as unmountable Reiserfsck is still giving error Unknown code er3k 127 so looking at another thread where some did the same as me I spotted the xfs_repair command. So running xfs_repair -nv /dev/sde1 I do get a readable output. Could it be worth trying to run xfs_repair without the n option? Or is it worth trying stop the array, edit the drive and change the format back to XFS? I'm grasping at straws I know

I've switched my new 14tb disk into disk position 1, replacing the one I was trying to change from reiserfs to XFS and it's showing the FS as ReiserFS and doing a data rebuild. Might I be lucky enough to end up with data on the new drive (albeit using the wrong format of reiserfs) at the end of the rebuid? If so I can worry about sorting that out later - which I guess involves coping the data off to one of the old 6gb drives (one reformatted to XFS) and showing as empty - then reformat the new 14tb drive and then copy back?

Would it be worthwhile, putting my new 14tb drive into the array as Disk 1 (replacing the one drive I tried to move from reiserfs to XFS) and then use unassigned devices to see what I can see on that old 6tb UD drive? If I did want to try and earlier version of unRaid, am I like to run into any issues doing that? On other posts others seem to have had similar issues and getting the same error code. On that thread the user has tried using unassigned devices to copy files off using MC I'm keen to make sure I don't make the problem any worse

Attached are the logs after running reiserfsck --rebuild-sb /dev/md1 I've also ran the blkid command and that's still showing as all devices being XFS - but the device in question MD1 does show as being reiserfs in the UI Many thanks birchestower-diagnostics-20221017-1053.zip

I've looked at the thread above and another but whenever I try to use the command reiserfsck --rebuild-sb /dev/md1 I'm getting the error below. Unknown code er3k 127 Looks like I'm running reiserfsck 3.6.27 With the array stopped I'd changed the format from XFS back to ReiserFS and started the array in maintenance mode. Is that correct or would I need to start normally and do another format back to reiserfs back from XFS for the reiserfsck program to work correctly. Thanks for the input so far.

Thanks I'll take look at that thread. Fingers crossed

So I only formatted the data drive after the parity disc had been rebuilt so as far as I can see, the parity drive has all the information before I formatted the data drive. I've not run any parity checks since I formatted the data drive. If I had simply replaced the data drive with a new disk, it would have been able to rebuild the data drive. As soon as I've reformatted one of the data drives, will that have updated the parity drive, so that there's nothing available to rebuild? I understand that parity isn't a backup, but if I can pull one data drive and replace with new/empty one parity can be used to reinstate that data drive - or am I missing something?

Afternoon everyone, Looking for some help as to whether I can recover data on one of my data drive after I changed the filesystem type. I recently bought a pair of larger (14tb) drives to replace the parity drive and one of the data drives in my array. Replacing the parity went as planned. I'd precleared both new drives, shut down the array and brought in one of the new drives as parity and after 24 hours or so the new parity disc was up and running. All good at this point. One of the 3 data drive I had was formatted with ReiserFS which I wanted to switch to XFS. I stopped the array, went into the disk that was formatted with ReiserFS, changed it to XFS and restarted the array asking it to reformat, thinking it would format the drive then rebuild from parity. The drive that was ReiserFS now shows as XFS but it's also showing a lot of space free so I don't think any rebuilding took place. Have I lost the data on the drive forever or can I somehow force a rebuild of that disk using the parity. No data has been added, changed or deleted from the array since I've done this. I have available the other 14tb disc as an unassigned device at present (precleared and ready to go) if that can be of any use. I'm on version 6.11.0 at present. Thanks in advance

Yes, I think the correct terminology is to have a 2nd cache pool - so 2 pools, one with the 2.5 SSD and the other with the NVMe SSD I'm not to precious about anything downloaded to the cache pool but not moved to the array being lost but any VMs and their associated data I'd wanted backed up. I presume I could keep a backup of the NVMe apps and appdata folder on the array itself? (just manually backup every so often)

Hello everyone, Currently I have an unRaid setup on an HP Gen8 MicroServer that has 4 x 3.5 WD Reds as data & parity discs plus single 2.5 250gb Crucial SSD as the cache drive. I use that single cache drive for download files to and where I've got my docker apps & app data installed. I'm building a replacement for the Gen8 with the capacity to add more 3.5" drives and I've also gone for a new Mobo & CPU as I want to run one or two Windows VMs My new Mobo (ASRock X570M Pro4) as NVMe support, so could anyone confirm if I'd be better off getting a decent NVME SSD to put the docker apps and app data on and leave the 2.5 SSD purely as a download cache? I'm thinking about a 1tb NVMe drive - possibly a WD Black. Would this be the best approach and any SSD drive recommendations would be welcomed. If I do go down this route I guess it's fairly straightforward to move the existing apps/docker directory to the new drive? Thanks in advance

I’ve opted to build my custom unRaid server with the ASRock X570M Pro4 and the Ryzen 5600G Not yet built as awaiting case and memory but the 8 Sata ports were a big plus for me along with the M.2 slots for when I want to upgrade my cache drive It also seems to have decent power control