Skip to content

Usage # Migrating data

Teemu Toivola edited this page Dec 28, 2023 · 2 revisions

Migrating data from one host to another or keeping the data when doing operating system upgrades or reinstalls

For all vnStat 2.x versions, all data stored by vnStat exists in the single database file vnstat.db that can found in the DatabaseDir directory (/var/lib/vnstat by default). The file is a regular SQLite database file and is cross-platform compatible as a result (for more details, see "Stable Cross-Platform Database File" section in Distinctive Features of SQLite):

The SQLite file format is cross-platform. A database file written on one machine can be copied to and used on a different machine with a different architecture. Big-endian or little-endian, 32-bit or 64-bit does not matter. All machines use the same file format. Furthermore, the developers have pledged to keep the file format stable and backwards compatible, so newer versions of SQLite can read and write older database files.

As long as vnStat and SQLite library versions are equal or greater on the destination system, simply moving the database file is enough to move all the data.

If the interface names don't stay the same, interfaces in the database can be renamed using the vnstat --rename command while the daemon isn't running.

For vnStat 1.x versions, the existing data needs to first be exported for each interface using vnstat --exportdb -i interface1 >interface1.txt to a plain text file and then imported back on the destination system using vnstat --importdb interface1.txt. Note that versions 2.x don't support importing data from an exported text file and as a result, it is not possible to upgrade vnStat version from 1.x to 2.x while moving the database between systems / installations.

Migrating data from vnStat 1.x versions to 2.x versions

All vnStat 2.x versions will automatically migrate data from version 1.x databases during the first version 2.x daemon startup given the following conditions:

  • A version 2.x database file (vnstat.db) doesn't exist in the database directory
  • The version 1.x database files are in the same directory as the version 2.x configuration points to
  • The version 2.x daemon process has read permissions to the version 1.x files
  • The host CPU architecture is the same for both versions

If any of the above conditions doesn't apply then the data migration isn't executed and the content of the new database starts from zero or from the previous content of the database. The data migration doesn't remove any version 1.x database files from the database directory as those are ignored once the database contains any data.

In most cases, assuming there aren't any packaging changes, upgrading the vnStat version 1.x package with a version 2.x package is enough get all data migrated automatically.