-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tentacool container volume export backups #334
Comments
Starmie's HASS volume backup is ~150MB, ~120MB of which is |
Zigbee2MQTT's database (?) should be backed up as well. |
HASS is now up to 450MB for a backup, almost all of which is down to the database. This should grow with devices and history but not with time, as by default history is purged after ten days. Apparently that's all the database is used for. I don't really need this backing up given my horrendous upload bandwidth. |
Down to 33MB if I: tar -f backup.tar --delete home-assistant_v2.db |
28MB: tar -f backup.tar --wildcards --delete "home-assistant_v2.*" |
A zip backup can be requested and downloaded from the Zigbee2MQTT UI. For me right now it's tiny, ~30kB. |
Also a nicer way to:
Would be nice. |
Is there a declarative backup solution? |
^ Here we go: 75f3be0 On Restoring etc from Alakazam is a bit of a faff Should things look good tomorrow let's keep running the manual backup script as normal for now. The plan is to test how this works for a few weeks, including with restores, then remove or otherwise deprecate the Duplicity buckets and remove all calls to Duplicity from the backup script. At that point it's a case of figuring out how to automate the remaining bits of the backup script. I imagine much or all of it can be handled via systemd timers managed by Nix. Ideally at some point everything will be backed up automatically, almost all of it declaratively via Nix. |
^ Looks like the buckets are populated and the services all ran at 4AM on Tentacool. At the moment they run in parallel, that seems to be working fine but something to keep in mind is possibly offsetting them. |
Restic backups look like they're working well. Only annoyance right now - not a blocker - is that the paths are Edit: It's also including backups for the Synology |
^ For the unwanted metadata: 81f4dbb Deployed to Tentacool. Coming through in the backup commands in the units as Raised the linked issue for the duplication between this and the wallpaper script. |
Let's test it tomorrow after another scheduled backup runs. Currently the latest snapshot includes the unwanted files: $ <B2 ENV> restic --password-command <PASS CMD> -r b2:archive-restic2 ls latest | rg '(eaDir)|(.DS_Store)'
<many results> |
^ Working well for a few weeks. Backup script trimmed down: f54d6d8 |
Mostly done. Next most relevant improvement tracked at #378. |
Via sftp?
The volumes are pretty big, ~150MB in some cases. I might not want to back this up weekly when so little tends to change in that timeframe?
From experience I don't trust the in-app backups for either HASS or Pi-Hole to actually back everything up.
The text was updated successfully, but these errors were encountered: