XML restore of full install configuration to NanoBSD install
I tried searching for an answer to this, but wasn't sure where even to start with search terms.
I had an Intel SSD running for about 8 months when it failed. Seems I hadn't gone through and fully turned off all logging etc and it tore through the NAND cells. But, before it went down, I backed up the config.
This time, I've got a SATA-DOM (SuperMicro, 16GB) and have put a Nano 4GB Serial based install to it. Never mind the acres of space left over, when I do a restore of that XML configuration, suddenly, it comes up on a VGA monitor and as I look through the logging area, it looks to be turned back on.
Does a full install config backup convert (the settings of) a NanoBSD install to a full install, and do I have to go through again turning off RRD graphing etc? Or is the NanoBSD hard coded to never write to disk regardless of what is in the XML file?
Sorry if this is a simplistic question.
it comes up on a VGA monitor and as I look through the logging area, it looks to be turned back on.
Sorry…suddenly the nano-bsd serial install shows up on a vga monitor during bootup. Before the config restore, bootup on a monitor just showed a blinking cursor, but I was able to console in. Now, after the restore, when I reboot, I can see the entire bootup routine, in addition to the menu.
That's what led me to believe that somehow I had "converted" the nano-bsd serial install to a full vga install.
Does that make more sense? Thanks for your help.
The "It" you're asking about refers to RRD graphs. Isn't this graphig feature turned off on a Nano-BSD install?
The main thrust of my question regards NOT having PFSense write to the SATA-DOM - something I thought I had achieved by using the Nano build. But did I break that by doing the XML restore?
Does that make more sense?
Are you actually having any problem? You can very clearly see what's installed with the system information widget on the dashboard.
It's not that I'm trying to see what's installed or solve any problem.
Will my current install (which started as a Nano image) perform many needless writes to the SATA-DOM, thus reducing it's lifetime? The purpose of my installing the Nano version was to prevent this. But if a simple XML configuration file restore brings back the write settings of the previous installation (that was on the SSD), then that completely obliterates the main point of the Nano version.
I appreciate your help on this, and apologize for not being clear enough.
- you can very clearly see what's installed using the System Information widget (see Platform). You can see the same information when you connect via SSH/console, right above the menu.
- nanobsd is completely abandoned with 2.4, and the read-only feature is gone from there since 2.3.1 or so.
- if you are concerned about writes, look at ramdisks instead (System - Advanced - Miscellaneous)
- restoring a config does NOT switch between nanobsd and full install.
Thanks but I KNOW I installed the Nanobsd version, and yes it shows that under Platform.
I looked at the ramdisk settings and that was a great help and clarifies a lot.
At this point, I can't understand the logic behind using a nanobsd install then. Should I just go with a full install, and then set it to use RAMdisk? Will that, in addition to turning off RRD graphing, rid the install of most needless writes, and thus prolong my SATA-DOM life? I read through a long discussion on this very topic in the forum, but my takeaway was that simply using nanobsd would be sufficient. They recommend disabling firewall rule logging. When I go into the setting of my current nanobsd install, they are, however, turned on.
So after all this, here is how I would rework my initial post. Will restoring the SETTINGS from a full install, overwrite the default settings in a nanobsd install (like logs and RAMdisk etc), thus negating the entire reason for the nanobsd install (limited writes)?
I also still don't understand how a serial nanobsd install started displaying VGA output at bootup. There must be a setting buried somewhere in the dashboard that controls it?
nanoBSD has /var and /tmp as RAM disks. Other than that, it does nothing special to stop writes to the non-volatile storage ("disk"). Back some time ago it used to set the non-volatile storage to read-only. That would make sure that if something did try to write there, that "something" would get an error. Stuff that really did need to write to non-volatile storage had to switch to read-write, write data and switch back to read-only.
The "set the non-volatile storage to read-only" behavior was removed some time ago. But the actual logic of real code did not change. So there was no sudden surge in writes to non-volatile storage. The system still tries to only write to non-volatile storage when it really needs to.
2.3.* is the end of the road for nanoBSD.
Given all the above, everyone should do full installs and if you are worried about writes to non-volatile storage, then take the options to put /var and /tmp in RAM.
Great answer and very apropos to my question. So I suppose that in 8 months, NOT turning off /var and /tmp can take out a 120GB Intel SSD? Yikes.
Time for a full re-install.
Thanks Phil and doktornotor.
can take out a 120GB Intel SSD?
Modern SSDs should work for "a very long time" (TM) and have no problems at all. And given that the pfSense/FreeBSD install is only taking a small fraction of 120GB, there are plenty of free blocks for the underlying SSD block re-writing algorithm to spread itself around. So it will take ages for individual real blocks on the SSD to "wear out".
IMHO, spending time messing about with this is only (possibly) relevant on old early SSDs that may not have had sucvh good reliability.
That's what I thought…
Well, I guess it also depends on the packages installed. I was running Squid, but am quite sure I had offloaded the writes to a traditional HD that was also installed in the same server. All logs were going to a syslog server on the network. That's why I was puzzled when the firewall started failing recently. The Nanobsd install has been running flawlessly for a week now so it definitely was an HD problem.
Also, that SuperMicro SATA-DOM I'm using is only 16GB, so I have less room for errors, and that's why I want to make sure I don't lessen IT'S life.
When it fails, I'm going back to a quality SSD drive and will simply use the RAM disk just to be safe.
Thanks all. Good to know for the future.