apandey

So, basically, you want to remove the 2TB drive from array when moving to new board. Does it have any data on it? Where is unraid telling you this? Please share the actual error. What do you see on top right of unraid GUI - trial or your license? You can always download the license key from MyServers plugin when logged in using your ID (Obviously, it needs internet connection) Since you are removing a drive, you will need to do new configuration (Tools -> New Config) and rebuild parity. Make note of the disks and their slots assignment in existing config so that you don't mix up parity and data drives (you cannot in your case, since they are easy to identify due to different capacities), but be careful about that. Do NOT format any data drive at any point, just rebuild parity after new config You will of course need to copy over any data you had on 2TB drive manually after your array is online Should be a different issue. See if you have network.cfg and network-rules.cfg in the config directory on your flash drive. Deleting them will reset your network to default DHCP which might be able to start you over on new hardware. Perhaps your network interfaces are not same on new motherboard. This probably should be the first thing to fix as this allows you to reinstate your registration key I assume you are using "same" boot USB, as registration key is tied to physical USB drive

that probably explains why I cannot troubleshoot my lack of spindown. I see my parity drives spindown, but data drives don't, so it must be read activity. Is there a good way to look for reads only? Also, would help if there was a way to only track a specific disk in array, sometimes it's easier to just focus on one disk where you dont expect activity and not be buried by logs from another disk where you do expect action

when you add a disk, switch to manual assignment and use /dev/disk/by-id/xxxxxxxx path to the disk to use it. by-id ensures that you get same disk irrespective of its diskX assignment in unassigned devices also see this if you need to understand better

Main tab, boot drive section, browse files using the icon on right end of your USB flash drive. Files are under config directory In terminal, they are mounted at /boot/config Or you can shutdown unraid, take USB flash drive to another computer. Files are under config directory Deleting those 2 files will reset the network to default settings. If you have a DHCP server on network, it will assign unraid an IP which you can use to connect to Web UI. If not, you can use an attached monitor to setup manually I am not sure what you are trying to do, your network config looks confusing. For example both br0 and br2 seem to be assigned the same 50.200 IP

Does your motherboard support pcie bifurcation on the slot you added the card to? You need to bifurcate to 2 separate x4 channels to be able to use 2 drives. The Asus hyper m. 2 does not have an onboard plx switch to bifurcate itself

Perhaps try the support thread specific to tailscale container

Normally you should not do this, as this can conflict with any mover activity and bypass shfs which unifies the file systems across cache pools and array If you directly addressed pool or drives like this before, it might explain how you ended up with 2 copies

This is normal

Looking at timestamps, the one one nvme looks more recent. I would simply delete (or move elsewhere as backup while you figure this out) the system share from disk13 if everything it has exists on nvme cache. /mnt/user/system should then pick whatever is up on nvme This is assuming system share uses the nvme cache If your nvme cache is protected by raid, ideally it should not complain. If the cache is single disk, then of course it is unprotected once the files are on cache

yes, it is most likely a BTRFS RAID1 pool, with 1 disk redundancy. You can confirm by clicking the cache drive settings in Main tab in unraid UI. Under balance status, it would say filesystem type as for what is better, it depends on your usage. If you prefer 2 separate independent pools without any drive redundancy, thats fine too simplest is to make appdata as a cache "only" (see share settings) share. or create a separate cache "only" share and point plex container metadata mount point to it if above terms are new to you, read the respective parts of unraid manual and ask more questions here

i cannot see what drives you have, they seem to to be hiding behind the FTS PRAID controller. RAID controllers are not supported for unraid Is there any other read / write happening on your array while parity is building? that will slow things down a lot Are you mixing HDD and SSD on the array now - your writes will be limited to slower of the speed of data and parity drive. reads may still get faster if data disk is SSD

Are you doing anything intensive on that VM that needs dedicated cpu resources? I always start with no isolation / pinning and only look at this when I encounter a cpu saturating workload

The flash drive only contains the OS binaries and your unraid configuration, which gets unpacked on boot and runs completely from RAM after that (except for any config updates etc that may need to be written back to usb) The actual data itself sits on the drives. If that is corrupted, the best bet it to identify what corrupted it, remove that first (a fresh USB drive will help if the Ransomware was injected via OS, it won't help if it's running from a computer connected to the share) As for data itself, the cleanest way is to restore from a backup once you have fixed the attack itself

One can setup a mDNS reflector or repeater to cross across networks, but have to be careful with this to avoid any nasty broadcast storms and security concerns (which are inherently why it works local network only by design)

I keep my basic network firewall (pfsense) on separate hardware from unraid. That is a lot more secure and flexible when it comes to reliability, maintenance etc. The more things I have going on unraid, the higher the chances of something needing maintenance or breaking occasionally due to ever increasing complexity. It's good to know I have connectivity when that happens

Given you are running into problems frequently, might be good to revisit your cables / connections etc. Both power and data. That is probably the only common thing here

It's a more involved flavor of "I'm feeling lucky" search. It makes life a box of chocolates, you never know what you are going to get Worth asking "how sure are you" after every reply

If you want to try recovery, I would suggest to image the entire disk and work on the copy of the image mounted somewhere. That way you can restart if a recovery software makes a change and it doesn't work out

No, absolutely not. Format is never a part of data recovery. It is a write operation which irrevocably removes any chances of recovering data because from that point on, the new correct state of drive is formatted and empty Did you run a correcting parity check? Did you add the drive back into the same slot in array? I suggest you don't so anything else for now and post diagnostics first so someone can suggest a next step

All of the examples you are giving are basically backup of some form. So you are arguing for an inbuilt backup system in unraid? Perhaps that can be a feature request. I don't see a backup solution has to necessarily come from changing the meaning of cache pools I gave you the negative effect of multiple copies of data, which leads to data synchronization issues. I see it as xy problem because you are trying solve backup via a mechanism that isn't built with that focus Cache pools are not inherently unprotected. They are just not protected by unraid parity. They can still be protected by whatever filesystem redundancy they are built on. I currently run btrfs raid1 pools, which are protected against drive failure. They can still have filesystem corruption, but parity doesn't protect from that either. A backup does. I might move my pools to zfs after 6.12 Here is how pools are planned to be evolving for now: All the examples of not touching array directly also go against what you can do with unraid today. We have a mix of new and power users Not any more than data sitting in array itself and not having a cache at all. What happens if you delete anything in that case? Do we suggest users protect themselves against that by setting up a backup / recycle bin mechanism or by setting up a cache (which by now should be clear is not meant to backup data). We do have occasional users who incorrectly assume unraid array has a copy of their data in parity drive that they can recover in such cases, and that is not too far away from this example I can also argue that deleting data without correctly understanding whether you have another copy somewhere is asking for data loss at some point. Manual user operations can only be protected to an extent

If you go into the history of term, you will discover that if buttons are spaced out, the human phenomenon it describes will still exist and we would find a new term to describe it - perhaps bumpy elbow or sleepy head. Mother nature gave the ability to make the most unexpected mistakes and we just have to spent enormous time teaching computers how to work around that I am now more convinced that this is indeed an xy problem. While recycle bin can be a proper solution to the issue at hand that will reliably work, cache is by luck at best. What happens when you delete a file that hasn't been copied over to array yet? Oops again?

Well fine, but then that is a breaking change and not something I would want given I don't expect to have copies of data that can be managed independently by a unsuspecting user That could be a solution, and fairly independent of reinventing the cache. Seems there is a recycle bin plugin for shares, though I have no experience using it It would then have to deal with data synchronization issues. All the issues that a backup system has to deal with, while avoiding a backup system in place that would have solved the underlying issue at hand properly. What happens when someone unsuspectingly updates the array copy of data because they worked at drive level rather than share level. Will their changes be overwritten at some undeterminate point in time later? Fat Fingers come in many forms I use cache only share with a backup to array when I explicitly need that setup (like appdata backup plugin provides). That works without making cache pools any more complex or ambiguous. Would that achieve what you want? Indeed, going from a mergerfs type implementation to a clone-backup model is fundamentally a different system, so just making sure we are not dealing with an XY problem BTW, seems the plan on unraid is to drop the confusing cache terminology and just work with pools as first class objects that can be setup with mover relationships against shares. Maybe that will avoid some confusing that it may be a cached copy

Your observation is still making an assumption that the cache has a separate copy of data. That is not how cache is intended to operate in the first place. Cache is not a backup, if you need to protect against data loss due to fat finger operations, you need a backup. Also, array stop isn't specifically a data management operation. I rarely stop my array, so what you suggest would rarely happen to me To top it all, I would not expect a prefer share to move out of cache to array anyway, as long as cache has free space. That is what prefer means

I have 2 macs backing up to same share. But my share is on a dedicated backup pool with “Only” setting, so the mover never touches it