Backup and Recovery

See also

Thanks to the XML-based configuration file used by pfSense® software, backups are a breeze. All of the settings for the system are held in one single file (see 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.

Note

In rare cases, packages may store files outside of config.xml, check the package documentation for additional information and backup suggestions.

Backup Strategies

The optimal backup strategy can be summarized in the following points:

  • Take frequent backups

  • Keep multiple copies of backups in a safe location off the firewall

  • Periodically test backups

The remainder of this section expands on these points.

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 helpful, regardless of changes, especially in cases where a manual backup may be missed.

pfSense software makes an internal backup upon each change, and the best practice is to download 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. Backups may be handled easily and automatically using the free AutoConfigBackup service.

Tip

Backup files can contain sensitive information, so carefully consider security measures for backups kept off the firewall. If they are on other network file shares, ensure access is restricted. For offline backups, consider physical security measures such as keeping media containing backups in a fire safe and at a remote secure location such as a second office or bank safety deposit box.

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 described in 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 documentation, such as /boot/device.hints, /boot/loader.conf.local, and others.

Note

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. The best practice is to periodically test 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.