How to update urbackup server running in docker?

Server
1

Hi,
running urbackup server in docker on a sinology NAS.
How can I update to the latest version without loosing all settings/backups (e.g. 2.5.27->2.5.30)?

Thanks

2

I assume you are running the official uroni/urbackup-server image?

You should have specified storage for settings and database something like:

volumes:
      - /path/to/your/database/folder:/var/urbackup
      - /path/to/your/backup/folder:/backups

… in your docker-compose.yml file or on your “docker run” command line. That’s where your settings and backups are located. The above illustrates a bind mount, but you could have configured a Docker Volume instead.

So you can rebuild your container based on a newer urbackup-server image, and should be just fine if you set up your volumes exactly as you did previously. i.e., pointing to the same place as before.
Obviously, don’t delete these bind paths or Docker Volumes (whichever you used) as that will wipe out your existing settings and backups.

3

Thank you, much appreciated!
I had set up a volume to my backup-folder, but unfortunately never did so for the settings (/var/urbackup).
I guess I’ll set it up afresh now configuring both the paths to reside on a volume.
One more question: I do understand the difference between volumes and bind-mount, but apparently synology-docker only lets me edit “volumes” when configuring the container. Do you have a hint what in the end is then used, volume or bind-mount, if I am configuring a directory on the host via the synology-docker-volume dialog?
And is it meaningful to also bind/volume the www folder?

Thanks!

4

Since you did NOT set up a volume or bind mount for your settings (/var/urbackup) that means that your settings are INSIDE THE CONTAINER. So do not delete that container! First, you need to get your settings OUT of the existing container and put them somewhere that the new container can access them (a Docker Volume or a bind mount to the host’s file system). Once your get those settings OUT of the old container and have verified that the new container can access them (wherever you put them - volume or bind mount), only THEN can you safely delete the old container.

Or, as you mentioned, you can just start afresh and reconfigure all your settings from scratch for the new container. If this is your path, then you may have to get help from others here, not me, because I do not have experience trying to keep old backups, while configuring new settings from scratch, during a Docker/UrBackup upgrade. This is a lack of UrBackup knowledge on my part. I know how to mount volumes/bind mounts in Docker. How does one make UrBackup recognize and continue using older backups in what amounts to a brand new installation from UrBackup’s viewpoint? This I do not know, because I have never done it. So I’m not the best person to advise you.

I think it should be simple to copy your old settings from your old container into a newly created Docker Volume, and then mount that newly created Docker Volume into the new container you will be creating during the UrBackup upgrade. This way your new UrBackup container would be using both the old settings, and the old backups.

I will admit, the last time I upgraded UrBackup I just started afresh. A new container. A new settings directory (bind mounted, but I probably should have chosen a Docker Volume - oh well!) And a new backups directory (bind mounted). I did keep my old UrBackup container and its old settings and its old backups, in case my upgrade starting afresh didn’t work. These things are currently sitting there, unused. I should go ahead and delete them now, because I’ve been running the upgraded UrBackup setup for four months without any issues. So I have plenty of good backups under the new system to be confident enough to delete the old.

Note that “starting from scratch” really is “starting from scratch”. I ended up having to delete and reinstall the clients as well. This may not be absolutely necessary if you are a UrBackup guru and know what you are doing, but I ran into issues and the quickest and cleanest way for me was the just wipe out the clients and start those afresh also. I currently have six clients so upgrading them all was not too onerous. If you have a ton of clients, you may want a different approach than I took.

As far as Synology, I don’t know what that does with regards to Docker. I guess you must have some kind of built-in configuration or scripting in Synology if you’re asking this question. It kind of implies that Synology set things up, not you personally. I’m running my Docker on a Linux box, and I’m doing all my configuration from the Linux command line. You should be able to see if Synology used bind mounts or volumes by using the “docker inspect” command. You give this command the container name or container idid.

Here is my UrBackup docker-compose.yml file setup:

  urbackup:
    image: uroni/urbackup-server:production
    container_name: urbackup
    restart: unless-stopped
    network_mode: host
    volumes:
      - /backups/urbackup/database:/var/urbackup
      - /backups/urbackup/backups:/backups
      - ./app_data/urbackup/www:/usr/share/urbackup
    environment:
      - PUID=1009
      - PGID=1008
      - TZ=America/Denver

And here is what “docker inspect urbackup” displays relating to mounts:

        "Mounts": [
            {
                "Type": "volume",
                "Name": "25c968941460155292b3e88d504a3c213f7c87936c8464b2c270acf511d7cc97",
                "Source": "/var/lib/docker/volumes/25c968941460155292b3e88d504a3c213f7c87936c8464b2c270acf511d7cc97/_data",
                "Destination": "/var/log",
                "Driver": "local",
                "Mode": "",
                "RW": true,
                "Propagation": ""
            },
            {
                "Type": "bind",
                "Source": "/backups/urbackup/database",
                "Destination": "/var/urbackup",
                "Mode": "rw",
                "RW": true,
                "Propagation": "rprivate"
            },
            {
                "Type": "bind",
                "Source": "/backups/urbackup/backups",
                "Destination": "/backups",
                "Mode": "rw",
                "RW": true,
                "Propagation": "rprivate"
            },
            {
                "Type": "bind",
                "Source": "/var/opt/docker/production/app_data/urbackup/www",
                "Destination": "/usr/share/urbackup",
                "Mode": "rw",
                "RW": true,
                "Propagation": "rprivate"
            }
        ],

You can see my three bind mounts that are configured in my docker-compose.yml file. There is also a Docker Volume listed. I did not create that manually. Evidently the UrBackup image created it. But you can clearly see what is in a Volume and what is bind mounted.

As far as bind/volume on the www folder, I bind mount mine. But I cannot come up with a good reason why I should do that in the generic case. I bind mounted it simply because all of my OTHER Docker apps (not UrBackup) I have configured to put their www stuff in a bind mounted directory so I just went ahead and did the UrBackup installation that same way. If you haven’t already set up www folders outside of containers in your setup, I see no reason to start doing that with UrBackup. It doesn’t hurt, it doesn’t help, IMHO.

Good luck with your upgrade!

5

Thank you very much for details and hints.

For me it was possible to set up the server afresh (also did not really need the existing backups).
Now I have put settings and also www folder onto a volume and should be good to go for a next update then :slight_smile:
The reason why I also put www folder is that there some keyfile (.pub) was located which is probably replicated by a new installation anyway based on the information in /var/urbackup)

Thanks again!