Mdraid on an external usb basket?

Question

linux

I made a tricky configuration using mdraid using 3 disks. One drive is internal, the other two are external, connected via usb 3.0 in the basket.
Each disk has a partition 256M - /boot, and 300G - system (with lvm) [but this is generally not important]
Created two raid1 arrays separately for /boot separately for the system. Everything is running great.
The question is.
How to keep such a design workable in case of some kind of failure in an external basket connected via usb 3.0 (or a banal accidental pulling out of the cable)?
I conducted an experiment, suddenly turned off the basket - the screws disappeared from the OS, after returning the basket to life, they appeared, but they did not get into the md-array.
After the reboot, both were identified as another raid1 array and began to synchronize with each other, and the old array remained without two lost disks.
In general, is it possible to somehow return disks temporarily dropped out of the OS to the old array without a new synchronization and somehow automatically?
Would mdadm --detail --scan >> /etc/mdadm.conf help? (before ripping out disks, mdraid was detected automatically).

Answer 1

It would be worthwhile to specify which raid and OS, but ...
If we are talking about raid 1 Most likely, in the raid there were only these 2 disks that you disconnected and connected. The internal one was a spare and didn't sync at all. You can find out for sure with the cat /proc/mdstat command. There, the sequence number matters - the smaller it is, the “more important” the disk.
When ripping out-adding without synchronization, there is no way, because the data on one disk has become no longer relevant. Only if the disk was not mounted (or ro)
In theory, if you build an array of 2 disks, pull out the second one, write something to the first one, and then add the second one - raid should start synchronization itself, although I don’t sure. This did not happen for you, since the internal disk apparently did not participate in anything at all (as I wrote above).

Answer 2

It is obviously impossible to return without synchronization at all - during the time the disk was missing, the OS could have time to write something to the array, how do you imagine working without synchronization here? You can reduce synchronization if you use write-intent bitmap. In general, this increases the reliability of the storage (because information about what has changed is specially stored) and reduces the synchronization time (bitmap is used when taking into account which blocks need to be synchronized), but slows down its work, because extra jerking heads from data to bitmap and back are required.
You can’t automatically return it, Linux itself can’t do this and does it right. Automation in the event of a storage failure is generally a bad thing. If something is out of order, it cannot be touched. If before automatic repair it was possible to restore something, then after automatic repair it may already turn out to be unrealistic - everything that was on one of the disks has already been erased. For these cases, there is support for hot spare (hot spare) - such a disk will go into operation automatically, and overwriting it will not affect recovery in case of any problems, because. there were no important data on it before commissioning.
So, yes, after the loss and the appearance of the second disk, you should definitely manually, checking whether everything is in order with the data itself, insert the disk into the system.
PS I don't understand why you need USB. If it is exclusively for hot swapping a disk in an array, this is utter nonsense. All SATA controllers in AHCI mode support hot-swapping, for five years I have not even come across desktop motherboards without this support.