Please no knee-jerk reactions "that is dumb". I come from a mainframe and unix server background (although that was 20 years ago) and have thought this through carefully.

Yes this is for backup. I know wear leveling has improved ssd reliability, maybe just moving swap to a dedicated ssd is adequate and I should just hardware mirror to a second ssd. I will listen to arguments for this, especially if there are tools to read out the status and warn me that my ssd may fail within the next 6 months. I fear that being mirrored, both ssds would fail at the same time.

In mainframes and solaris servers we could schedule jobs to image backup the os to an instantly bootable alternate disk and/or build a backup image for the previous version of software. Read to the bottom for a question on this possibility, which I suspect is also a VERY hard question.

I will accept that a carefully crafted scheme of backups may be best. But experience has shown that I will get lazy over time and fail to keep up with backups, or fail to notice that the scheduling has failed, or I will notice, but put off fixing until I forget, and I will be left with nothing.

I want to set up a new system, for running a virtual machines (will be new to me in PCs).

Note that ONLY the operating syhstems will be in an ssd/hdd mirror set. swap will be a dedicated, non mirrored ssd, and user data will be a separate mirrored hdd set. I don't serve up web pages or have massive databases, so I can wait while my spreadsheet loads off hdd. Loading programs, especially with massive bloat is where I want the benefits of ssd.

Since only the os is being mirrored in the ssd/hdd set, there is not much writing. If it helps, I could put /tmp and /etc elsewhere too. Doing OS updates will be slowed to hdd speed, but I can start that up when I go to bed if it is a big update.

What *IS* critical, though, is will either software raid and/or a raid card dynamically (or by configuration) detect that reads come faster from /dev/sda1 than from /dev/sdb1 and route all reads there? In mainframes this WOULD happen as a feature of the operating system, dynamically. If a raid card will split all reads equally, then it there is no point in my configuraiion, or I might as well use two hdds.

A reasonably priced raid card is preferred, but if it takes a $2000 card, then I won't do it. If only software raid will do what I want, then that is what I will do.

Note that in mainframes, I could just regularly image copy the system, then at any time boot from the backup and it would work. In Solaris servers, I had to edit the copied root partition switching fstab entries between /dev/sdaxx and /dev/sdbxx and I could boot either image. With UUIDs, this is not obvious how to do. Per someone's suggestion, I once tried putting in the /dev/sdaxx format, and it did not work (but may have made some other error, I suppose). I don't think I tried to put the other parttion in my running system so I could just swap them.

Welcome to LQ!

I have not personally been in a situation where 2 HDD's failed at the exact same time. It was always a priority to get the HDD replaced as soon as possible as most times we would be running Raid 5 on the data and Raid 1 on the OS drive. Its not perfect but there have been other systems in a cluster to take over the heavy lifting if things were to go south. If you are planning to use Virtual machines you could always setup a Raid array with frequent backups and at the same time use the snapshot feature on a regular basis. Although snapshot is not and should not be considered as a backup solution it is another tool in the box that can be used.

Must be very unusual setup if these programs get unloaded and reloaded all the time. Normally once the system is up and programs are loaded into RAM they stay there and run from there.