As always, please ensure you stop your Jellyfin server and take a full backup before upgrading!
Now, if only there was a simple, built-in way to backup/export and restore/import all settings and other data, so that all platforms could do this easily, without having to search the internet for which folders to back up…
FYI, this is the best we have atm (which is pretty terrible). Please correct me if there is a better way:
I run JF in a docker container, and although I don’t have backups of my config files yet (because I don’t really care about setting up from scratch if need be), it would be trivial to simply backup the mounted config volumes. Makes upgrading safe and easy, too.
That’s probably how I would recommend going about this, personally.
Theoretically, support for that could be coming… Emby (where Jellyfin is based on) always used their own layer for interacting with a SQLite database. All that custom made logic is currently being swapped out for EF Core. EF Core is a DotNet library for interacting with databases and EFCore that also supports MySQL, PostgreSQL, SQL Server besides SQLite.
So my guess is that, once all that work is completed, support of other database can be added.
For a little bit of context. I am currently running Jellyfin on Btrfs and there is quite a performance impact due to CoW. If 2 clients decide to browse the libraries, both clients grind to a near standstill with regards to being able to see things. So I am following this work with quite some interest.
I am currently running Jellyfin on Btrfs and there is quite a performance impact due to CoW. If 2 clients decide to browse the libraries, both clients grind to a near standstill with regards to being able to see things.
CoW is not recommended for databases, all DB servers advise for turning it off for the actual database. You’ll run into the same issue with a dedicated database if you leave CoW on I guess. You could also disable CoW for jellyfin’s database right now and performance should increase.
I also follow the progress of a dedicated DB, but on the other hand I don’t know how much sense it makes architecturally. The likeliness that you have multiple jellyfin server instances access the same database is low - after all, there is info very specific to the server in there like the file path. Just migration is already not easy, how likely is sharing the database live? And if each database is specific to an instance - why not use SQLite (like it’s done right now) and allow for more specific parameter tuning, like used memory and the like?
I’m surprised at the lack of enhancement request/PR addressing this.I really want to dust off my C# and try but I’m kinda scared that the reason it isn’t yet a thing is because it’s a mess to implement.
Based on some comments in recent PRs for requested features that seem to have gone nowhere, the devs are trying not to overly complicate the project at the moment with other people’s code that they’d have to support, and instead leaving certain requests to be handled in some grand refactoring they’re working on.
I believe they’re suggesting just doing a full backup up of your system/Docker container. Which isn’t ideal, but I think they’re trusting people who can run a Jellyfin server to be able to use the scripts.
Sure. But what if Docker is not available on a machine? What if the import should happen on a Linux machine coming from Windows? What if I want to sync two installations on different OSs?
I know it’s all doable, but not easy, let alone foolproof. It’s so easy to install, but genuinely not easy to keep safe without tech knowledge.
Syncing two instances sounds like a fun challenge. I think there’s some project to replicate an sqlite db over the network. Similarly, you could use ceph or other distributed storage for the media.
I built something like this for Nextcloud a few years back, fun times.
If you run it on a container, it should be enough to just make a copy of the set up volumes, right? (with permissions and all the metadata kept of course)
Now, if only there was a simple, built-in way to backup/export and restore/import all settings and other data, so that all platforms could do this easily, without having to search the internet for which folders to back up…
FYI, this is the best we have atm (which is pretty terrible). Please correct me if there is a better way:
How to backup a JF instance?
Jellyfin Docs: Migrating
I run JF in a docker container, and although I don’t have backups of my config files yet (because I don’t really care about setting up from scratch if need be), it would be trivial to simply backup the mounted config volumes. Makes upgrading safe and easy, too.
That’s probably how I would recommend going about this, personally.
Oh, if only there was real database support like Mariadb or Postgres…
Theoretically, support for that could be coming… Emby (where Jellyfin is based on) always used their own layer for interacting with a SQLite database. All that custom made logic is currently being swapped out for EF Core. EF Core is a DotNet library for interacting with databases and EFCore that also supports MySQL, PostgreSQL, SQL Server besides SQLite.
So my guess is that, once all that work is completed, support of other database can be added.
For a little bit of context. I am currently running Jellyfin on Btrfs and there is quite a performance impact due to CoW. If 2 clients decide to browse the libraries, both clients grind to a near standstill with regards to being able to see things. So I am following this work with quite some interest.
CoW is not recommended for databases, all DB servers advise for turning it off for the actual database. You’ll run into the same issue with a dedicated database if you leave CoW on I guess. You could also disable CoW for jellyfin’s database right now and performance should increase.
I also follow the progress of a dedicated DB, but on the other hand I don’t know how much sense it makes architecturally. The likeliness that you have multiple jellyfin server instances access the same database is low - after all, there is info very specific to the server in there like the file path. Just migration is already not easy, how likely is sharing the database live? And if each database is specific to an instance - why not use SQLite (like it’s done right now) and allow for more specific parameter tuning, like used memory and the like?
That’s my absolute #1 wish for jf. I’m sure it’s hard work and people are on it, it excites me to think about
I’m surprised at the lack of enhancement request/PR addressing this.I really want to dust off my C# and try but I’m kinda scared that the reason it isn’t yet a thing is because it’s a mess to implement.
This has been discussed before and you might be right.
Jellyfin Forum
Github
Python Backup Script (Good luck if you’re not a developer)
… and so forth. No good answers so far.
Based on some comments in recent PRs for requested features that seem to have gone nowhere, the devs are trying not to overly complicate the project at the moment with other people’s code that they’d have to support, and instead leaving certain requests to be handled in some grand refactoring they’re working on.
I believe they’re suggesting just doing a full backup up of your system/Docker container. Which isn’t ideal, but I think they’re trusting people who can run a Jellyfin server to be able to use the scripts.
Sure. But what if Docker is not available on a machine? What if the import should happen on a Linux machine coming from Windows? What if I want to sync two installations on different OSs?
I know it’s all doable, but not easy, let alone foolproof. It’s so easy to install, but genuinely not easy to keep safe without tech knowledge.
Syncing two instances sounds like a fun challenge. I think there’s some project to replicate an sqlite db over the network. Similarly, you could use ceph or other distributed storage for the media.
I built something like this for Nextcloud a few years back, fun times.
If you run it on a container, it should be enough to just make a copy of the set up volumes, right? (with permissions and all the metadata kept of course)
I have my media on a disk separate from the rest of the VM. I set that disk to not be included in snapshots, then snapshot the VM before upgrades.
I run mine in an LXC container. I just snapshotted it in case of disaster and then ran apt update && apt upgrade.