itimpi

If one is talking about a replacement strategy then there is probably minimal risk on any sensible approach as long as for each stage one keeps the removed (good) disks intact until that stage has successfully completed as you then have the original disks available as your fallback strategy.

You also need to fill in the Remote Syslog server field with the IP of your Unraid server so the server logs to itself as you want it to be both server and client.

Regardless of whether you sort out the parity speed issue you might want to consider installing the Parity Chevk Tuning plugin so you can trade off elapsed time for the check for avoiding it impacting daily use of the server.

The biggest enemy to USB drives is heat, so you want drives that run as cool as possible. this tends to mean USB2 is preferred over USB3, small form factor drives should be avoided, and ones with good heat dissipation (e.g. metal cases) are a good idea.

The My Servers will backup the current flash drive any time you make a change. What it does not give you is a set of dated backups so you can select a particular restore point. There should not be any measurable change in flash drive usage when running docker/VMs unless you explicitly configure it to be used.

No problem except for the fact that Unraid has to format any drive it is using so existing contents get lost. Did not sound as if this was an issue for you? When you plug in the drive then Unraid will handle the mechanics of integrating it into the existing arrsy As long as the keyboard does not need an operating system running it would be fine. Typically it means that a Bluetooth keyboard will not work, but if it has a dongle (e.g. Most Logitech keyboards) it will work fine.

Maybe it has some dependency that is missing on Unraid since Unraid is not a full Linux distribution?

1. Yes. 2. Very easy as long as you have the ports available to plug them into. They do not all need to be the same size. 3. Many people run their Unraid servers headless. You may need a monitor/keyboard temporarily plugged in to support setting up the BIOS to boot off the flash drive unless the motherboard you select has IPMI support (which allows this to be done over the network). The Unraid management GUI uses a web browser so that can run anywhere that supports a browser.

Not that changing the included disks does not apply to existing files (they have to be moved manually iff you want them on different disks). - it will only apply to new files. Not clear from your original post if you are talking about existing files, or about new files going to the wrong drive. According to your diagnostics it looks like there is also content for the TV share on disk2 whereas the Include settings now only show disk3 and disk4 as the desired targets for that share.

OK - just thought I should check. Getting the right level of testing logging will tell me what is happening under the covers.

You are likely to get better informed feedback if you post your system’s diagnostics zip file. Commonest cause can be a too restrictive Split Level setting that is forcing files to the drives in question.

There can be a short period while a parity check and mover are both running until the parity check background monitoring task kicks in. I could see this explaining why the initial small files did not trigger the pause, but it looks like you then had a big file being moved which the monitor task SHOULD have picked up. you might want to check in the plugin settings that the option to pause if mover is running is enabled.

I would need the Testing mode of logging in the plugin running during the period to see if I can work out what might be the problem. Have you rebooted since updating the plugin to the latest version? Just want to make sure you have the latest version.

How are the drives connected? Some BIOS’s get upset if they see more than 12 drives potentially bootable. The fix in such a case is normally to go into the BIOS settings for the HBA and turn off the option to be able to boot from HBA attached drives.

XMP is an over clock.

OK I will go ahead on that basis. The Parity Check Tuning plugin runs a background monitor task so it does not need to know when the backup is scheduled to run as long as it can detect the backup task is running/finished and the presence or absence of the files you mention makes that easy. There might be few minutes while they run in parallel before the monitor task triggers a pause/resume but that should not be a problem.

Thanks, that should be easy enough to handle. Do you agree this would be better handled in the Parity Check Tuning plugin rather than trying to make it a feature in the CA Backup2 plugin?

Yes - no data drive can be larger than any of the parity drives. Of course you could later put a larger drive into the parity2 site.

I might look into what would be needed in the parity check tuning plugin to add such a feature there. Since that plugin already handles intelligent pause/resume of parity checks it feels as probably the best place to add such a feature. I recently added an option to that plugin to pause a parity check while mover is running so this seems a similar option. I would just need to work out the best way to detect if CA Backup is installed (and if not suppress offering this as an option) and if the backup is currently running. Any thoughts on whether this would be a sensible way to handle this?

According to your screen shot you have so far only set up the server to receive syslog entries from other machines. You have two options: set the IP address of your server into the remote syslog server field so your server logs to itself. set the option to mirror the syslog to flash

Yes - parity is only important after a drive fails to reconstruct its contents. Yes. The key thing is to not have any data drive accidentally assigned as a parity drive as that will end up losing its contents. if any share have includes/excludes for specific drives these will need to be checked (and if needed corrected).

You missed an important step. You should have started the array after the assignments are as you wanted them. After doing a new Config all drives are deemed uncommitted until the array is started. That is required to commit them to the flash drive. If you do not have a record of how they were set up then unless you can tell from their contents you are just guessing at the drive order. Since parity1 and parity2 use different algorithms so they are not interchangeable, and getting even one drive on the wrong order would invalidate parity2 anyway there is not going to be much alternative other than to rebuild both parity drives. This will be fine as long as no array drive fails before parity is rebuilt as you are not protected until it has completed.

Seems to work fine for me. The option to power up at a specified time was an option in my BIOS. Some people go for the option to wake on LAN traffic, but I did not want this as I could have a random device on the LAN waking up the server in the middle of the night.

You will have to format the 2TB drive you want in the array before copying data to it, but the 4TB drive you move to the external enclosure can be mounted with no problems. Every array drive in Unraid has a self-contained file system that is readable outside the array. You probably want the Unassigned Devices plugin installed to simplify the mounting of the drive in the USB enclosure.

Any time spent doing a Preclear is wasted as the rebuild process always writes to every sector on the drive thus erasing whatever was already there.