pihole restartdns flushes all stats - is that the expected behavior?
Which stats are flushed? All stats should be preserved.
Do you see any errors in
/var/log/pihole-FTL.log
I only see Resizing notifications in that log.
Which stats are flushed?
From the dashboard?
The dashboard graphs show no data and start growing again.
Did you change /etc/pihole/pihole-FTL.conf regarding database settings or logging?
cat /etc/pihole/pihole-FTL.conf
IGNORE_LOCALHOST=yes
PRIVACYLEVEL=0
I've seen this after I manually deleted the long-term database.
What is the output of
ls -lh /etc/pihole/pihole-FTL.db
ls -lh /etc/pihole/pihole-FTL.db
-rw-r--r-- 1 pihole pihole 695M Jul 30 10:47 /etc/pihole/pihole-FTL.db
It looks like the long term database gets dumped with the restart.
Edit: Actually, from the size it looks like it is still there.
It's there and it its huge - maybe that is an issue 
My home network has around 40 clients. : )
Please generate a debug token (pihole -d)so a moderator can have look.
Okay. Generated. How to proceed, should I start a new thread and notify a moderator?
At the end you should have been ask if you would like to upload the log - in return you get a URL (token). Please post the token here. A moderator will have a look if time permits.
@yubiuser - how would one page a moderator? Could I just delete delete that big database and hope for the situation to heal itself?
You do a @moderators 
But please generate a new debug token - the old one expires after 48h.
You could try, but it might not solve a underlying issue. I would wait for further troubleshooting and delete as last resort (will delete all long-time data).
sudo service pihole-FTL stop
rm /etc/pihole/pihole-FTL.db
sudo service pihole-FTL start
Your inital token was still alive.
Sorry for joining late, didn't see this.
First:
I don't think the db size is involved here, I've seen bigger db files working flawlessly.
If you'd want to keep your long term history, it would be enough to move that db file out of the way for the moment instead of removing it completely.
Change the rm line in yubiuser's above commands to.
sudo mv /etc/pihole/pihole-FTL.db ~
Your debug log shows some problems when accessing your database:
*** [ DIAGNOSING ]: contents of /var/log/lighttpd
-rw-r--r-- 1 www-data www-data 9191 Jul 30 13:39 /var/log/lighttpd/error.log
2020-07-30 09:04:57: (mod_fastcgi.c.421) FastCGI-stderr: PHP Warning: SQLite3Stmt::execute(): Unable to execute statement: database is locked in /var/www/html/admin/scripts/pi-hole/php/groups.php on line 535
*** [ DIAGNOSING ]: contents of /var/log
-rw-r--r-- 1 pihole pihole 62727 Jul 30 13:49 /var/log/pihole-FTL.log
-----head of pihole-FTL.log------
[2020-07-30 08:17:12.136 895M] Compiled 0 whitelist and 3 blacklist regex filters for 460 clients in 217.6 msec
[2020-07-30 08:17:19.287 895/T900] Received: Real-time signal 0 (34 -> 0)
[2020-07-30 08:18:17.662 895/T896] IPv4 telnet error: Interrupted system call (4)
[2020-07-30 08:21:36.378 895M] ERROR: set_per_client_regex(332,1,true): Out of bounds (1 > 460 * 0 == 0)!
[2020-07-30 08:21:36.379 895/T896] SQLite3 message: API called with NULL prepared statement (21)
[2020-07-30 08:21:36.379 895/T896] SQLite3 message: misuse at line 83270 of [3bfa9cc97d] (21)
[2020-07-30 08:21:36.379 895/T896] gravityDB_getDomain() - SQL error step: bad parameter or other API misuse
-----tail of pihole-FTL.log------
[2020-07-30 10:46:05.105 1913M] get_client_groupids(SELECT count(id) matching_count, max(id) chosen_match_id, ip chosen_match_text, group_concat(id) matching_ids, subnet_match(ip,'192.168.178.77') matching_bits FROM client WHERE matching_bits > 0 GROUP BY matching_bits ORDER BY matching_bits DESC LIMIT 1;) - SQL error step: database is locked
I haven't seen this combination of warnings and errors before, so not sure what to make of it.
It'd look like a permission issue, but your previous ls -lh output does invalidate that assumption.
I'm also puzzled that the log claims some 460 clients for regex compilation, when there is only one in your database:
*** [ DIAGNOSING ]: Clients
id group_ids ip date_added date_modified comment
---- ------------ ---------------------------------------------------------------------------------------------------- ------------------- ------------------- --------------------------------------------------
1 1 192.168.178.26 2020-05-14 17:38:17 2020-05-14 17:42:51 (name removed by mod)
Can you verify if reading from the Long-term database fails for you as well?
There are also some issues with your chosen IPv6 address, but as these are not related to vanishing statistics, we can tackle them later.
Absolutely no need to apologize. Even though I donated I am fully aware that there is no service level agreement here. Your in-depth analysis is highly appreciated.
I can confirm that accessing long term data from the web interface also fails. I will move the db as instructed. I could live with losing the data if from that point everything start working normally.
I noticed issues with the deny list when I tried adding and removing a domain through the API. I have given up on that for the time being. Nevertheless, the non-loading of data on the dashboard is older than that activity.
Did you ever have those 460 clients with Pi-hole?
You could run a quick integrity check on your db like this:
sudo sqlite3 pihole-FTL.db "PRAGMA integrity_check"