@Maximilian-Gerhardt I agree on your idea for laying this out. USB for the disk, the built-in µSD card slot for the µSD card. Add some LEds, buttons, and/or expansion boards for a physical user interface if you want one.
USB 2.0 will be limited to ~60 megabytes per second, but that might be fast enough for many uses, like if you just want to leave the µSD card in this auto-backup-dock-thing whenever it's not in use. If you want more speed, it's probably time to use a more powerful device with USB 3.0 or native SATA. That might be an old laptop, or a faster single-board computer (some have USB 3.0).
As to software, I bet this will be possible using some combination of scripts or programs that do the actual sync, and something to start it when a new card is inserted, probably procd. For copying, I'd consider rsync, as I bet there's some combination of flags that will make sure that your data only gets copied off once, not multiple copies of the same data.
Assuming you want to delete the files off of the uSD card once they're copied, you could mount the µSD card once as "read-only", copy the data off, then remount it as "read-write" for just a few seconds to delete the files, then unmount. This is pretty safe, as you can safely yank the µSD card out at any point in time except during that time when it's mounted "read-write".
@Brad-Buskey some similar systems offer an ability to download a backup file through a web gui as part of the sysupgrade functionality but I don't know if this is one of them.
Speaking generally rather than about the omega 2 in particular:
If you already have the read-only system image corresponding to your current state (for example from the download server) then all you would really need to backup would be the mtd patitions containing the "firmware" identity data (possibly), and the one containing the jffs overlay that captures any changes you make on top of the read-only core.
Approximately speaking, if you boot in failsafe mode you could dd the partitions (probably /dev/mtdblock2 and /dev/mtdblock4 but I don't have a running system here to check) to /tmp and then download them with something like scp. It may also be possible to directly scp the /dev/mtdblock psuedo-files, or possibly to pipe the dd copying through gzip to make a smaller backup.
Thanks @fader and @Boken-Lin. I have started using tmux in a vertical split screen while testing so that I can quickly restore my changes after a factory reset. The openwrt article was handy for keeping my configs.
Looks like your connection to Community was lost, please wait while we try to reconnect.