Hello, I set up a backup for my server that I started putting together recently. It’s an Ubuntu system with the standard “Backup” program, which is apparently Duplicity. But it seems to be unable to read some of the files in the Plex directory under /var/lib/:
Every single (seems like) GoP-0.xml file in /Plex Media Server/Media/localhost/0/04…12.bundle/Contents/
A movie poster I had uploaded: /Plex Media Server/Metadata/Movies/1/ad…1e.bundle/Uploads/posters/ad…b0
The main config file: /Plex Media Server/Preferences.xml
This is very perplexing, especially restricting the preferences file to read/write by the plex user and nobody else. An automated backup that’s running under my user isn’t going to be able to back it up as perhttps://support.plex.tv/articles/201539237-backing-up-plex-media-server-data/!
To top it off, the Preferences.xml permissions actually get reset when PMS saves the file, so I can’t even fix it manually by allowing read for others, like with the movie poster.
What’s up with all of that?
(P.S.: I have seen the arcane process that is recommended for backup and cloning under Linux. I think it’s an issue that the permissions are set the way they are, preventing the built-in, user-friendly and automated solution from working for no discernible reason.)
If Duplicity is running as your username, instead of as root, this is the problem.
Linux does not let your username read the files (to backup) from another username (plex) without explicit permission.
This as the foundation, run Duplicity as root or, what most of us do, run a cron job which does the following:
cd /path/to/backup/files
mv -f PlexBackup.tar.gz PlexBackup.tar.gz.prev
cd /var/lib/plexmediaserver
tar cfz /path/to/backup/files/PlexBackup.tar.gz ./Library
Now you have both the backup you desire and it’s already in the correct form to move to a different location or host should you need to relocate your Library directory.
Run this on whatever schedule you wish. Keep in mind, as written, it will keep only the 1 previous backup.
Linux only honors the permissions of the files - most of them work just fine, only the exceptions that I’ve listed diverge. I’m questioning if / why this needs to be that way.
I realized that I probably want to set up a script for better control anyway, thanks for the input. Although I’m thinking I would rather modify the file permissions that don’t work for me, and have a proper incremental backup that way.
If you start modifying permissions within /var/lib/plexmediaserver you are opening a can of worms.
Work within how linux does OR we can customize PMS to work how you want it to.
From your post, it sounds like you would prefer it run as your username.
This is easily done.
@amorpheus There are actually quite a few aspects to this to be honest.
1 There are ‘ways’ to backup open files, though I personally haven’t bothered to figure this out since crash plan does it for me and I’m just hoping it will work. If it doesn’t I’ll just rebuild.
2 - I’d suggest writing out a design for how this all works for you - You’ll need to know which user you’ve set Plex to run as and which groups you need for which users and most likely match up the UID and GID’s across your different boxes - though I’m not 100% sure how you’re connecting so I could be wrong. I’ve spent some time figuring out something that works for me previously - see my article https://www.tech-knowhow.com/2016/03/how-to-plex-permissions-linux/ on Plex permissions between two servers (which is really just all *nix permissions) - getting older now but should still apply.
3 - There’s actually a good official Plex article on permissions here that should help also.
4 - Overall, you shouldn’t have to change the user, just the group - but it can be a bit of a pain to get right in ones head. Plus any time you change anything you gotta remember how you did it. So, this is why I recommend mapping it out on paper first.
5 - Plenty of help is around, people will have different opinions and out of that you will make yours. Don’t be scared, you can always rebuild!
FYI… That tech-knowhow.com link is specific to one implementation which appears to be the RPi family.
It is not the default configuration for mainstream Linux.
Appreciate the comments regarding backing up a live plex database, but:
(A) Even if you are creating a tar ball of /Library/, isn’t that also going to cause potential issues with the backup unless you actually stop the Plex Server first? If not, plex could be changing files as the tar is being created?
(B) Sounds like there is another issue here (that I’ve seen as well) in that all of the /Library/Application Support/Plex Media Server/Media/localhost/X/XXXXXXXXXXXX.bundle/Contents/GoP-0.xml files are being created by the plex user with the permissions set as 700 when all of the other plex-owned files (with the exception of Preferences.xml?) are being created as 755? Any reason why these Go-P-0.xml files are any different to the other plex files (permissions wise)?
Personally, digging into the metadata file structure itself is probably best left for engineering.
I’ve read through the specs but because I’m not a database guy, I don’t understand why things are like they are.
I know…
A. Back it up with a tar ball (1. fast 2. all file attributes preserved, 3. portable)
B. Backing up on a live system, if you’re going to move to a new system, isn’t a good idea. However, if you’re snapshotting the system, AND have Schedule Tasks set to create a backup DB, the backup database (only 3 days old) is 100% static and safe to copy. Bringing that current is as easy as scanning all files.
I really do advise to just let the contents of the metadata directories be. Different features use them differently. How they interact is another.
I will ask about those files being 700. I do not know of any reason for the file to be exclusive to user plex but there might be. If Engineering is slowly evolving to something new, this could be foundation work for it. It’s anyone’s guess… including mine!
For now, backup as root. It’s the only way to guarantee all directory and file permissions, attributes, and other flags (including sparse files) are backed up properly.
Linux is strict on permissions. That is always an important facet to remember
