Not containers and data, but the images. The point would be reproducability in case a remote registry does not contain a certain image anymore. Do you do that and how?

  • kumi@feddit.online
    link
    fedilink
    English
    arrow-up
    2
    ·
    edit-2
    12 hours ago

    Just a small number of base images (ubuntu:, alpine:, debian:) are routinely synced, and anything else is built in CI from Containerfiles. Those are backed up. So as long as backups are intact can recover from loss of the image store even without internet.

    I also have a two-tier container image storage anyway which gives redundancfor the built images but thats more of a side-effect of workarounds… Anyway, the “source of truth” docker-registry which is pushed to is only exposed internally to the one who needs to do authenticated push, and to the second layer of pull-through caches which the internal servers actually pull from. So backups aside, images that are in active use already at least three copies (push-registry, pull-registry, and whoevers running it). The mirrored public images are a separate chain alltogether.

    This has been running for a while so all handwired from component services. A dedicated Forgejo deployment looks like it could serve for a large part of above in one package today. Plus it conveniently syncs external git dependencies.

    • Bakkoda@lemmy.world
      link
      fedilink
      English
      arrow-up
      3
      ·
      22 hours ago

      This is how i do it. I can delete everything, repull and redeploy like nothing ever happened.

      I have one exception and thats my calibre-web container. I have all my books backed up separately and I’ll be nuking that whole set up eventually.

    • Onomatopoeia@lemmy.cafe
      link
      fedilink
      English
      arrow-up
      4
      ·
      1 day ago

      Curious, have you tested rebuilding using this approach?

      It makes sense to me, if the compose files are up-to-date, it should just work.

      I’d only be concerned about ensuring I capture changes made to the container that happened after initial build.

      • teawrecks@sopuli.xyz
        link
        fedilink
        English
        arrow-up
        2
        ·
        12 hours ago

        I feel like if that’s something you’re doing, you’re using containers wrong. At least docker ones. I expect a container to have no state from run to run except what is written to mounted volumes. I should always be able to blow away my containers and images, and rebuild them from scratch. Afaik docker compose always implicitly runs with --rm for this reason.

      • surewhynotlem@lemmy.world
        link
        fedilink
        English
        arrow-up
        9
        ·
        24 hours ago

        That’s the secret. I never change the container.

        If you absolutely must do some config on the container, then have a container creation script that creates a new container with the right settings and use that.

        #pipelines

      • enchantedgoldapple@sopuli.xyz
        link
        fedilink
        English
        arrow-up
        4
        ·
        1 day ago

        I can attest to it. Lately my server needed to be repaired and got its entire disk wiped. Fortunately I managed to back up my compose files and bind mounts. After reinstalling the OS and transferring the backed up contents, I ran ‘docker compose up’ and eventually everything came back up exactly how they were when being backed up. Even the Postgres backup of Joplin was recovered purely from its bind mount.

  • HelloRoot@lemy.lol
    link
    fedilink
    English
    arrow-up
    18
    ·
    1 day ago

    i selfhost a pullthrough docker repository, so every container I use is stored in there and can be pulled offline.

  • wersooth@lemmy.ml
    link
    fedilink
    English
    arrow-up
    18
    ·
    1 day ago

    if there are some custom image, e.g. additional stuff I added to an existing image, then I backup the dockerfile. you can rebuild the image anytime and the size is smaller than a binary.

    • brvslvrnst@lemmy.ml
      link
      fedilink
      English
      arrow-up
      8
      ·
      1 day ago

      Came here to say that: the most economic solution is to backup any dockerfiles themselves, though that also has the caveat that any installs within the build steps might also depend on external resources that could also be dropped.

      There are methods of adding a local caching layer between your system and external, which might be what OP is after, but that involves investing in the additional space needed to back them up

  • r0ertel@lemmy.world
    link
    fedilink
    English
    arrow-up
    1
    ·
    18 hours ago

    I’ve been looking to do this, but haven’t found a good, easy to use pull thru proxy for docker, ghcr.io and some other registries. Most support docker only.

    This one looks promising but overly complicated to set up.

    A few times now, I’ve gone to restart a container and the repo’s been moved, archived or paywalled. Other times, I’m running a few versions behind and the maintainer decided to not support it, but upgrading would mean a complete overhaul of my Helm values file. Ugh!

    I was considering a docker registry on separate ports for each upstream registry I’d like to proxy/cache.

  • HumanPerson@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    5
    ·
    1 day ago

    I used to but then I switched out the server I was doing backups to and have been thinking “I’ll get to it later” for many months. If anything goes wrong I’m screwed. I’ll get to it later ¯_(ツ)_/¯

  • GreenKnight23@lemmy.world
    link
    fedilink
    English
    arrow-up
    1
    ·
    21 hours ago

    yes. all of the images I use are cached and stored in my locally hosted gitlab registry.

    I think I’ve got around 120-140 images. a lot of what I have is just in case of an emergency.

    I’ve always imagined I could build and run technological infrastructure after a social collapse or something, so I have a lot of images that could be a good basis to start with. Most OS images, popular DB images, etc. it would probably never work, but I’d rather have the option than not.

  • just_another_person@lemmy.world
    link
    fedilink
    English
    arrow-up
    4
    arrow-down
    1
    ·
    1 day ago

    I mean…you have the container right there on your machine. If you’re concerned, just run your own registry and push copies there when needed. This of course is all unnecessary, as you only need the Dockerfile to build a clean image from scratch, and it will obviously work if it’s already been published.

    • 4am@lemmy.zip
      link
      fedilink
      English
      arrow-up
      5
      arrow-down
      1
      ·
      1 day ago

      As long as the internet works and the image is still available.

      Which is kind of the whole point, homie.

      • just_another_person@lemmy.world
        link
        fedilink
        English
        arrow-up
        1
        ·
        edit-2
        1 day ago

        Again, it’s nearly impossible to scrub the entire internet of the code to just run a single command and build a docker image of whatever you were running yourself. If you have the image locally, you can just push it anywhere you want.

        Keep Dockerfile, keep checkouts of what you’re running, or push images locally. All very simple.

  • Eskuero@lemmy.fromshado.ws
    link
    fedilink
    English
    arrow-up
    3
    ·
    edit-2
    1 day ago

    Yes I do. I cooked a small python script that runs at the end of every daily backup

    import subprocess
    import json
    import os
    
    # Output directory
    OUTPUT_DIR = "/data/dockerimages"
    try:
            os.mkdir(OUTPUT_DIR)
    except:
            pass
    
    # Grab all the docker images. Each line a json string defining the image
    imagenes = subprocess.Popen(["docker", "images", "--format", "json"], stdout = subprocess.PIPE, stderr = subprocess.DEVNULL).communicate()[0].decode().split("\n")
    
    for imagen in imagenes[:-1]:
            datos = json.loads(imagen)
            # ID of the image to save
            imageid = datos["ID"]
            # Compose the output name like this
            # ghcr.io-immich-app-immich-machine-learning:release:2026-01-28:3c42f025fb7c.tar
            outputname = f"{datos["Repository"]}:{datos["Tag"]}:{datos["CreatedAt"].split(" ")[0]}:{imageid}.tar".replace("/", "-")
            # If the file already exists just skip it
            if not os.path.isfile(f"{OUTPUT_DIR}/{outputname}"):
                    print(f"Saving {outputname}...")
                    subprocess.run(["docker", "save", imageid, "-o", f"{OUTPUT_DIR}/{outputname}"])
            else:
                    print(f"Already exists {outputname}")
    
  • panda_abyss@lemmy.ca
    link
    fedilink
    English
    arrow-up
    2
    ·
    1 day ago

    I do run my own forgejo container repo, and I mirror containers I need there.

    But I don’t backup my containers, just the data directories I mount to them.

  • realitaetsverlust@piefed.zip
    link
    fedilink
    English
    arrow-up
    1
    arrow-down
    1
    ·
    20 hours ago

    I’m kinda confused by all of the people here doing that tbh.

    The entire point of dockerfiles is to have them produce the same image over and over again. Meaning, I can take the dockerfile, spin it up on any machine on gods green earth and have it run there in the exact same state as anywhere else, minus eventual configs or files that need to be mounted.

    Now, if I’m worried about an image disappearing from a remote registry, I just download the dockerfile and have it stored locally somewhere. But backuping the entire image seems seriously weird to me and kinda goes against of the spirit of docker.

    • crater2150@feddit.org
      link
      fedilink
      English
      arrow-up
      2
      ·
      11 hours ago

      A lot of Dockerfiles start with installing dependencies via the base image’s package manager, without specifying exact versions (which isn’t always possible, as most distros don’t keep all history of all packages in their repos). So all your dependencies may have different versions, when you build again.

      • realitaetsverlust@piefed.zip
        link
        fedilink
        English
        arrow-up
        1
        ·
        8 hours ago

        True, but I got two problems with that thought chain:

        1. I don’t want any outdated dependencies within my network. There might be a critical bug in them and if I back up the images, I keep those bugs with me. That seems pretty silly.
        2. If an application breaks because you updated dependencies, you either have to upgrade the application aswell or got some abandonware on your hands, in which case it’s probably time to find a new one.
  • Decronym@lemmy.decronym.xyzB
    link
    fedilink
    English
    arrow-up
    1
    arrow-down
    5
    ·
    edit-2
    6 hours ago

    Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:

    Fewer Letters More Letters
    DNS Domain Name Service/System
    Git Popular version control system, primarily for code
    HTTP Hypertext Transfer Protocol, the Web
    IP Internet Protocol
    SSH Secure Shell for remote terminal access
    SSL Secure Sockets Layer, for transparent encryption
    VPN Virtual Private Network
    nginx Popular HTTP server

    [Thread #44 for this comm, first seen 30th Jan 2026, 12:50] [FAQ] [Full list] [Contact] [Source code]

    • officermike@lemmy.world
      link
      fedilink
      English
      arrow-up
      6
      ·
      1 day ago

      While I don’t necessarily have an issue with the intent of this bot, literally none of the initialisms listed were in the OP or any of the comments, as far as I can see.