A Pi-hole backup isn’t just a snapshot; it’s a time machine that lets you rewind your entire ad-blocking universe, including custom blocklists, whitelists, and DNS settings, back to a specific point in time.
Let’s see it in action. Imagine you’ve just painstakingly set up Pi-hole on a new Raspberry Pi, imported your client-specific DNS records, and tuned your blocklists. You want to replicate this exact setup on another identical Pi, or perhaps you’re worried about a software update gone wrong.
First, on your source Pi-hole, you’ll grab the configuration:
sudo pihole -a -t backup
This command bundles up all your settings into a single .tar.gz file, usually located in /etc/pihole/backup/. You’ll then transfer this file to your destination Pi-hole.
On the destination Pi-hole, assuming Pi-hole is already installed but not yet configured, you’ll restore:
sudo pihole -a -r restore
This will prompt you to select the backup file. Once selected, Pi-hole will unpack and apply all your previous settings. Reboot your Pi-hole (sudo reboot) and within a minute or two, your new Pi-hole will be identical to the old one, serving ads to the void just as you left it.
The problem this solves is the tedious manual re-configuration of Pi-hole across multiple devices or after a system failure. It’s about reproducibility and disaster recovery for your network’s DNS filtering. Internally, pihole -a -t backup essentially archives key files and directories: /etc/pihole/, which holds gravity.list, local.list, wildcard.list, dns-pihole.conf, and various other configuration files; and /etc/dnsmasq.d/, which stores your custom 01-pihole.conf and any other custom configurations you’ve added. The restore command unpacks these into the appropriate locations, overwriting existing (likely default) configurations.
The exact levers you control are the backup and restore commands themselves. You initiate the process, and Pi-hole handles the rest. You can automate this backup process using cron jobs to regularly save your configuration to a remote location, ensuring you always have a recent copy. For instance, a daily backup could be scheduled like this:
echo "0 3 * * * root pihole -a -t backup" | sudo tee /etc/cron.d/pihole_backup
This would run the backup every night at 3 AM.
What most people don’t realize is that the pihole -a -r restore command is smart enough to detect if Pi-hole is already installed and running. If it is, it will warn you that it’s about to overwrite existing configurations and ask for confirmation. This prevents accidental data loss if you’re trying to restore onto a Pi-hole that’s already in use and has different settings. You can bypass this confirmation with the -force flag, but use it with extreme caution.
The next concept you’ll likely encounter is managing multiple Pi-hole instances and ensuring their configurations remain synchronized, perhaps using a version control system for your backup files.