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?

  • bigDottee@geekroom.techEnglish
    2·
    4 days ago

    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!

  • SavvyWolf@pawb.socialEnglish
    5·
    10 days ago

    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.

    • Kng@feddit.rocksEnglish
      3·
      10 days 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.

  • bluGill@fedia.io
    2·
    9 days ago

    Just remember any backup is better than nothing. Even if the backup is done wrong (this includes untested!) odds are you can read it and extract at least some data, it just may take a lot of time. Backups that are done right just mean that when (not if!) your computers break you are quickly back up and running.

    There are several reasons to backup data only and not the full system. First you may be unable to find a computer exactly/enough like the one that broke, and so the old system backup won’t even run. Second, even if you can find an identical enough system, do you want to, or maybe it is time to upgrade anyway - there are pros and cons of arm (raspberry pi) vs x86 servers (there are other obscure options you might want but those are the main ones), and you may want to switch anyway since you have. Third, odds are some of the services need to be upgraded and so you may as well use this forced computer time to apply the upgrade. Last, you may change how many servers you have, should you split services to different computers, or maybe consolidate the services on the system that died to some other server you already have.

    The only advantage of a full system backup is when they work they are the fastest way to get going again.

    • RadDevon@lemmy.zipOPEnglish
      1·
      8 days ago

      Just remember any backup is better than nothing.

      This is comforting.

      There are several reasons to backup data only and not the full system. First you may be unable to find a computer exactly/enough like the one that broke, and so the old system backup won’t even run. Second, even if you can find an identical enough system, do you want to, or maybe it is time to upgrade anyway - there are pros and cons of arm (raspberry pi) vs x86 servers (there are other obscure options you might want but those are the main ones), and you may want to switch anyway since you have. Third, odds are some of the services need to be upgraded and so you may as well use this forced computer time to apply the upgrade. Last, you may change how many servers you have, should you split services to different computers, or maybe consolidate the services on the system that died to some other server you already have.

      Some good things to consider here. Whether or not I’ll want to upgrade will depend on how far this theoretical failure is. If storage fails, I might just replace that and restore the backup. If it’s something more significant than that and we’re 2-3 years down the line, I’ll probably look at an upgrade. If it’s less than that, I might just replace with the same to keep things simple.

      I guess one other upside of the full system backup is that I could restore just the data out of it if I decide to upgrade when some hardware fails, but I don’t have the reverse flexibility (to do a full system restore) if I opt for a data-only backup.

  • MangoPenguin@lemmy.blahaj.zoneEnglish
    2·
    10 days ago

    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.

    • RadDevon@lemmy.zipOPEnglish
      1·
      10 days ago

      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!

      • MangoPenguin@lemmy.blahaj.zoneEnglish
        2·
        10 days 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.

  • Appoxo@lemmy.dbzer0.comEnglish
    1·
    7 days ago

    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

    Having any sort of functional (best case tested) backup is more than a majority has ever achieved on a computer.

    Personally I am using Veeam with a (free) NFR license.
    Though the community edition is plenty for most situations.

    As for what I backup: It depends.
    My main file storage is backed on a volume basis
    My gaming/pc is also volume based but I have another job that backs my game ROMs
    My linux server is backed fully as to not loose anything on it
    My LDAP server as well as my financial VM is fully bavked up because it’s so small.

  • unlogic@lemmy.zipEnglish
    1·
    9 days ago

    I don’t do a full system backup, just data I need. I use restic to backup to B2 storage. As for docker data and databases I have a script that brings down the containers, runs a sqldump (or db type equivalent) into a tar.bz file and that gets backed up before bringing the containers back up. I used to run a Borg backup to a local drive and then rclone that to B2 so I have live data, local data, and remote. But these days I just back up remote and suck up the egress costs if needed.

  • Scrubbles@poptalk.scrubbles.techEnglish
    11·
    10 days ago

    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.

    • RadDevon@lemmy.zipOPEnglish
      2·
      10 days ago

      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. 😅