As @Fox said, the metadata will guarantee that the array can be assembled no matter what order the drives are detected in.
You should of course be thinking about the devices by their serial number or some other property unique to the physical device, as opposed to the device node name. e.g.:
$ ls -la /dev/disk/by-id/ata-ST3320418AS_6VM9PNFT
lrwxrwxrwx 1 root root 9 2011-11-15 23:20 /dev/disk/by-id/ata-ST3320418AS_6VM9PNFT -> ../../sde
because which physical devices get assigned which device nodes on boot isn't guaranteed. That could be important if you ever need to remove a device, etc. So in my case I think about that disk as serial 6VM9PNFT, not /dev/sde.
As for backing up the metadata, I don't think it's that important because as long as your array assembles you'll have the metadata. If the array doesn't assemble then what is the point of the metadata? Really you aren't meant to be messing around with metadata, you're supposed to be keeping enough available devices!
However, if you really want to back it up, you can dump it out by executing mdadm -E /dev/sde1 for each of the member devices in each of your arrays.
It can be a side-effect of the internal write-intent bitmap used.
Use mdadm <dev> --grow --bitmap=none to remove it, and re-try with fio.
Anyway, I strongly suggest you against going into production phase without a bitmap-enabled array, as a crash/power outage will force the array to do a full byte-per-byte scan/compare. A write intent bitmap will guarantee much faster recovery.
Best Answer
cat /proc/mdstatwill give you the output you need, relatively easy to parse, because the mapped device is on the same line as its members, e.g.: