Dear all,
I am a satisfied Pi-hole user since early 2018. Last week the Pi-hole suddenly was not functioning anymore. It seems that the SD-card was EOL. I managed to make a backup by Teleporter. A .tar file was created.
I bought new SD-cards and decided to install Pi-hole on a RPi v4 instead of v3B I came from. It was running Home Assistant, but I never ended that 'project' after starting it a year a go.
I installed Raspberry headless on the SD-card and started the RPi v4. After booting up I managed to install Pi-hole with the bash-command. The same static IP address was applied and I logged in the admin GUI.
Expected Behaviour:
I expected to restore the backup I made last week with the Teleporter function. But to my surprise Pi-hole expected a tar.gz file. So I added '.gz' to the file name; without success. After that I extracted the backup file ti find the settings; no succes.
Actual Behaviour:
The actual behavior I have described above. Also what I have tried to solve it.
Is there a way to get the settings back? As you can imagine I have six years plus of added white and black lists domains, I have added sources of domains to be blocked etc. I really would like to get these back..
This is because your web browser has "helpfully" unzipped the .tar.gz file when it downloaded, giving you a .tar file. This behaviour might normally be helpful but, as you've discovered, Pi-hole wants that file zipped, so to fix it you can zip it back up again.
First of all, rename the downloaded file back to just file.tar. Then gzip it back up with
gzip file.tar
This will give you a valid file.tar.gz which you can then Restore into Pi-hole in Settings > Teleporter and get your settings back.
Had a look at your debug log to see if everything else looks okay. There are a couple of issues that need fixing.
First, your router is the DHCP server at 192.168.1.1 and it is giving clients four DNS servers to use. One is Pi-hole, the other three are external servers. This means your clients will be able to bypass Pi-hole in normal operation. The DHCP server must ensure that only Pi-hole's IP is given to clients to use for DNS.
Second, there is another DHCP running at 192.168.1.234 which is giving clients the router to use for DNS. Any client which gets its IP from that device will not be using Pi-hole at all. And, if the DHCP ranges overlap, you'll get address conflicts popping up in the client OSes. It would be worth identifying this device and disabling its DHCP server if you weren't aware it was running.
At chrislph
Thank you very much! This has done the trick for me. I could restore the backup file and see mu white and black listed domains again. Also the update with Gravity of my lists with domains to block works as expected.
I also had a look at the DHCP at 192.168.1.234. It is the dhcp server in the Gree airco to be able to connect to the wifi and to an app on a phone. I will Google how to disable this DHCP server. Because I never noticed before I think it is only function on the wifi. On the RPi with Pi-hole I have disabled the wifi, hopes this helps a bit.
At rdwebdesign
Thanks for the link and the background information. I will never forget this.