OPNsense Forum
Archive => 21.1 Legacy Series => Topic started by: waxhead on February 16, 2021, 12:01:29 pm
-
I upgraded by opnsense box with SSD's and decided to put /var in RAM.
If I enable all the periodic backups (rrd,dhcp leases,netfow and captive portal) at 1 hour interval it is not clear to me if this would be the same as having /var periodically saved to disk causing a unclean reboot / shutdown to result in max 1 hour of lost logs.
-
Not at all!
RRD, dhcp lease, netflow, captive portal, and the rest of the items in the GUI config only saves a tiny portion of the /var folder. Everything else is lost after a reboot. It does not have to be UNCLEAN, even the normal reboot wipes the entire /var and re-creates from scratch after every boot. If you need the full content of /var, you must do your own work, and create some periodic copy script that takes care of everything under /var.
-
Am I misunderstanding or do you say that a normal reboot wipes /var EVEN if it is on disk? If that really is the case , why not always keep /var in memory then?
-
You misunderstood me.
If /VAR is on normal filesystem, nothing is wiped during reboot.
If /var is on memory filesystem, the entire content is wiped during reboot, so if you want to keep any file saved there, you have to back them up to a permanent storage.
-
So, do you know if since the vnstat database is in /var/lib....it too is not written to disk AND is also wiped on reboot (using the memory option)? Wonder if there's a way to relocate that database...and/or periodically back it up in that situation. No plans to switch to memory option, but curious. Thanks.
-
My problem, when I enabled MFS was also the loss of vnstat history and the vnstat db got corrupt and had to do DB reset every single time the system booted.
The "solution" suggested from one of the opnsense devs was, to turn off MFS. Then do a reboot. Then turn ON the MFS, then reboot again. Suddenly, the vnstat database was relocated under the folder /root/var/lib/vnstat (dont ask me how it happened, I think it was some faulty race condition or sthg similar mistake), so in fact it remained on permanent storage. So the issue has been "fixed" so to say.
On another opnsene with MFS this same vnstat+MFS issue still persist even today, but the MFS turn ON and then OFF then ON again did not fix it the same way. So after every reboot I have to always reset the DB, otherwise the vnstat service fails to start.
Seems nobody else in the community is affected. Or nobody is using MFS + vnstat on the same system. Or simply nobody else reported this issue after all...
-
> [...] So the issue has been "fixed" so to say.
It's a long, strange and sad way to describe a feature, but you certainly hit the nail on the head (again).
Cheers,
Franco