Tentacool container volume export backups
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.
Starmie's HASS volume backup is ~150MB, ~120MB of which is home-assistant_v2.db.
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.
https://github.com/samhh/dotfiles/commit/9a20fb5bc1b14ba8fe97efce381caf9e20600caf & https://github.com/samhh/dotfiles/commit/3e93a91100c7c57ec1ec757cd95c0ae9fcd408db
Starmie and Onix wouldn't be necessary if only they were configurable in Nix. Exeggutor always will be as it contains the Zigbee coordinator database.
Still missing some lesser used services.
Also a nicer way to:
- Store/run that script (in the quotes).
- Provide su perms.
Would be nice.
Is there a declarative backup solution?
^ Here we go: https://github.com/samhh/dotfiles/commit/75f3be07fee4cad35f360f1c76812e77646d0506
On restic branch for now. Deployed to Tentacool, let's see what happens overnight. Looks promising after an initial test on Alakazam. Timers are all set up as expected to run at 4am.
Restoring etc from Alakazam is a bit of a faff ~~owing to #360 (NB restic encryption key is also in password store)~~. ~~I think if that were fixed~~ I might be able to include the relevant decrypted env before running restic. For now the backup script can be modified similar to the documentation in the commit.
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 <nas path>/<backup path> rather than just <backup path>. I can't find a Nix option that works around this (by changing PWD). Relevant upstream feature request: https://github.com/restic/restic/issues/2092
Edit: It's also including backups for the Synology eaDir/ dirs, and .DS_Store. Related-ish: https://github.com/samhh/dotfiles/commit/421c66ed4c67062e9fb41ed60ddee911446c0cd6. Could find some way of getting to --exclude.
^ For the unwanted metadata: https://github.com/samhh/dotfiles/commit/81f4dbb2d6b7e4bc8d74739d0433dd51662dc0ed
Deployed to Tentacool. Coming through in the backup commands in the units as --exclude=@eaDir/ --exclude=.DS_Store.
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: https://github.com/samhh/dotfiles/commit/f54d6d84f4a04a9ec40d103c8fa043f42ebd5967
Mostly done. Next most relevant improvement tracked at #378.