Traccar TimescaleDB old positions get deleted

fts 22 days ago

Hi,

I tried out the latest Traccar 6.11.1 with a TimescaleDB. I successfully migrated my data from an older Traccar 5.4 installation with Postgres 13 database to a new Docker based Traccar installation.
The migration of the database from old format to newest format including TimescaleDB features went through without major issues.

But afterward I realized that process removed most of my older data. I found out that Traccar is configuring TimescaleDB with a 1 year retention policy by default:

> psql -U traccar -d traccar -c \ > "SELECT job_id, proc_name, schedule_interval, config > FROM timescaledb_information.jobs > ORDER BY job_id;" job_id | proc_name | schedule_interval | config 
--------+-----------------------------------+-------------------+---------------------------------------------------------------------------------------- 
1 | policy_telemetry | 24:00:00 | 
3 | policy_job_stat_history_retention | 06:00:00 | {"drop_after": "1 month", "max_failures_per_job": 1000, "max_successes_per_job": 1000} 
1000 | policy_retention | 1 day | {"drop_after": "1 year", "hypertable_id": 3} 
1001 | policy_retention | 1 day | {"drop_after": "1 year", "hypertable_id": 1} 
1002 | policy_retention | 1 day | {"drop_after": "1 year", "hypertable_id": 2} (5 rows)

I think a 1 year retention policy should not be the default, but keeping all data should be the default as before.
Enabling retention policy should be an option that the users can activate if they wish.

Best regards

Anton Tananaev 22 days ago

Let's see what other people think, but in my experience 1 year (or lower) is the most common value people want to use.

sem13 20 days ago

Здравствуйте. Подскажите параметр в конфигурационном файле <entry key='database.historyDays'>365</entry>, ничего не решает или можно поставить 730 и данные будут дольше храниться?

Anton Tananaev 20 days ago

That parameter doesn't exist anymore.

Kalabint 20 days ago

The new retention policy is not noted at all in the Blogpost for 6.11.0.

So Users updating to the newest version and on a PostgreSQL DB will be surprised if they suddenly only have 1 Year of Data left to view.

If I ask via Traccar ChatGPT Support Link, I get the same answer as sem13. It only answer correctly, when I link to this thread directly, and even then the LLM contradicts itself nonstop due to old Information (another reason not to trust chatbots).

I disabled TimescaleDB completly on my PostGIS installation, because I'm using it as an archive and made other modifications which are not compatible with TimescaleDB.

It would be a good idea to allow Users to edit those settings in an easier way, than to modify the DB changelog-6.11.0.xml file at runtime.

Anton Tananaev 20 days ago

OK, it sounds like it's safer to remove the policy for now:

https://github.com/traccar/traccar/commit/645faa375a203d54e3c45220d13b59a589787300

fts 19 days ago

My use case is to use Traccar has a personal archive of my travels. That's why I want to keep all my data.

depth7503 9 days ago

I'm grateful for the reversion as I too wanted a historical archive of my positions.

I could see value in per device/user retention policy.

I actually didn't realize I lost years of data when I upgraded to timescaledb last year, until reading this post and checking for old records. I'm pretty sure I have backups of most of it though. Can anyone offer pointers on what's important to not screw up when bringing in old position records to timescaledb?

And, will updating to 6.11 remove the 1 year policy or do I have to manually change something else still?

Anton Tananaev 9 days ago

You need to wait till next release.