Interesting question - I like and am also keen on this.
I tried creating a volume mapping to /boot, but that didn't want to work (/boot doesn't even show up in the host path drop down).
I created a soft link from /cache/boot to /boot (ln -s /cache/boot /boot). But this, to me at least, is quite a large security risk. It could inadvertently give access to the flash files where you don't want it, especially if /cache is shared.
Another option that springs to mind... create a backup folder on either the cache or a disk / user drive. Don't export it and create a cron job to copy all files periodically. Or do this manually each time you upgrade or change anything (which is what I do - each time I upgrade I backup the entire flash drive to my windows file server which is subsequently backed up to CrashPlan anyhow ).
UPDATE
Seems you can do this:
[*]Create a mapping in the advanced settings. I did /boot to /boot, and made it read only.
[*]Open the CrashPlan client and click the Change button on the backup tab
[*]Check the "show hidden files" checkbox in the client (I'm using the CrashPlan-client via RDP from the host).
[*]Once you've done this, all sorts of wonderful folders spring to life. Including /boot.
[*]Select it and ok away, presto it is backing up (238 files for 700 MB in my case)
Currently backing up boot > bzroot (7.59% @ 2.6Mbps)
Glad you were able to figure it out :-)
Would you be able to explain where this advanced settings file is and what exactly I need to do to create this mapping?
There is a slider in the upper right to enable advanced settings.
Since this is about backing up the flash, you should be aware that unRAID stores the array configuration and start/stop status of the array in /boot/config/super.dat. This is important to know for 2 reasons.
The most important reason is that you don't want to restore a backup with a different array configuration than you actually have.
There was a user that made a backup of his flash, and after that, he upgraded his parity drive and used the old parity as a data drive. Later when trying to solve some problem, he restored his old flash backup. Unfortunately, this made unRAID think that his old parity (now containing data) was still the parity disk, and it began writing parity to it. Not good.
The other reason is that if you make a backup of the flash with the array started, and you later restore that backup and boot, then unRAID will think that the array wasn't stopped before it was shutdown, and it will do a correcting parity check due to an unclean shutdown.