Updating Jellyfin docker container on Synology DSM 6

[Sargon]

I have just finished setting up Jellyfin in a docker container on my Synology box (running DSM 6) and spent a few days getting all the metadata updated properly everything configured the way I want.

Now I want to make sure I know how to update the container without breaking anything whenever there is a new software version released.  I know there are automated ways to keep the container updated, but I would prefer to only update on demand at this point.

With that said, I have created a task in Synology that I "think" will update the container, but I am a bit nervous about running it the first time and potentially losing all the work I have already done.  
(NOTE: I have taken a complete backup of my docker container, so in theory I should be able to restore that if anything goes wrong, but I don't have any experience restoring containers)

Is there anyone who can tell me whether the script below appears to be defined correctly to update the container?  I realize you don't have all the specific details on my configuration, but do the steps look logically correct?  Have I missed anything?

Code:

docker stop jellyfin
docker rm jellyfin
docker pull jellyfin/jellyfin:latest
docker run -d --name=jellyfin \
-v /volume1/docker/jellyfin/config:/config \
-v /volume1/docker/jellyfin/cache:/cache \
-v /volume2/Video/Movies:/video-movies:ro \
-v /volume2/Video/Series:/video-series:ro \
-v /volume2/Video/Wrestling:/video-wrestling:ro \
-v /volume2/Video/Other:/video-other:ro \
-v /volume2/Music:/music:ro \
--user 1026:100 \
--net=host \
--restart always \
jellyfin/jellyfin

[TheDreadPirate]

"docker rm jellyfin" is the part that removes the image used to create the jellyfin container. This forces docker to actually check for the latest jellyfin image and pull it down.

Alternatively, if you're able to use docker compose the "--force-recreate" flag will do the same thing.

[Efficient_Good_5784]

From what I see, everything appears good.

The only bit of advice I would give is to add a bit more to make a copy of the config folder and store it in a separate location on the NAS so that if the new Jellyfin update breaks something, you have a backup from just before the update. Just make sure the container is shut down before starting the copy task so the database doesn't have a chance of being copied during and operation and getting your backup in a corrupted state.

[TheDreadPirate]

From what I see, everything appears good.

The only bit of advice I would give is to add a bit more to make a copy of the config folder and store it in a separate location on the NAS so that if the new Jellyfin update breaks something, you have a backup from just before the update. Just make sure the container is shut down before starting the copy task so the database doesn't have a chance of being copied during and operation and getting your backup in a corrupted state.

To refine on this point, you should use rsync instead of plain copy.  Copy will do a sufficient job of making a backup, but will never cleanup files that are no longer present at the source.  If you rename, delete, or re-identify media the associated metadata (like images) will change.  Copy will not touch the now obsolete metadata. This can cause the backup to bloat over time as old images, subtitles, etc., are not cleaned up.

Rsync CAN cleanup the destination when files are deleted at the source.

Code:

rsync -a -p --progress /volume1/docker/jellyfin/config /path/to/backup/directory/ --delete

The --delete option is what cleans up the destination folder when files are no longer present at the source.

[Sargon]

"docker rm jellyfin" is the part that removes the image used to create the jellyfin container.  This forces docker to actually check for the latest jellyfin image and pull it down.

I believe, based on what you are saying here, that the explicit "docker pull" line would be unnecessary because the run statement is going to pull the latest image down anyway.  Is that true?

[TheDreadPirate]

The explicit pull is not necessary. When you execute "docker run" it would pull it at that point.