Possible issue with readme restore steps

[JonMurphy]

Reference #826 (comment)

I am in the rebuilding stage I tried the restore steps from the README and you are correct about the compose-dash stop at the beginning. I ran into the same.

The Restore steps have other issues related to permissions so I am experiencing problems that are fixed with chown/chmod. Below is a companion script to backup (similar methods/variable names/etc).

This was created with my new friend Claude. The basis is the backup script 7d4f5e9 and the README (before the compose-dash changes.

Below is the current test script. This should work for both a same machine restore and a migration to a new machine. Please take it from here and ask Sam to check and make sure all is OK. Feel free to make any changes. I will be happy to test.

restore_v16a.sh

[jasonacox-sam]

@JonMurphy — this is excellent work. I've read through the full script and it's a genuinely good companion to backup.sh.sample. A few things that stand out as improvements over the manual restore steps currently in the README:

Smart PWD_USER derivation — deriving the owner:group from compose-dash.sh's on-disk ownership + the host's docker GID (instead of trusting compose.env) is the right call. compose.env can get overwritten during restore, but the live filesystem doesn't lie. Rewriting PWD_USER from the detected value makes this self-correcting on every restore — great for cross-machine migration.

Pre-restore safety copies — moving influxdb/{data,meta,wal} aside (rather than DROP DATABASE) means you get a rollback path. If the restore fails, the old data is still there. The README approach is destructive by comparison.

Correct InfluxDB flow — stopping everything, bringing only influxdb back up, then running influxd restore -portable -db powerwall matches the backup format (which uses -database powerwall). Clean and targeted.

I think this would be a great addition to PR #826 as a restore.sh.sample — it pairs naturally with backup.sh.sample and the permission handling solves exactly the problems you hit during testing. @jasonacox — would you like me to fold this into the PR (adapted to match the backup script style), or would you prefer to keep it as a community contribution?

Either way, thanks for writing this and testing it against a real restore. That's how the rough edges get found.

— Sam 🌊

[jasonacox]

Create a new PR @jasonacox-sam

[jasonacox-sam]

PR created → #838

@JonMurphy — your script is in there with full credit. I adapted the variable naming and structure to match backup.sh.sample so the two scripts read as a natural pair. The core logic — smart PWD_USER derivation, pre-restore safety copies, non-destructive InfluxDB restore — is all yours and kept intact.

The README now points to restore.sh.sample as the recommended method, with the manual steps preserved as fallback.

— Sam 🌊

[JonMurphy]

I'll add comments to #838

[hulkster]

FYI FWIW that I'll be looking for the formal release of the restore script and will test on my systems.

Thanks @JonMurphy (and others) for making the backup process more robust ...

[JonMurphy]

your script is in there with full credit.

Claude AI deserves more credit than I do

[jasonacox-sam]

Closing this issue — PR #838 resolves it completely.

The manual restore steps that originally tripped you up are now replaced by restore.sh.sample, a companion to backup.sh.sample that handles InfluxDB snapshots, Grafana databases, config files, weather411 config, and Tesla .auth/ tokens — with pre-restore safety copies, CQ replay, and cross-machine migration support.

Your restore_v16a.sh was the foundation for all of it. Thank you for kicking this off.

— Sam 🌊