02 Oct pfSense® Backup
pfSense® Backup
Local Copy - Config History
pfSense® automatically makes an internal backup upon each configuration change. This is useful for reverting to prior configurations after changes that have proven detrimental. These backups can be seen and restored from the WebGUI on Diagnostics -> Backup & Restore -> Config History.
These backups reside on the system itself and not externally. This is not ideal for scenarios where a change renders the system inaccessible or for disaster recovery purposes. Hence, you have the option to backup your configuration either on Netgate servers or your own. The choice is entirely yours.
Remote Copy to Netgate Servers
Netgate provides a free service named AutoConfigBackup. This utility automatically encrypts and saves configurations to Netgate servers without manual intervention. To utilise this, simply go to the WebGUI and choose Services -> Auto Config Backup. More information about this feature is available here.
While this service is quite advantageous, we’ve occasionally encountered challenges. Specifically, it necessitates an active internet connection and the retrieval of both the encryption password and the unique identifier for the firewall for the restore process to complete.
Remote Copy to Your Own Servers
Our team has crafted a script that archives the Config History (automatically generated by pfSense®) to your designated server. Additionally, this script captures a snapshot of the active pfSense® configuration. When executed as a scheduled task, it establishes a remote configuration repository. This repository becomes a valuable resource, enabling the restoration of your pfSense® server or appliance in the event of hardware malfunctions. Essentially, this approach provides a comprehensive disaster recovery solution for your pfSense® system.
Method 1 - Pull
Pre-requisite:
- Enable Secure Shell Server on System -> Advanced -> Admin Access -> Enable Secure Shell
- SSH Key-Based Authentication
Linux shell script to pull the pfsense® config history and current config
#!/bin/bash
CID=$1 # Customer ID
IP=$2 # IP of pfSense
INST=$3 # Instance
# Copy Config History
scp -p admin@${IP}:/cf/conf/backup/* /pfsense_backups/${CID}/${INST}/
# Copy Current Configuration
scp -p admin@${IP}:/cf/conf/config.xml /pfsense_backups/${CID}/${INST}/
# Update timestamp to see when the script last run
touch /pfsense_backups/${CID}/${INST}/lastrun
Method 2 - Push
Pre-requisite:
- Install Cron utility on System -> Package Manager -> Available Packages -> Cron
- SSH Key-Based Authentication
Navigate to Services -> Cron
and create two cron jobs to copy the current configuration and the config history.
Utilities
Additionally, our team has created a user-friendly tool that display, on your server, the specific configuration changes that prompted an automatic backup in pfSense® and the resulting files generated. This becomes particularly beneficial when an erroneous change made your system inaccessible. This help you identify and reinstate the configuration that was operational right before the undesired alteration.
Perl script to list the History Config .xml files on your server and the configuration change that triggered its creation in pfSense®
#!/usr/bin/perl
use warnings;
use strict;
use POSIX qw( strftime );
my ($customer, $instance) = @ARGV;
my $filename = "/pfsense_backups/$customer/$instance/backup.cache";
my @fields = ();
open(FH, '<', $filename) or die $!;
<FH> =~ /^a:30:\{(.*)\}$/;
my $data = $1;
$data =~ s/i:(\d{10})/ts:$1/g;
@fields = split(/ts:/, $data);
close(FH);
foreach (@fields) {
my @val = split(/;\w+:\d+:/, $_);
if ( defined($val[0])) {
print "File config-$val[0].xml -> ";
print strftime('%Y-%m-%d %H:%M:%S', gmtime($val[0]));
print " Version: " . substr $val[4], 1, -1;
print " - " . substr $val[2], 1, -1;
print "\n";
};
}Output example:
Please note, this backup script is based upon the “Alternate Remote Backup Techniques” published by Netgate here. The copy of historical configuration change is not listed by Netgate as an officially way to access the configuration history so watch out in case Netgate change the directory where historical configurations are kept.
Also, be wary of the risks implications of using SSH Key-Based Authentication. Ensure the remote server is well protected and the user running the script is isolated and has little to no privileges on the server.
If you wish to hire us to implement this DR solution, to keep it current and secure, please contact us here.
