Restore ancient backup

[khorton]

I want to create a new TeslaMate instance so I can import data from a car I sold years ago. The data is a backup made with TeslaMate v1.27.1, from early January 2023.

Is there any likelihood that I could import this data into TeslaMate v4.0.1?

My first thought was to spin up TeslaMate v1.27.1, but I haven't found any hints on what the docker-compose.yml file should contain for that version TM. Or would a current format docker-compose.yml work fine?

[daveshenal]

Yes, this should work... it's a known scenario, and the project's own maintainers/community have walked people through almost exactly this in past Discussions.

A few load bearing facts:

• The Postgres engine matters, not just the TeslaMate version. Since TeslaMate v2.0.0, the app refuses to even start unless the underlying PostgreSQL is 16.7/17.3 or newer. So that's a hard requirement added in a breaking change release, not something Ecto migrations can route around. So you can't restore a 2023 era dump straight into a v4.0.1 stack in one step.. the database has to get walked up to a modern Postgres major version first.
• TeslaMate's own schema migrations are designed to run sequentially from any old state. That part isn't the blocker - starting a current TeslaMate against a much older (but Postgres-version-compliant) schema is exactly what happens on every normal upgrade, just compressed into more migrations running back-to-back.

So the path that matches what's actually documented and recommended for this kind of "old backup, new install" situation is:

1. Spin up the old TeslaMate version first, using image: teslamate/teslamate:1.27.1 (that tag does exist on Docker Hub) alongside a period-correct Postgres - postgres:13 was the documented default around that time. You can otherwise use a modern-format docker-compose.yml; the overall structure (teslamate / database / grafana / mosquitto services) hasn't changed in a way that matters here - you're just pinning the two image tags back instead of using :latest.
2. Restore your teslamate.bck into that stack using the normal Backup & Restore steps, and confirm your old data shows up correctly in Grafana before going further.
3. Walk Postgres up to 16.7+/17.3+ using the official Upgrading PostgreSQL procedure (pg_dump/restore into each next major version) - you may need to repeat this a few times depending on what major version you land on in step 1.
4. Only then bump the TeslaMate image tag to 4.0.1 and start it. It'll run the full chain of pending migrations automatically, same as any in-place upgrade.

One caveat though... I haven't found anyone documenting this exact "~3.5 year old backup straight through to v4.0.1" jump, just the same principle applied to smaller gaps. So treat step 2 as a checkpoint - don't touch your original .bck file until you've confirmed the data looks right there, and keep a copy of the dump at each stage before moving to the next.

[khorton]

Thank you very much for the extremely detailed instructions! I'll report back once I've finished, or if I have questions as I work through the process.

[khorton]

I'll demonstrate my Docker ignorance here: given that this will be a separate TM instance, do I need to specify a unique database name in the docker-compose.yml to avoid interference with my current TM instance? Or, will this new instance be in a completely separate world, with zero possibility of interfering with my older (and still running) TM instance?

[daveshenal]

Completely separate world - no risk to your existing instance, no need to rename the database.

Just do two things:

1. Put the new compose file in its own directory (e.g ~/teslamate-old/). Compose uses the directory name to prefix containers/volumes, so this alone gives you a separate Postgres volume from your existing setup.
2. Use different host ports, since two containers can't bind the same port. If your current instance uses 4000:4000 and 3000:3000, use something like 4001:4000 and 3001:3000 for the new one.

The database name inside the file (teslamate) can stay the same... it's just an internal name inside that container's own isolated Postgres, with no connection to your other instance's database. As long as the directory and ports are different, both stacks run side by side with zero interference.

[khorton]

I put

ports:
     - 4001:4001

in docker-compose.yml, but the logs show that TeslaMateWeb is using 4000:

docker compose logs teslamate
teslamate-1  | 2026-06-21 13:16:28.127 [info] Migrations already up
teslamate-1  | 2026-06-21 13:16:29.642 [info] System Info: Erlang/OTP 24 (jit)
teslamate-1  | 2026-06-21 13:16:29.642 [info] Version: 1.27.1
teslamate-1  | 2026-06-21 13:16:29.665 [info] Running TeslaMateWeb.Endpoint with cowboy 2.9.0 at :::4000 (http)
teslamate-1  | 2026-06-21 13:16:29.665 [info] Access TeslaMateWeb.Endpoint at http://192.168.0.230
teslamate-1  | 2026-06-21 13:16:29.670 [info] MQTT connection has been established
teslamate-1  | 2026-06-21 13:16:32.834 [info] tzdata release in place is from a file last modified Fri, 22 Oct 2021 02:20:47 GMT. Release file on server was last modified Thu, 23 Apr 2026 11:51:51 GMT.
teslamate-1  | 2026-06-21 13:16:33.781 [info] Tzdata has updated the release from 2021e to 2026b

If I stop the original TM (which is using 4000), the browser finds nothing at either 4000 or 4001. If I then edit docker-compose.yml for this new instance to use 4000, and restart it, the browser then finds the new empty TM at 4000.

It seems like the http port for TM is hard coded to 4000 or cached somewhere, unless there is something else I need to do so it is happy to use 4001.

[khorton]

Perfect! Sorry for not digging into the Docker docs

[khorton]

I got the data from the old car restored to TM v1.27.1. Taking a long look at everything to be sure it is correct before making another backup, then doing the steps to upgrade PostGres to v17.3

[khorton]

Looking at the various dashboards after importing the old data, the only obvious issue I see is that the Drives dashboard shows errors 'db query error: ERROR: column "ascent" does not exist'.

Looking at the code history, the column "ascent" seems to have arrived in v2.1.0. So, I wonder if somehow Grafana is using current dashboards to look at my old data. If that is the case, I assume that I can ignore this error for now, and everything will magically work after I grind through the process to upgrade TM from v1.27.1 to v4.0.1.

[daveshenal]

Yeah... You're running v1.27.1 data with current Grafana dashboards that expect columns added in later versions. The ascent column (and likely a few others) simply don't exist yet in your schema.

Safe to ignore for now... once you upgraded to 4.0.1, the migrations will add all the missing columns and the dashboard errors will go away on their own.

[khorton]

I finished the step by step Postgres updates from 13 to 17.3+, making backups at each step. Then I edited the TM version in docker-compose.yml to 'latest' and did a TM update. Everything seems to be correct. I can now see the drives, as we apparently now have an 'ascent' column.

The one puzzling thing is that somewhere in the process the database got car ids and VINS for the two Teslas that I bought subsequent to the one whose data I am importing. It didn't have any other data for those two cars - only the VIN. My theory is that the info came in from Tesla via the Tesla Auth token log-in process, as my Tesla login has that info tied to it. I deleted those unwanted IDs from cars and car_settings.

Thanks so much for all the help.