What can be done to simulate NanoBSD behavior in pfSense 2.4?
Hi and thank you very much for the superior firewall!
Unfortunately I did not follow pfSense development plans. This is why it was for me very sadly to read, that the NanoBSD functionality was deprecated and removed from pfSense 2.4.
For me it was very handy, just to care about pfSense configuration backup before upgrading. All the rest was done by NanoBSD - full backup to another slice. I came relatively often to the situation, that upgrades caused firewall problems. I needed just to reboot the server(s) from the backup slice, restore the configuration - voilà! I spent about 30 minutes for such procedure. I did never have fear to upgrade the firewalls.
Now, in order to perform an upgrade, I need to simulate NanoBSD behavior: to have HD, splitted to two slices; to have a possibility to change slices on boot; before upgrading - copy current slice to the backup one. And all of this can be done only manually.
The question is, how to do it the best way? Or there is a better upgrade workflow? E.g. on my linux servers, the root partition can be snapshot-ed, so before the upgrade, I make a snapshot. If after the upgrade everything is ok, I remove the snapshot. Sometimes, e.g. if the system becomes un-bootable, I reboot it from the snapshot and check, if something in the upgrade process can be changed/fixed, I write tickets, may be I contribute a solution…
Now, reading https://doc.pfsense.org/index.php/Upgrade_Guide:
Make a backup!
Reinstalling the previous release
The worst case scenario on upgrading is a FreeBSD regression that prevents the firewall from booting successfully, or no longer communicating with the network. In this case, reinstall. For a full install, this means reinstalling from a CD or Memstick for the previous release. Download the appropriate image and have it ready before starting the upgrade procedure.
I understand, that in case of booting or other problems, if I follow this guide literally, I will spend much more time, than 30 minutes, to get the firewall working again.
I do not ask to return NanoBSD functionality. I suppose, there were serious enough reasons to remove it. I just wonder, how I can optimize my time, upgrading the firewalls.
I wonder also, what is the new upgrade process for the embedded firewalls? It is clear, how to make the pfSense configuration backup. But what would happen, if the system becomes un-bootable? (Sorry, I did not try to find the answer on this question - just wondered.)
To be honest, previously I was thinking about buying of two embedded pfSense firewalls. Now I am not sure…
I am sorry for such a post, I really-really like pfSense, the team and the community.
There is no way to get the dual-slice behavior or boot differences back.
You can reduce disk writes by turning on the setting to put /tmp and /var in RAM disks.
Eventually it may be possible to work up something with ZFS snapshots or ZFS send backups but there isn't anything in place currently.
For quick full pfsense backups and recoveries this is what we do with our telecommuters. It works quite well. Hopefully the idea can also benefit you.
First, make sure that your router hardware can boot from an external USB hard disk drive in "legacy BIOS boot" mode. If for some reason the BIOS doesn't allow it scrap the idea. Also if you do not have 3 USB ports on your pfsense hardware, make sure that you have an external powered USB hub with 3 ports.
Then, get/make yourself a bootable USB flash-drive with some flavor of Linux on it that you are comfortable with.
For instance, it could be a live Linux Mint 18.2 disk, or BootRepair live disk, or still bitdefender live disk.
Whatever you pick ensure that it is GUI based. Something that's capable of booting up your router hardware and allow you to run a terminal window and a utility like dd, or dcfldd or yet dc3dd (these are all raw disk copy tools for command line use).
Next, get yourself a couple of identical, top quality Flash disks no larger than 16GB, (or a couple of small size SATA SSDs that you get from AliExpress for cheap and convert to external USB drives by using cheap enclosures).
Regardless what kind, ensure that the drives are not larger than 16 (or at most 32) GB. The reason for size limit is that, as a matter of routine backup you will be performing an image copy of the entire disk drive, and the larger the drive the longer the copy time will be.
A nanoBSD based pfsense system is a lightweight system and it fits on a few gigabytes at most. So, my assumption is that 8, 16 or 32GB will be more than enough for your situation. But on the other hand larger USB flash drives are faster than smaller ones, so that's why 16GB is probably the perfect size/performance point.
Now, install pfsense 2.4 on one of the USB flash disks (no ZFS, no UEFI, just basic ufs in legacy bios boot mode). Configure it and use it as if you are in normal operational mode.
At your intended, periodic backup time, simply shut down pfsense, plug in your Linux USB flash disk mentioned at the beginning, get a terminal session going and run a dcfldd copy of the entire pfsense flash disk onto your backup flashdisk of identical physical size. Typically this would take a few minutes.
So, basically you will be running pfsense off an external USB flash drive and when you decide to run a backup, you go into linux mode and copy one flash drive onto the other in raw copy mode. This will result in absolutely identical, physically separate pfsense disks that you can swap as needed.
Performance wise the USB flash disks won't be worse than any nanoBSD solution, but obviously you won't be able to run "heavy" stuff like squid cache etc. But I gathered that that's not what you're looking for based on the fact that your starting point is nanoBSD.
The beauty about this solution is that if you need to restore, you simply switch to the other flashdrive, there is no need to copy anything.
Again, this is something that we have been doing with many telecommuters (50+) at large with different levels of technical knowledge and all kinds of pfsense hardware, and the cornerstone of our logic has been that regardless how expensive the hardware, the firewall/gateway would eventually fail, so quick recovery, high level of safety and painless but guaranteed backup were all necessary.
So hopefully this will also help you. Good luck.