itimpi

You have to simulate a drive failure to trigger the rebuild
stop array
Unassign disk3
Start array to make Unraid ‘forget’ current drive.
At this point disk3 will show as being emulated. You can browse the contents of the ‘emulated’ drive to check it looks OK as what you see at this point is what will end up on the physical drive after it is rebuilt. If you do not think the contents look correct get diagnostics and then post them here to get advice on how to proceed.
Stop array
Assign disk3
Start array to rebuild disk3.

They will as long as they were installed via the Unraid Apps tab. When you install containers in that way the settings are stored in an XML template on the flash drive and that is used by the Apps->Previous Apps option. If you install containers in another way then you have to remember the settings used.

When you replace an emulated disk and it is rebuilt then whatever was showing on the emulated disk before the rebuild is what will appear on the physical disk after the rebuild. No need, therefore, to copy the existing contents elsewhere first unless you want to protect against the rebuild failing for some reason.

@hyphonetics
There are 2 possibilities to increase available storage that you might want to consider:
Add the new 12TB drive replacing a 6TB drive increasing the total available space by 6TB to give 18TB.
Add the new 12TB drive as an additional data drive (i.e.disk3) increasing the total available space by 12TB to give 24TB.

In theory it should "just work".

Having said that I to avoid any potential issues I would remove any pass throughs of hardware as the IDs will definitely change (and make sure no VM that uses them tries to autostart) and redo them when you come up on the new hardware.

Unless you had only 1 data drive (a special case where parity is a mirror of the disk), then there is no user data on a parity drive that is retrievable even by a specialist.

I think you need to have the array stopped before you can change the Minimum Free Space setting on a pool.

According to the diagnostics the ‘cache’ pool IS being used for that share although there is not much there at the moment.
p------------r shareUseCache="yes" # Share exists on cache, plexdata

What makes you think it is not?

The onboarding wizard only appears automatically on first boot of 7.3.1. Nothing further to do if you want to continue running as before the upgrade.

When you change a share to be array only it does not cause any existing files to be moved as that setting is only used for new files.

One option is to manually move files. For this you could use Unraid’s built-in file manager or a file manager of your choice.

Another option is to let the mover application built into Unraid do this. For this to happen you need to set a share up with Primary Storage=cache; Secondary. Storage=array; mover direction=cache-.array.

In both cases you should have the docker and vm services disabled while ding ‘tis as they hold files open which stops them being moved.

I would suggest creating a new 7.3.1 flash drive using the USB Creator and check it boots. At this point it will be a virgin install with no licence.

You can then restore the config folder from the backup to get all your settings applied and reboot. If this step fails then it probably means there is an issue with the contents of your 'config' folder in the backup so if that turns out to be the case I suggest you come back here describing what is happening, ideally providing a diagnostics.zip file so we can see what the current state of things actually is.

Boot drive can only be a pool drive, not an array drive.

You should be fine. There used to be an error where it was possible for the part of the parity drive beyond the largest data drive at the time was not always correctly zeroed, and as you are on such an old Unraid release I expect you encountered it.

Let the correcting check run to completion. A subsequent parity check should then return 0 errors.

In the special case of a the main array having 1 data drive and parity1 then the answer is yes.

I would just create a top level folder on the desired disk that is the name of the share you want there and it will automatically become a User Share. Then go into the settings for that share and make sure they are what you want. My suspicion is that there is some sort of interaction between the 'Manual' Split level setting and something else.

You can configure the plugin to give you notifications when the plug-in does a pause/resume, and the reason why.

You do not have to rename the pool to ‘cache’ - it can be anything you like. It is just that for historical reasons ‘cache’ is the default name for the first pool. Whether a share should be cached is set at the individual share level and different shares could use different pools for caching purposes. To do so you set the pool to act as the cache (it can have any name) as primary storage, the array as secondary storage, and the mover direction as pool->array.

You have to disable (temporarily) the Docker and VM services under Settings as they hold files open on the System share that will prevent them being moved. You cannot do it in Maintenance mode as then the files are not available to be moved.

That will be because not all the files are on the ‘Pool-apps’ pool. It will be enabled automatically for all shares which meet the conditions if you have the global option enabled, so if shows up as No when you look at the share settings it typically means that not all files/folders for the share are in the right location although it could be one of the other required conditions

Providing the requested diagnostics would allow us to check for other possible issues.

Parity is never held at an individual drive level but is always system wide. If the emulated drive is mounting OK and the expected files are showing then after a rebuild parity should be good as all drives plus parity drive are involved in a rebuild. If the expected files are not showing then a rebuild is probably not the best next step. After a rebuild it would not hurt, however, to run a parity check at that point although it is probably not needed as it should be correct.

As mentioned in the online User Manual you need to check filesystem when you get a drive showing as unmountable.

You have to time it yourself and then add on 30 seconds or so. If that timeout is not long enough then you get unclean shutdowns as the timeout shuts down the server before the array is cleanly unmounted.

There are other timeouts you can set controlling how long VMs and docker containers should be given before the system attempts forcible close of them.

It is a new pool - not part of the cache pool. Whether a share is cached is set at the individual share level, and it can use any pool (i.e. it does not need to be called cache).

There is often confusion between a pool called ‘cache’ and the caching facility which can use any pool. It just historical that the default name for the first pool is ‘cache’ as originally that was all it could be used for.

An unassigned drive is one that is NOT part of the array. Rather than try anything clever and you have no free slots it is probably easiest to plug the old drive on via USB (probably using a USB->SATA dock or adapter). Less chance of doing anything wrong that way, and anyway being able to temporarily plug a drive in is always useful for purposes such as backups.

Looks like you have problems with your flash drive:

Apr 6 17:45:31 Battlestar kernel: critical medium error, dev sda, sector 60125056 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
Apr 6 17:45:31 Battlestar kernel: buffer_io_error: 2 callbacks suppressed
Apr 6 17:45:31 Battlestar kernel: Buffer I/O error on dev sda1, logical block 60123008, async page read
Apr 6 17:45:31 Battlestar kernel: sd 14:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=0s
Apr 6 17:45:31 Battlestar kernel: sd 14:0:0:0: [sda] tag#0 Sense Key : 0x3 [current]
Apr 6 17:45:31 Battlestar kernel: sd 14:0:0:0: [sda] tag#0 ASC=0x11 ASCQ=0x0
Apr 6 17:45:31 Battlestar kernel: sd 14:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 03 95 6f 81 00 00 07 00
Apr 6 17:45:31 Battlestar kernel: critical medium error, dev sda, sector 60125057 op 0x0:(READ) flags 0x0 phys_seg 7 prio class 2
Apr 6 17:45:31 Battlestar kernel: Buffer I/O error on dev sda1, logical block 60123009, async page read
Apr 6 17:45:31 Battlestar kernel: Buffer I/O error on dev sda1, logical block 60123010, async page read
Apr 6 17:45:31 Battlestar kernel: Buffer I/O error on dev sda1, logical block 60123011, async page read

I would suggest first try redoing it from your backup (if you have one) as sometimes rewriting the drive can fix this type of issue. If that does not work you will have to consider transferring your setup to a new one.

Restarting from the beginning is Unraid default behaviour for all array level operations.

If you have the Parity Check Tuning plugin installed then it has an option to try and restart array operations from point previously reached (as long as the shutdown was a clean one).