JonathanM

Motherboard reported, may be accurate, maybe not. fixed allocation by Unraid It's the percentage of space used INSIDE the docker.img file. Not the free space on the drive holding the image file.

Use the 6.12.10 files, overwrite everything on the USB except the config folder. Make sure you keep the config folder, make a backup of it before you do anything else.

Pretty sure that didn't work like you thought it did, because those locations are the same. /mnt/user paths are the combined view of all the root paths on the array disks and the pools combined. user share and disk share should never be mixed in a file operation.

It does, I use it extensively, each of my VM's runs apcupsd in slave mode, and is set to begin shutting down a minute or two after the host server reports a loss of power. Server shutdown is much smoother for me if the VM's are all shut down before the server itself starts the shutdown sequence.

Block the entire 140.210.*.* network in your firewall.

Ask your ISP if they put you on a CGNAT address. If so, ask if they can put you back on a direct internet address instead.

I just thought of a another VERY good reason I want the parity drive to be read all the way to the end. Hidden errors. Unless you run a complete SMART test, that portion of the parity drive beyond the last data drive is NEVER read or written during normal use. The last thing I want is for there to be a bad sector lurking in the last bit of the parity drive, just waiting for me to add a data drive and start exercising it. At least with a parity check that portion of the drive is read regularly. Count me as 1 vote to keep the current behaviour, for the above reason alone.

Just be glad that one of your current data drives wasn't in use as a parity with that old backup. That sort of error is generally fatal to the data that was on said drive. Lesson here, keep current backups, and delete any old backups made before a drive change. You really don't want to accidentally use an old backup.

If that were implemented, it would require a change in the drive addition and replacement code, because it would no longer be a given that the full capacity of the parity drive is indeed zeroes. I don't see that kind of code rewrite happening, mainly because what is there now works, and mucking around with such important code that is currently working would require a VERY strong reason, given the amount of work needed to test for edge cases and general bugs that could be introduced.

Try a different USB stick. It's possible the GUID for the stick you tried isn't usable.

This video is rather old, but covers the basic principles. "Cache yes" terminology is not used anymore because it was confusing, it's been replaced by primary and secondary along with the direction mover should act.

https://forums.unraid.net/topic/82198-support-binhex-urbackup/?do=findComment&comment=918119 pinned post in the support thread

I strongly recommend not doing this. There are many reasons, but the most important in my mind is the need to evaluate the entire situation before allowing the server to come back up. If you are not on site to make that evaluation, there very well may be circumstances that you are not aware.