best way to backup (lsio) docker jellyfin data?

[Iacov]

hey

i make weekly backups of my vm running ubuntu/docker/jellyfin but i would like to make a backup of the jellyfin database itself
what is the best practice to do so? does it make a difference wether it is the official docker image or the LSIO image?

and do you know will there be an official backup-option someday?

thank you!

[TheDreadPirate]

I am not aware of any plans to have a built in backup function. Nor is it needed, IMHO. It would be out-of-scope for Jellyfin to have one anyway, especially when nothing special is needed to do so.

Just backup the /config folder (specifically the corresponding host folder that /config is mounted to). That includes the database and config files and metadata.

I just have a cronjob that rsyncs the Jellyfin data folders overnight to a separate drive and also Duplicati running to backup my Jellyfin data directory to Google Drive.

[Iacov]

i have never had in depth experience with rsync
do you have to stop the container to mitigate file corruption or can rsync work around that?
is rsync push or pull? do i tell my fileserver to pull files from the jellyfin server or do i tell my jellyfin server to push to my nas?

what rsync commands are you using to be satisfied with the backup?
(sorry if the questions seem kinda noobish...because that's what i am xD)

[TheDreadPirate]

I had some hardware failure last summer and was able to restore from the backup made with this script.  No corruption.

Code:

#!/bin/bash

BACKUP_LIST=/root/backup_list.txt

while read list ; do
source=$(echo $list | awk -F ':' '{print $1}')
dest=$(echo $list | awk -F ':' '{print $2}')
rsync -a -r -p --progress --exclude /var/lib/docker "$source" "$dest" --delete >> /root/backup.log
done < $BACKUP_LIST

It reads in a text file that has a source directory to backup and a destination of where to place the backup.  If you delete or change a file in the source directory it will delete it from the backup directory (the --delete option).

Excluding /var/lib/docker is important because it only contains temporary data and takes up a lot of space if you don't exclude it.

An example of the text file specifying what to backup.  The colon separates the source (left) with the destination (right)

Code:

/home:/media/extended/Backups/
/etc:/media/extended/Backups/
/var:/media/extended/Backups/
/media/storage:/media/extended/Backups/media/
/media/storage/Pictures:/media/extended/Backups/
/docker:/media/extended/Backups/

In /etc/cron.d I created a text file that contains the cronjob schedule.  You can also put this in root's crontab.

Code:

0 3 * * * root /root/backup.sh
0 1 * * mon root cat /dev/null > /root/backup.log

This runs the backup script nightly at 3am.  Every Monday at 1am it nulls the backup log file.

[Iacov]

thank you very much for sharing

[Iacov]

please excuse the late followup question - but are you using a smb or an nfs share for the rsync?
i first used smb for smaller docker stuff but realized that smb does not support symlinks easily when i tried to backup nginx proxy manager. since then i have switched everything to nfs, but am not sure if it is a good choice to back up jellyfin AND what parameters to use for the nfs mounting
is file-locking a huge issue? should i go for a hard or a soft moutn? or ignore that and go for a x-systemdautomount? if so, should i set a idletime?

[TheDreadPirate]

No. All the storage for my Jellyfin server is locally attached. So no symlink issues for rsync. I've only used SMB, not familiar with the peculiarities of NFS.

[bitmap]

please excuse the late followup question - but are you using a smb or an nfs share for the rsync?
i first used smb for smaller docker stuff but realized that smb does not support symlinks easily when i tried to backup nginx proxy manager. since then i have switched everything to nfs, but am not sure if it is a good choice to back up jellyfin AND what parameters to use for the nfs mounting
is file-locking a huge issue? should i go for a hard or a soft moutn? or ignore that and go for a x-systemdautomount? if so, should i set a idletime?

I'm jumping in a little late here, but I've used rsync to backup my LSIO instance several times, including at least one server rebuild. For NFS, you need to preserve anything you want to stay the same (e.g., ownership, permissions if you're particular) but you can also change all of that back if you need. I didn't archive anything, as compression wouldn't save much aside from logs, which are cleaned regularly. I have had ZERO issues with file locking.

I chose to squash file access to a single user, which you can do using anonuid and anongid and the ID number of the user (anonuid) and group (anongid). This has allowed me to avoid permissions issues, but it will not preserve ownership or anything of the sort. It's a bit of a moot point for me, since settings are what I'm interested in rather than data. I use nfs-common and nfs-kernel-server packages on both servers (both are sharing NFS drives), /etc/exports and /etc/fstab for mounting by UUID (rather than device).

Be very careful if you have real-time monitoring enabled as it can create a race condition if JF starts up and can't find any of your media. It will start deleting the entries in the DB until 1) your mount comes up and 2) you restart the container (since Docker won't see the new mount). Without real-time monitoring, I can restart either of my servers (I have a very stupid NFS setup right now) and the client doesn't panic about it. Only thing that may happen is if somebody tries to play media on the server that's currently down they will receive an error and that entry may be marked as missing/removed from the DB. Short restarts have avoided this in the past.