Selfhosted

You are looking for a disaster recovery plan. I believe you are going down the right path, but it’s something that will take time.

I backup important files to my local NAS or directly store them on the local NAS.

This NAS then backs up to an off site cloud backup provider BackBlaze B2 storage.

Finally, I have a virtual machine that has all the same directories mounted and backs up to a different cloud provider.

It’s not quite 3-2-1… but it works.

I only backup important files. I do not do full system backups for my windows clients. I do technically backup full Linux vms from within Proxmox to my NAS…but that’s because I’m lazy and didn’t write a backup script to back up specific files and such. The idea of being able to pull a full system image quickly from a cloud provider will bite you in the ass.

In theory, when backing up containers, you want to backup the configurations, data, and the databases… but you shouldn’t worry about backing up the container image. That can usually be pulled when necessary. I don’t store any of my docker container data in volumes… I use the folder mapping from host to directory in docker container… so I can just backup directories on the host instead of trying to figure out the best way to backup a randomly named docker volume. This way I know what I’m backing up for sure.

Any questions, just ask!

I figure the most bang for my buck right now is to set up off-site backups to a cloud provider.

Check out Borgbase, it's very cheap and it's an actual backup solution, so it offers some features you won't get from Google drive or whatever you were considering using e.g. deduplication, recover data at different points in time and have the data be encrypted so there's no way for them to access it.

I first decided to do a full-system backup in the hopes I could just restore it and immediately be up and running again. I've seen a lot of comments saying this is the wrong approach, although I haven't seen anyone outline exactly why.

The vast majority of your system is the same as it would be if you install fresh, so you're wasting backup space in storing data you can easily recover in other ways. You would only need to store changes you made to the system, e.g. which packages are installed (just get the list of packages then run an install on them, no need to backup the binaries) and which config changes you made. Plus if you're using docker for services (which you really should) the services too are very easy to recover. So if you backup the compose file and config folders for those services (and obviously the data itself) you can get back in almost no time. Also even if you do a full system backup you would need to chroot into that system to install a bootloader, so it's not as straightforward as you think (unless your backup is a dd of the disk, which is a bad idea for many other reasons).

I then decided I would instead cherry-pick my backup locations instead. Then I started reading about backing up databases, and it seems you can't just back up the data directory (or file in the case of SQLite) and call it good. You need to dump them first and backup the dumps.

Yes and no. You can backup the file completely, but it's not a good practice. The reason is that if the file gets corrupted you will lose all data, whereas if you dumped the database contents and backed that up is much less likely to corrupt. But in actuality there's no reason why backing up the files themselves shouldn't work (in fact when you launch a docker container it's always an entirely new database pointed to the same data folder)

So, now I'm configuring a docker-db-backup container to back each one of them up, finding database containers and SQLite databases and configuring a backup job for each one. Then, I hope to drop all of those dumps into a single location and back that up to the cloud. This means that, if I need to rebuild, I'll have to restore the containers' volumes, restore the backups, bring up new containers, and then restore each container's backup into the new database. It's pretty far from my initial hope of being able to restore all the files and start using the newly restored system.

Am I going down the wrong path here, or is this just the best way to do it?

That seems like the safest approach. If you're concerned about it being too much work I recommend you write a script to automate the process, or even better an Ansible playbook.

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