Your problem is that the chain of untrust has not hit the ground yet.

At some point, you need to trust some technology or system.

You can continue until you are in comfortable ground and then build you trust chain. But honestly following your line of thoughts you will probably end up in a non digital area.

In my case I followed a similar path, but I am totally aware that I can not put resistance to a well funded and well manned intelligence agency, so the high quality industrial level is probably fine for me.

I have several copies on f my backups and all of them are encrypted and signed with rsa, the so are all of them open sources and well audited versions. The only point I relaxed is my phone and I try not have sensitive information on it but vpn and proxies just in case I need them.

I almost don’t use cloud services anymore and the one that I use he a nice record for keeping privacy.

My objective is not to stop Cia, but industry, scammers and all other nasty guys in the wild.

It is tiring, uncomfortable and sometimes cumbersome. But I think it is worthy

First, second and third most important point is : Tesla needs to allow the connection to an alternative server.

The fourth should be access to the api and data that are exchanged.

You shouldn’t mess with the FW of your own car even for some innocent feature like this one, you don’t know/understand the interactions that may happen between different Sw components and the hw layer, you can not provide a similar of level of testing, including some worst case scenarios, that can make your car unsafe during some problems or unforeseen conditions. And perhaps also, the car could loose its license for driving…

If tesla allows that, then we can start speaking about it. But last time I check on that was not possible

Some clarifications :

The 3 2 1 rule applies only for the data. Not the backup, in my case I have the real/live data, then a daily snapshot in the same volume /pool and a external off-site backup

For the databases you got misleading information, you can copy the files as they are BUT you need to be sure that the database is not running (you could copy the data and n the middle of a transaction leading to some future problems) AND when you restore it, you need to restore to the exact same database version.

Using the export functionality you ensure that the data is not corrupted (the database ensure the correctness of the data) and the possibility to restore to another database version.

My suggestion, use borgbackup or any other backup system with de duplication, stop the docker to ensure no corruptions and save everything. Having a downtime of a minute every day is usually not a deal breaker for home users