Well I've made some interesting progress in backup strategy. The fact that I have two Polisys (and the hardware necessary to reflash their SSDs) for testing allowed me to try some of the riskier things that I wouldn't do on a single system that's actively in production. The first was to do a full file backup (unix, IoX, plugins... everything) to a USB stick, and then use that to "clone" the Polisy I took it from to the second Polisy. Worked great. This involves connecting by ssh and running unix commands. This type of backup is good when you're about to do a major change, like an upgrade to a new IoX version, especially if it also upgrades the version of FreeBSD. This has been the case with 6.0.0. Before doing any of this: Please... UDI provides truly great support (almost to a fault, if we think that we can try risky stuff because at worse, they can always bail us out). At minimum, you need to be confident with using unix commands, and be ready to recover using one of their supported methods if you get into trouble doing this (like buying their recovery USB stick). As the saying goes: a lack of planning on your part does not necessarily constitute an emergency on their part. UDI gives us an amazingly open product and great support. Don't abuse it! That said, here is my procedure for making a full cpio unix backup of a controller. Cpio is the name of the unix command (means copy in and out) that we use here. I know that most people use "sudo" commands for this kind of thing. I've worked with unix since 1985 and was used to doing everything in straight "root" login. Sudo didn't exist back in the day! Yes, I'm an old dinosaur. Try it with sudo commands if you feel better doing it that way. To get to a root prompt, login with ssh the usual way (admin@polisy.local) then do: sudo sh and when prompted for a password, enter the admin password. You should then get the "#" prompt. Ok, you'll need a USB stick. I bought some 32 GB sticks for this. First you need to create a filesystem on the stick, partitioned as a single large partition: - insert the usb stick and view disk devices: # geom disk list - note that da0 is the usb stick, should show brand and size. # gpart destroy -F da0 da0 destroyed # gpart create -s GPT da0 da0 created # gpart add -t ms-basic-data da0 da0p1 added # newfs -U /dev/da0p1 Now you have a mountable filesystem that you can copy files to. cd to the root directory (cd /) and create a directory that will be a mount point with a filename that you won't find anywhere else in the system, to make it easy to find in a list. # mkdir abcxyz Finally, mount the usb stick: # mount /dev/da0p1 /abcxyz Verify that its mounted, using just the mount command. You can also see the storage capacity using the df command, which will show you the number of blocks available on both the SSD and the mounted USB stick. # mount # df In unix, filesystems are mounted as subdirectories to the root filesystem. This makes file operations between physical media seamless. It's just another directory. Ok, now for the cpio backup. The trick is to create a file list of everything on the root filesystem, and then have the cpio command get the names of the files to backup from the list. The reason for this two step process is because we need to make a list from the root filesystem, which will by default include the subdirectory where the USB stick is mounted. We then want to edit the list to remove that directory from the file list because if you don't then the backup will try to backup the backup itself, recursively, like a snake eating it's own tail. So create the file list from the root directory, using a unique file name: # cd / # find . -print >/tmp/file_list Now use the vi editor to remove the mount point directory from the file list. Delete any lines that begin as "./abcxyz" in the file, and save the file. Then launch the actual backup, which will back up everything into a single large file with a name of your choosing: # cpio -ov >/abdxyz/my_pre_upgrade_backup </tmp/file_list This cpio command redirects it's standard output to the /abcxyz/my_pre_upgrade_backup file, and redirects it's standard input from the file list we created earlier. the "o" option means output, and the "v" option means verbose, which means it will display the file names it's backing up to the screen (technically, to the "error output" file descriptor). You'll see hundreds of file names scroll by. Once it's finished and you're back to the root prompt. You can verify the presence and size of the backup file: # ls -l /abcxyz You then need to unmount the USB stick, using the umount command: # umount /dev/da0p1 You're done! Now suppose that digital armageddon occurs and you need to restore your system. You at least need to get back to a unix shell prompt. This could involve reflashing the SSD, or connecting a keyboard and screen to a eisy because networking isn't working. Whatever. The first thing you need to do is recreate the mount point if it got lost as part of the disaster: # mkdir abcxyz Now insert and mount the usb stick: # mount /dev/da0p1 /abcxyz Verify that its mounted, using just the mount command. All ok? So now make sure you're in the root directory and logged in as root, because this is going to be a real smash! Cringing is permitted! (remember, I did this on a test system that I could reflash). Launch the restore: # cpio -ivumd </abcxyz/my_pre_upgrade_backup Aside from the obvious "i" for input and "v" for verbose options, "u" means unconditionally overwrite same name files, even if the existing file has a newer modification time, "m" means write back the original modification times that the files had when backed up, and "d" means create any directories needed for the files to restore. This will totally overwrite everything, unix and all, with the files from the backup. Once your back to the root prompt, reboot the controller: # reboot Your controller should be back to how it was when you backed up. Don't use this procedure to change controller types (eg: Polisy to eisy, or other way around) as some files would be different. We're talking about a backup here, not a migration. Also, if you're restoring to a different physical controller, the UUID of the old controller will not be carried over to the new one. The UUID is generated by the startup process, extracted from the controller's network card MAC address. Once again: this is for your information only, and use at your own risk, And...if something happens where you think you'll need UDI to help you, well this isn't the kind of procedure they support. Be ready to reflash your SSD from a image file they provide before getting them involved. On the bright side, I've done this a couple of times and it's worked well 🙂 PS: cpio is a great tool for copying unix directory trees, when multiple files and directories are involved. If you don't need to copy to a subdirectory to your current one, but rather to a directory above or beside yours. You don't need to do the two step directory list thing. Here is an example: suppose you're working on a plugin and you want to make a copy of all the files in it to a new directory as a backup, because you're about to make big changes to it. Let's say that your plugin's home directory is "/home/admin/workspace/plugin-dev/myplugin" and you want to copy everything in it to a new directory: "/home/admin/myplugin_save". Begin by creating the new directory you want to copy to: # mkdir /home/admin/myplugin_save Now position yourself in the directory to want to copy: # cd /home/admin/workspace/plugin-dev/myplugin Make sure you're in it, using the pwd (print working directory) command: # pwd Once that's confirmed, copy everything over to the new directory with the magic cpio command: # find . -print | cpio -pduv /home/admin/myplugin_save Verify that everything has been copied to the new directory 🙂