I’m in the process of setting up backups for my home server, and I feel like I’m swimming upstream. It makes me think I’m just taking the wrong approach.

I’m on a shoestring budget at the moment, so I won’t really be able to implement a 3-2-1 strategy just yet. I figure the most bang for my buck right now is to set up off-site backups to a cloud provider. 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.

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.

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?

  • marcos@lemmy.worldEnglish
    2·
    6 hours ago

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

    If you don’t have the budget for on-premises backup, you almost certainly can’t afford to restore the cloud backup if anything goes wrong.

    Then I started reading about backing up databases

    Go read the instructions for your database in particular. They are completely different from each other. Ignore generic instructions.

    now I’m configuring a docker-db-backup container

    What is perfectly fine. But I’d first look how this interferes with the budget you talked about earlier and if it wouldn’t be better to keep things simpler and put the money on data replication.

    Either way, if your budget is low, I’d focus a lot on making sure you have the data when you need to restore, and less on streamlining the restore procedure. (That seems to be the direction you are going, so yeah, I’d say it’s good.) Just make sure to test the restore procedure once in a while.