this post was submitted on 27 Feb 2025
21 points (95.7% liked)

Selfhosted

42940 readers
478 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 2 years ago
MODERATORS
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
21
Backups: Am I doing this right? (lemmy.zip)
submitted 16 hours ago by [email protected] to c/[email protected]
19 comments fedilink hide all child comments
 

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?

all 20 comments
sorted by: hot top controversial new old
[–] [email protected] 5 points 11 hours ago (2 children)

In regards to full system backups, there's no real need to back up the OS itself. Canonical will give you a clean Ubuntu install if you ask then nice enough, after all. Personally, the risk of having to spend an afternoon reconfiguring my system isn't that big a deal compared to the storage and time needed to back up an entire image.

I know systems generate a lot of "cruft" in terms of instslled programs and tweaked configurations over time which can be hard to keep track of and remember. But imo that should be avoided at all costs because it leads to compatibility and security issues.

For backing up databases, there's scripts like automysqlbackup and pg_dump which will export a database to an sql file which can be easily backed up without worrying about copying a broken file.

I actually recently set up borgmatic earlier today and I'd recommend it except for the fact that you seem to be using Docker, and I'm not sure how best to backup containers.

[–] [email protected] 1 points 5 hours ago

I usually also backup the etc directory so if I had an issue I would at least have the config files from the old setup. This has already saved me a few times when I have really messed up configuration files.

[–] sugar_in_your_tea 1 points 8 hours ago

Yeah, I keep everything as simple as possible. Everything is containerized, and all the configs live in one directory and they store their data on my RAID. I don't need to go track down configs across the system, and adding a new service doesn't require any backup config so no risk of forgetting something.

Docker is simple. You map directories in the container to directories on your host, so you put the important data where it'll get backed up and the less important data (e.g. logs) where it won't.

[–] [email protected] 10 points 16 hours ago (1 children)

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

[–] [email protected] 1 points 13 hours ago

Much easier than what I was trying to do. Thank you!

[–] [email protected] 2 points 16 hours ago* (last edited 16 hours ago) (2 children)

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 main downside is the size of the backup, since you're backing up the entire OS with cache files, log files, other junk, and so on. Otherwise it's fine.

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.

You can back up the data directory, that works fine for selfhosted stuff generally because we don't have tons of users writing to the database constantly.

If you back up /var/lib/docker/volumes, your docker-compose.yaml files for each service, and any other bind mount directories you use in the compose files, then restoring is as easy as pulling all the data back to the new system and running docker compose up -d on each service.

I highly recommend Backrest which uses Restic for backups, very easy to configure and supports Healthchecks integration for easy notifications if backups fail for some reason.

[–] [email protected] 3 points 16 hours ago

Second rest and backrest!

[–] [email protected] 1 points 12 hours ago (1 children)

If that's the main downside to a full-system backup, I might go ahead and try it. I'll check out Backrest too. Looks great!

[–] [email protected] 2 points 12 hours ago* (last edited 12 hours ago)

Yeah there are plenty of advantages of a full system backup, like not having to worry that you're backing up all the specific directories needed, and super easy restores since the whole bootable system is saved.

Personally I do both, I have a full system backup to local storage using Proxmox Backup Server, and then to Backblaze B2 using Restic I backup only the really important stuff.

[–] [email protected] 1 points 16 hours ago* (last edited 16 hours ago) (1 children)

Some things you should determine first:

  1. Total amount of data you will be backing up
  2. Frequency of backups
  3. Number of copies to keep

Plug these numbers into cost calculators for whatever cloud service you're hoping to use, because this is honestly not going to be the cheapest route to store off-site if there are ingress charges like with S3.

I know Cloudflare's R2 service doesn't charge for ingress or egress (for now), but you might be able to find something even cheaper if you're only backing up certain types of data that can be easily compressed.

I'd also investigate cheap ways to maybe just store an off-site drive with your data: office/work, family house, friends house...etc. Storage devices are way cheaper than monthly cloud costs.

[–] [email protected] 1 points 12 hours ago (1 children)

Had considered a device with some storage at a family member's house, but then I'd have to maintain that, fix it if it goes down, replace it if it breaks, etc. I think I'd prefer a small monthly fee for now, even if it may work out more expensive in the long run.

Good call on the cost calculation. I'll take another look at those factors...

[–] [email protected] 1 points 7 hours ago

There's also the option of just leaving an offline disk at someone's and visiting them regularly to update the backup.

Having an entirely offline copy also protects you/mitigates against a few additional hazards.

[–] [email protected] 0 points 16 hours ago* (last edited 16 hours ago) (2 children)

If you're using docker (like your DBs run in docker), then I think you're overthinking it personally. Just back up the volume that the container uses, then you can just plop it back and it will carry on carefree.

I usually did a simple tar cvf /path/to/compressed.tar.gz /my/docker/volume for each of my volumes, then backed up the tar. Kept symlinks and everything nice and happy. If you do that for each of your volumes, and you also have your config for running your containers like a docker-compose, congrats that's all you need.

I don't know who said you can't just back up the volume, to me that's kind of the point of docker. It's extreme portability.

[–] [email protected] 2 points 16 hours ago (1 children)

OK, cool. That’s helpful. Thank you!

I know in general you can just grab a docker volume and then point at it with a new container later, but I was under the impression that backing up a database in particular in this way could leave you with a database in a bad state after restoring. Fingers crossed that was just bad info. 😅

[–] [email protected] 3 points 15 hours ago (2 children)

In theory the database can end up in an invalid state when you leave the database container running. What I do for most containers is to temporarily stop them, backup the Docker volume and then restart the container.

[–] [email protected] 1 points 12 hours ago

Much simpler than my solution. I'll look into this. Thank you!

[–] [email protected] 2 points 15 hours ago* (last edited 14 hours ago) (1 children)

Seconded, and great callout @[email protected] , yes part of my script was to stop the container gracefully, tar it, start it again, and then copy the tar somewhere. it "should" be fine, in a production environment where you could have zero downtime I would take a different approach, but we're selfhosters. Just schedule it for 2am or something.

Oh, and feel free to test! Docker makes it super easy. Just extract the tar somewhere else on the drive, point your container to the new volume, see if it spins up. Then you'll know your backup strategy is working!

[–] [email protected] 1 points 12 hours ago (1 children)

Is your script something you can share? I'd love to see your approach. I can definitely live with a few minutes of down time in the early morning.

[–] [email protected] 2 points 9 hours ago

That particular one is long gone I'm afraid, but it's essentially just docker compose down, tar like I did above, docker compose up -d, and then I used rclone to upload it