Hey there,
I’m in need of a bit of wisdom here:
I recently got myself a shiny new Vserver and have it running exclusively with docker containers that use regular volumes.

Now: how would I back this thing up? I mean, I have read a lot about borg for example, but I’m not sure how to do it the right way:
Do I just copy / to a repo and fiddle the data back in place if stuff goes wrong, or would it be wiser to backup the volumes, do a docker save and export the images to a folder and then send that to the storage box?

Since docker should stop the containers to prevent data inconsistency during a backup: How do I tell Borg to do that? I’ve seen several approaches (Borg Dockerized with some sort of access to docker’s .sock, Borg setup on the host, and some even wilder approaches).

Since Backups aren’t something you can “try again” once you need them, I’d rather have a solution that works.

  • SpaceCadet@sopuli.xyzEnglish
    201·
    1 year ago

    As a general rule, you should always keep in mind that you’re not really looking for a backup solution but rather a restore solution. So think about what you would like to be able to restore, and how you would accomplish that.

    For my own use for example, I see very little value in backing up docker containers itself. They’re supposed to be ephemeral and easily recreated with build scripts, so I don’t use docker save or anything, I just make sure that the build code is safely tucked away in a git repository, which itself is backed up of course. In fact I have a weekly job that tears down and rebuilds all my containers, so my build code is tested and my containers are always up-to-date.

    The actual data is in the volumes, so it just lives on a filesystem somewhere. I make sure to have a filesystem backup of that. For data that’s in use and which may give inconsistency issues, there are several solutions:

    • docker stop your containers, create simple filesystem backup, docker start your containers.
    • Do an LVM level snapshot of the filesystem where your volumes live, and back up the snapshot.
    • The same but with a btrfs snapshot (I have no experience with this, all my servers just use ext4)
    • If it’s something like a database, you can often export with database specific tools that ensure consistency (e.g. pg_dump, mongodump, mysqldump, … ), and then backup the resulting dump file.
    • Most virtualization software have functionality that lets you to take snapshots of whole virtual disk images

    As for the OS itself, I guess it depends on how much configuration and tweaking you have done to it and how easy it would be to recreate the whole thing. In case of a complete disaster, I intend to just spin up a new VM, reinstall docker, restore my volumes and then build and spin up my containers. Nevertheless, I still do a full filesystem backup of / and /home as well. I don’t intend to use this to recover from a complete disaster, but it can be useful to recover specific files from accidental file deletions.

    • fraydabson@sopuli.xyzEnglish
      2·
      1 year ago

      This one offers the most info on understanding backups!!

      For my own use I am a fan of rsync. Sync my files to a backup hard drive and off site location. Just backup the compose files and directories.