Pi-hole’s long-term statistics are actually a lie, and the system is designed to break your heart by deleting data you thought was safe.
Let’s see Pi-hole’s long-term data in action. Imagine you’ve got Pi-hole running for a few weeks. You’ve been dutifully checking the "Query Log" and marveling at your network’s ad-blocking prowess. Then, one day, you decide to look at the "Long-Term Data" section. You expect to see the same detailed breakdown, perhaps aggregated over days or weeks. Instead, you’re met with a much simpler, less granular view.
Here’s a snippet of what that might look like in your browser, assuming you’re viewing the index.php?login page and navigating to the "Long-Term Data" section:
<div class="box-body">
<div class="row">
<div class="col-md-6">
<div class="box box-primary">
<div class="box-header with-border">
<h3 class="box-title">Top Permitted Domains (Last 24 Hours)</h3>
</div>
<div class="box-body">
<table class="table table-striped">
<thead>
<tr>
<th>Domain</th>
<th>Count</th>
</tr>
</thead>
<tbody>
<tr>
<td>google.com</td>
<td>1587</td>
</tr>
<tr>
<td>facebook.com</td>
<td>982</td>
</tr>
<!-- ... more domains ... -->
</tbody>
</table>
</div>
</div>
</div>
<div class="col-md-6">
<div class="box box-warning">
<div class="box-header with-border">
<h3 class="box-title">Top Blocked Domains (Last 24 Hours)</h3>
</div>
<div class="box-body">
<table class="table table-striped">
<thead>
<tr>
<th>Domain</th>
<th>Count</th>
</tr>
</thead>
<tbody>
<tr>
<td>doubleclick.net</td>
<td>754</td>
</tr>
<tr>
<td>adnxs.com</td>
<td>512</td>
</tr>
<!-- ... more domains ... -->
</tbody>
</table>
</div>
</div>
</div>
</div>
<div class="row">
<div class="col-md-12">
<div class="box box-danger">
<div class="box-header with-border">
<h3 class="box-title">Total Queries (Last 24 Hours)</h3>
</div>
<div class="box-body">
<div id="queries-over-time-chart" style="height: 250px;"></div>
</div>
</div>
</div>
</div>
</div>
Notice the "Last 24 Hours" constraint. This is the core of the "lie." Pi-hole doesn’t store historical data in a way that allows you to browse weeks or months of detailed query logs. It aggregates some information, but the granular details are ephemeral.
The problem Pi-hole’s long-term stats tries to solve is providing a persistent, aggregated view of network DNS activity without overwhelming the storage or processing power of a typical home server or Raspberry Pi. The actual problem it creates is the expectation of persistent, detailed historical data, which is then disappointed by the reality of its aggregation strategy.
Internally, Pi-hole uses a combination of SQLite databases and log rotation. The primary mechanism for "long-term" data is the /etc/pihole/pihole-FTL.db SQLite database. However, this database is not a simple historical archive. The pihole-FTL daemon, which is responsible for processing DNS queries and maintaining statistics, actively manages this database. It performs periodic "garbage collection" and aggregation.
The key levers you control are primarily within the Pi-hole web interface and its configuration files. The most significant is the database’s size and rotation policy.
When pihole-FTL starts up, it reads its configuration. If the pihole-FTL.db file grows too large, or if a certain time threshold is reached, pihole-FTL will perform an aggregation. This process takes raw query data and summarizes it into daily, weekly, and monthly statistics. Crucially, it then discards the raw, individual query data that has been summarized. This is why you can’t see individual DNS requests from three weeks ago.
The configuration for this behavior is largely implicit and managed by pihole-FTL. However, you can influence it indirectly. The MAXDBDAYS setting in /etc/pihole/pihole-FTL.conf controls how many days of raw data are kept before aggregation and deletion. By default, this is often set to 0, meaning "keep forever" for the aggregated data, but the pihole-FTL daemon’s internal logic and database size limits will still trigger aggregation and deletion of the underlying raw query logs. A more commonly observed behavior is that pihole-FTL aggressively prunes the pihole-FTL.db file, keeping only recent raw data and summarized historical data.
If you want to retain more granular historical data, you must disable the automatic log flushing and aggregation mechanism of pihole-FTL and implement your own external logging and archiving solution. This typically involves disabling pihole-FTL’s internal database management and instead directing Pi-hole’s query logs to a more robust external logging system like Elasticsearch/Logstash/Kibana (ELK stack) or Graylog, and then using those systems for long-term storage and analysis.
A common misunderstanding is that the "Long-Term Data" section is a direct window into an ever-growing historical log. In reality, it’s a curated summary, and the raw data that feeds it is transient. The pihole-FTL.db file itself is managed by pihole-FTL to prevent it from becoming excessively large. When the database reaches a certain size (which is not directly user-configurable in a simple integer value but is an internal threshold), pihole-FTL will prune older data, keeping only the most recent raw entries and the aggregated summaries.
The next thing you’ll likely run into is wanting to export this aggregated data, which Pi-hole’s web interface does not directly support for historical views beyond simple CSV exports of current, non-aggregated data.