trurl

No need to build a whole server for a single backup disk. Just mount it with Unassigned Devices and copy stuff to it. In addition to my backup server I also make backups of my important and irreplaceable files to Unassigned drives for storage offsite.

Lots of things diagnostics don't tell us until you start the array. Jul 23 17:38:02 UNRAID root: error: /webGui/include/ProcessStatus.php: wrong csrf_token Close all browser tabs and mobile apps that might have a connection open to your server. Try booting in SAFE mode and see if the problem still happens.

You can put whatever you want on whichever pool you want.

The whole point of different shares is to have different settings for different things of course.

And you must always resolve any parity errors in whatever way is appropriate. Exactly zero sync errors is the only acceptable result.

Monthly should be enough and don't correct. That way if you find out that another disk has a problem then you haven't changed parity unintentionally. If you do get errors that need correcting do that with a manual check with corrections. You should configure with an account that you will check consistently. Don't let one problem become multiple problems and data loss. Check all connections and change ports if appropriate, then Stop array Unassign disabled disk Start array with disabled disk unassigned Stop array Reassign disabled disk Start array to begin rebuild

For example:

Latest beta supports multiple cache pools, so there won't be a need to use UD for this anymore.

You should go to Settings - Scheduler - Mover Settings and disable mover logging. Kind of hard to sort through syslog with all those mover entries. It looks like parity was disabled a couple of weeks ago. What is your parity check schedule? Looks like there might have been a couple of checks since parity was disabled, but they were only read checks since there was no parity to check. Apparently you don't have Notifications configured to alert you immediately by email or other agent when a problem is detected. Do you know how to rebuild parity to the same disk?

Post new diagnostics

I just tested this to make sure. I changed one share which was prefer on one pool to prefer on another pool and invoked mover. Nothing was moved. So it appears that when moving files TO a pool, only array files are considered by mover and files in another pool will not be moved.

Except for that "rip out" part. Hot swap isn't recommended in the array, and wouldn't help anyway since you still must stop the array in order to assign the replacement disk. So stop the array and shutdown to replace the disk. Then assign the new disk to the same slot and start the array to begin rebuilding. More trouble to do it that way with no added benefit. Just keep the original disk until you are satisfied the rebuild was successful.

Is this a disk share or a user share? If a disk share, make sure you haven't accidentally created a user share named for that disk. SMB will only display one of these. This sort of mistake is one of the many reasons I recommend not sharing disks at all.

Not an opinion, a fact. Parity can only help recover from certain (and arguably rare) circumstances. Nothing parity can do about user error, for example.

An rsync script will often take care of it. I use that method to backup shares from my main server to my backup server, and also to make backups to external Unassigned Devices for storage offsite. Check out the script examples in the first page of the Unassigned Devices thread

You can go directly to the support thread for any of your Dockers by simply clicking on its icon and selecting Support.

Since the removed disks are part of parity, parity is invalid until rebuilt without those disks. So there is going to be some process involved which takes some time. Providing an automated way to do it has probably not been a high priority since it isn't often needed and there are well documented ways to do it yourself. Why did you want to "get back some disk bays" though? If the purpose is so you can add larger disks to the array instead of those smaller disks, then there is no need to "remove" anything. Just replace the smaller disks with the larger disks and let it rebuild (one at a time).

That's exactly what I have in both of my servers and they've been working fine for years. Don't know why and I never did but if it works for you fine.

Perhaps @Energen already knows this, but just in case. Parity is not a backup. You absolutely must have another copy of anything important and irreplaceable. Photos are one of those things that are often considered important and irreplaceable. What will you do when your wife finds out you have lost all the baby pictures?

1) You have your own domain, 2) you are using duckdns, and 3) your router has DDNS. You should only need one of these 3. Since your router has DDNS why get the other things involved at all?

Post new diagnostics if you want me to take a look.

The actual cron files for the scheduler are in /boot/config/plugins/dynamix. Maybe something broken there.

SMART for parity looks OK. To rebuild to same disk: Stop array Unassign disabled disk Start array with disabled disk unassigned Stop array Reassign disabled disk Start array to begin rebuild

And I notice many of your disks are relatively small. Possibly they are disks you already had so you decided to put them in too. Maybe they are getting a little old. In order to reliably rebuild every bit of a missing disk, Unraid must be able to reliably read every bit of parity PLUS every bit of ALL other disks. You don't want unreliable disks in your server. I am not inclined to study the SMART reports of so many disks. On the Dashboard page, do any of your disks have SMART warnings (thumbs down icon)?