In Pi-Hole v5.18 and FTL v5.25, is there a way to backup and restore all settings? In particular, I'm interested in using something like Nebula-Sync to keep several Pi-holes in sync for failover purposes.
Pulling a backup via Teleporter works great for a lot of settings, but the DNS settings do not seem to be included. In particular, the Upstream DNS and Advanced DNS settings don't come over in the teleporter file. Any suggestions?
Please don't resurrect old threads, especially not ones with a marked solution, relating to Pi-hole's v6 beta, where you seek advice on the current Pi-hole 5. I have separated your post into a new topic.
Please share the result of:
zgrep -a server= <pi-hole-teleporter-file>.tar.gz
Substitute <pi-hole-teleporter-file>.tar.gz with your actual teleporter filename.
Apologies for reviving old threads. I should have started a new one!
It's specifically the rev-server and server lines from dnsmasq.d/01-pihole.conf that are left out when I apply the tar.gz through the teleporter interface. The exact steps I use are:
Create a backup through teleporter web interface on the "primary" and download to third device
Upload the backup through teleporter web interface on the "target" choose Clear existing data and hit Restore
For good measure, I've restarted the target with sudo systemctl restart pihole-FTL.service
4. no change in DNS settings -- other settings such as client groups appear as expected.
Here's the output from zgrep for the "primary" pi-hole instance that has the settings I wish to propagate to other instances:
The zgrep output shows that the teleporter backup contains your router as upstream as well as Conditional Forwarding target.
On a side note: When using your router as Pi-hole's only upstream, CF won't add any benefits, as your router will already receive all DNS requests.
Anyway, that is the file you should import into your new Pi-hole.
When restoring that media-server backup to your new Pi-hole, do you encounter any errors?
After having restored the backup, on the new Pi-hole machine, what's the output of:
Thanks for taking the time to help me out. I really appreciate it!
There have been no errors at all in the process. Here's the output from both devices after running a restore based on a backup:
Target:
# Pi-hole: A black hole for Internet advertisements
# snipped header for brevity
addn-hosts=/etc/pihole/local.list
addn-hosts=/etc/pihole/custom.list
localise-queries
no-resolv
log-queries
log-facility=/var/log/pihole/pihole.log
log-async
cache-size=10000
server=192.168.1.1
domain-needed
expand-hosts
bogus-priv
local-service
Primary:
# Pi-hole: A black hole for Internet advertisements
# snipped header for brevity
addn-hosts=/etc/pihole/local.list
addn-hosts=/etc/pihole/custom.list
localise-queries
no-resolv
log-queries
log-facility=/var/log/pihole/pihole.log
log-async
cache-size=10000
server=192.168.1.1
domain-needed
expand-hosts
bogus-priv
interface=enp6s0
rev-server=192.168.1.0/24,192.168.1.1
server=/txoof.com/192.168.1.1
Can you elaborate regarding this?
On a side note: When using your router as Pi-hole's only upstream, CF won't add any benefits, as your router will already receive all DNS requests.
I chose this because I'm using my router, a Ubiquity Dream Machine, to pull down the ISP's DNS settings. The UDM also provides facility for naming devices based on interface mac address. The end result is that local devices can be accessed with custom-name.txoof.com. I use this to keep track of the various pis on the network giving them names like "P4-126" (Pi 4, 192.168.1.126) so I can connect to them a little easier and keep track of which device is which, hence the "server=" line.
I'm not an expert and definitely open to suggestions if I'm doing something dumb or inconvenient.
Indeed, while the teleporter backup file contains the entire /etc/dnsmasq.d/ directory, the restore code seems to consider only specific files (04-pihole-static-dhcp.conf, 05-pihole-custom-cname.conf) - essentially, only those that have a matching entry in the teleporter's UI tick list.
You'd have to edit those settings manually, as they are not handled by teleporter restoration.
Isn't that obvious?
Conditionally Forwarding allows involvement of an additional DNS server, usually in order to answer DNS queries for a specific domain and IP range that only that DNS server knows about and public DNS servers wouldn't be aware of.
But in your case, the DNS server with such local knowledge (192.168.1.1) is already used as Pi-hole's only upstream:
So you are telling your Pi-hole:
Forward all queries to 192.168.1.1, except when queries match *.txoof.com, forward to 192.168.1.1 instead.
This is redundant.
You can disable Conditionally Forwarding, as your 192.168.1.1 already receives all DNS requests.
Yes, the reason is that 01-pihole.conf is meant to be auto-generated/derived from other configuration only (there is a header saying this if I'm not mistaken).
This will be improved in Pi-hole v6.0 which offers you a dedicated field where you can add arbitrary additional dnsmasq config lines which will then be considered part of the overall configuration and backup-ed/restored via Teleporter.
Thanks for clarifying it's obvious now that you've explained what I'm doing. I'll do some experimenting with simplifying this. That might lead to a solution that's easier to replicate across devices.