I use vnstat to keep track of the network traffic statistics in my Fedora system. Through a web interface, it can show some nice charts. Couple of weeks ago when I was trying to see the stats, it was not loading properly. I initially suspected SELinux but executing vnstat from command line proved that there was some problem with vnstat itself. I got the error "Error: enp1s0: Invalid database daily date order: 1494518195 (3) < 1509896072 (4)"
I couldn't find anything helpful to resolve the issue. All I could do was to downgrade vnstat to previous version. As I have configured dnf to retain the cache, the downgrade was bit easy. The downside was that whenever I was updating the system, I had to pass -x vnstat to dnf command so that it will skip updating it.
From the time stamps that appeared in the error message, I thought that the date format was flipped and instead of May-11, Nov-5 was entered in the database creating the problem. The vnstat database is a binary one but vnstat supports exporting and importing the database. Reading the vnstat manual page gave enough information to export and import the data to a new database.
The following steps were taken to export the data from old database, fix it and then import it to new database.
Create a local configuration file for vnstat.
Copy the /etc/vnstat.conf to a local folder and change the DatabaseDir to point to that local folder.
Copy the vnstat database to the local directory. Export the data file using the command
For example, date -d "2017-05-21" "+%s" will give the time stamp in required format.
Create a new db
The downside was that the data for almost two months were not captured by vnstat. My weekly backup was not configured to capture this data. Lesson learned and I quickly set up an automated backup for the dynamic files using anacron. However, I am yet to figure out a way to validate the sanity of the dynamic data.
I couldn't find anything helpful to resolve the issue. All I could do was to downgrade vnstat to previous version. As I have configured dnf to retain the cache, the downgrade was bit easy. The downside was that whenever I was updating the system, I had to pass -x vnstat to dnf command so that it will skip updating it.
From the time stamps that appeared in the error message, I thought that the date format was flipped and instead of May-11, Nov-5 was entered in the database creating the problem. The vnstat database is a binary one but vnstat supports exporting and importing the database. Reading the vnstat manual page gave enough information to export and import the data to a new database.
The following steps were taken to export the data from old database, fix it and then import it to new database.
Create a local configuration file for vnstat.
Copy the /etc/vnstat.conf to a local folder and change the DatabaseDir to point to that local folder.
Copy the vnstat database to the local directory. Export the data file using the command
vnstat -i wlp3s0 --exportdb > wlp3s0.db For example, date -d "2017-05-21" "+%s" will give the time stamp in required format.
Create a new db
vnstat --config ./vnstat.conf --create -i wlp3s0
vnstat --config ./vnstat.conf -i wlp3s0 --importdb wlp3s0.db --force
vnstat --config ./vnstat.conf -i wlp3s0 -d
vnstat --config ./vnstat.conf -i wlp3s0 -m
sudo systemctl stop vnstat.service
sudo cp ~/vnstat/wlp3s0 /var/lib/vnstat
The downside was that the data for almost two months were not captured by vnstat. My weekly backup was not configured to capture this data. Lesson learned and I quickly set up an automated backup for the dynamic files using anacron. However, I am yet to figure out a way to validate the sanity of the dynamic data.
