Backup and Recovery¶
Thanks to the XML-based configuration file used by pfSense, backups are a breeze. All of the settings for the system are held in one single file (see pfSense XML Configuration File). In the vast majority of cases, this one file can be used to restore a system to a fully working state identical to what was running previously. There is no need to make an entire system backup, as the base system files are not modified by a normal, running, system.
In rare cases, packages may store files outside of config.xml, check the package documentation for additional information and backup suggestions.
The best practice is to make a backup after each minor change, and both before and after each major change or series of changes. Typically, an initial backup is taken in case the change being made has undesirable effects. An after-the- fact backup is taken after evaluating the change and ensuring it had the intended outcome. Periodic backups are also be helpful, regardless of changes, especially in cases where a manual backup may be missed for one reason or another.
pfSense makes an internal backup upon each change, and we recommend downloading a manual backup as well. The automatic backups made on each change are useful for reverting to prior configurations after changes have proven detrimental, but are not good for disaster recovery as they are on the system itself and not kept externally. As it is a fairly simple and painless process, administrators should make a habit of downloading a backup now and then and keeping it in a safe place. If a pfSense Gold Subscription is available, backups may be handled easily and automatically using the AutoConfigBackup package.
If changes have been made to system files, such as custom patches or code
alterations, those changes must be backed up manually or with the backup package
Backup Files and Directories with the Backup Package, as they
will not be backed up or restored by the built-in backup system. This includes
alterations to system files mentioned elsewhere in the book, such as
/boot/loader.conf.local, and others.
Custom patches should be handled using the System Patches package, which is backed up with config.xml, rather than saving manually patched files.
In addition to making backups, backups must also be tested. Before placing a system into production, backup the configuration, wipe the disk, and then attempt some of the different restoration techniques in this chapter. We also strongly recommend periodically testing backups on a non-production machine or virtual machine. The only thing worse than a missing backup is an unusable backup!
RRD graph data can optionally be held in the XML configuration file backup. This behavior is disabled by default due to the resulting size of the backup file. There are also other ways to ensure this data is backed up safely. See Backup Files and Directories with the Backup Package later in this chapter.