The limits of my main strategy
In a previous article, I discussed how I implement the 3-2-1 principle: one local backup on my NAS, and one on a remote object storage location.
Both are incremental and managed using restic.
This approach is generally good but has some limitations:
- Not all systems you find in a homelab or SME will support
restic. Some complementary measures are necessary for elements such as Home Assistant, which I use as a Virtual Appliance. - File-system level backups can make the recovery of useful information a tedious task. In a post IT failure situation, this may be deemed acceptable but you may want to recover access to critical information as quickly as possible. Passwords, which I manage through Vaultwarden, are a good example of this use case.
This article describes how I implemented backup for these situations in my home network.
Home Assistant
Nabu Casa has been putting a significant amount of work on the backup feature of Home Assistant, which now supports a lot of targets:
- Local file system
- NFS & SMB
- Various network & cloud services
Getting data to S3
The first backup location is easy:
- Create a shared folder and dedicated user on my Synology NAS.
- Add it to Home Assistant as a Backup type network storage.
- Enable backups to that new location from the UI.
Now, the real problems begin: how do I get my Home Assistant backups replicated on an S3 storage ?
A bit of Web search got me to several options:
h1f1x/hass-addon-s3-backup- Last commit 10 months ago, unsure if it’ll work with the revamped backups of HA 2025.x.
- Specifically bound to Amazon S3, it’ll require at least some forking and tuning to work with Cyso or OVH.
mkohns/hassio-addons/s3bkacup- Last commit 5 months ago - same risk as the previous entry
- From the add-on configuration file, it appears to support custom S3 targets.
- Relies on MQTT (good) and GPG (bothersome). HA now natively encrypts the backups. If I can avoid setting up dedicated GPG keys, I will.
Rbillon59/hass-backup-s3- Not updated for two years, and based on Issues and Pull Requests, will need some work. Disappointing but not a deal breaker at this point.
- Supports custom S3 targets and has optional GPG - promising !.
There is however a fundamental issue with going down that road: all these add-ons work by cloning a local backup on the HAOS node to an S3 location. Since I take my local backup direction on my NAS, there’s no folder to expose to the HA add-on and, hence, nothing to backup.
I could solve this two ways:
- Take a single local backup on the HAOS VM and use this as a basis for bucket sync with incremental backups to keep some history remotely.
- Move this whole story to the NAS.
I went with the second option to avoid installing yet another add-on from yet another source on my HAOS VM. Mirroring data to an S3 bucket is a native feature of the Synology DSM OS. Always go native when you can.
I ended up setting up an Hyper Backup job that mirrors the backups received through SMB from HAOS to an OVH Object Storage bucket. For some reason, I could not get Hyper Backup to work with a Cyso S3 bucket, and decided not to investigate further. My second backup copy is in a different location and country, I’m happy and willing to move on.
I could alternatively mount the shared folder from the NAS elsewhere, and then mirror it using restic.
Maybe someday I will! The functional result would be the same, only taking out the closed-source Hyper Backup application from the loop.
Rejected alternatives
n8n
I don’t use n8n but if I did, this highlighted an interesting approach to make an S3 object storage interface with HA using the worklow manager as a third party.
If you have n8n running for other reasons, that can be a valid approach - but it felt vastly overkill here.
kDrive via WebDAV
It is worth noting that Home Assistant also supports WebDAV as a backup destination. Being an Infomaniak user, I was tempted to use their web storage solution kDrive as a backup target: it is not located in my home country, still in Europe, with a good reliabilty and security reputation.
Alas, that idea was short lived: WebDAV access to kDrive is restricted to professional plans, which I don’t use, and found no alternative for.
Had a command-line Linux kDrive client existed, I could have figured something out with rsync, but that quickly proved to be a dead end.
Vaultwarden
In case my home infrastructure completely crashes or something really bad happens to me, I want my passwords to be somewhat easily recoverable for a legitimate person. Needing to pull a restic backup, decrypt it, extract the Vaultwarden container volumes, restore them to a new Docker container and finally get access to the information is the very definition of not easy.
I thus need to figure out two things:
- How to export a Vaultwarden database into a usable yet secure format, such as a KeePass database?
- How do I back this up properly?
Exporting in readable way
When you look for a way to backup Vaultwarden, the first ressources that come up (for instance: 1, 2, 3) all focus on exporting the actual data structure of Vaultwarden. While not incorrect, it does not bring value to my issue. I already take a mirrored backup of this by having restic snapshot the data volume of my Docker containers to both my NAS and a remote object storage.
The native export formats of Vaultwarden are json and csv.
The CSV export could fit the bill, but it’s by essence unencrypted.
Let’s look into a KeePass solution instead if possible:
k3karthic/bitwarden-to-keepass: Supports exports from the main BitWarden service or JSON unencrypted file to generate KeePass files. Could be used as basis to create a Docker service running on a scheduled basis, but will require some forking and tuning to work with a self-hosted Vaultwarden server.genericFJS/vaultwarden2keepass: A Docker-centric project to export a Vaultwarden vault to a KeePass database. Does not support scheduling nor cloud storage, but both are things I can work around of without any issues.querylab/lazywarden: A full fledged solution for automated Vaultwarden backups.
lazywarden looks nice but requires setting up Bitwarden Secret Manager and is overall akin to a sledgehammer to push a very small nail. On the other hand, vaultwarden2keepass looks convincing: the source code is simple, auditable, doesn’t reveal any obvious issue, and should be able to run fully locally in a Docker container disconnected from the Internet.
Looks like we’ve got ourselves a winner!