Little bit of everything!

Avid Swiftie (come join us at !taylorswift@poptalk.scrubbles.tech )

Gaming (Mass Effect, Witcher, and too much Satisfactory)

Sci-fi

I live for 90s TV sitcoms

  • 15 Posts
  • 20 Comments
Joined 2 years ago
cake
Cake day: June 2nd, 2023

help-circle












  • Seconded, and great callout @RadDevon@lemmy.zip , 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!


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