My Plex server ate itself on a Sunday night. A botched update left the database in a state where the server would start, run for ninety seconds, then crash and restart in an endless loop.
What scared me was not the software. It was the thought of losing eight years of watch history for a household of five people, plus roughly 400 hand-corrected movie posters I had painstakingly matched by hand.
The media files themselves were fine. What was at risk was everything Plex builds around those files, and that is the part almost nobody backs up until it is gone.
What actually needs backing up (and what does not)
Your movies and TV episodes are just files sitting in a share. If you have those, you can always re-add them. The valuable, irreplaceable stuff lives in one folder Plex calls the Plex Media Server data directory.
Inside that directory sit three things worth protecting: the SQLite databases that hold your watch history and ratings, the Metadata folder full of posters and artwork, and your Preferences file with the server identity and settings.
Here is what each piece actually holds, so you know why it matters:
- com.plexapp.plugins.library.db: watch history, play counts, ratings, view state, and how your libraries are organized. This is the crown jewel.
- The Metadata folder: every poster, background, and thumbnail, including the ones you swapped by hand. Lose this and Plex refetches generic artwork.
- The Preferences.xml file: your server identity token, remote access settings, and transcoder options. Restoring this keeps your existing server rather than creating a stranger.
So the goal is narrow. Protect the data directory, skip the disposable parts, and you can rebuild a dead server in under an hour with every poster and play count intact.
Step 1: Find your Plex data directory
The location depends on where Plex runs. The first time I did this I wasted twenty minutes searching the wrong drive, so here is the map.
| Platform | Data directory location |
|---|---|
| Synology NAS | /volume1/Plex/Library/Application Support/Plex Media Server/ |
| QNAP NAS | /share/CACHEDEV1_DATA/.qpkg/PlexMediaServer/Library/ |
| Windows | %LOCALAPPDATA%Plex Media Server |
| Docker | whatever you mapped to /config in your compose file |
| Linux (native) | /var/lib/plexmediaserver/Library/Application Support/Plex Media Server/ |
If you run Plex in Docker, this is easy. The folder you bind-mounted to /config is the whole prize, and you already know where it lives on your host.
Confirm you found the right folder
Open the directory and look for a file named com.plexapp.plugins.library.db. That single file is your library database. If it is there, you are in the correct place.
Step 2: Stop the server before you copy anything
This is the step people skip, and it is the one that quietly corrupts backups. The library database is a live SQLite file. Copy it while Plex is writing to it and you can end up with a backup that looks fine but fails to load later.
Give it a full ten seconds after stopping so any final writes flush to disk. Then you are safe to copy.
Plex does make a nightly internal backup of the database inside a Plug-in Support/Databases subfolder, named with a date. Those are handy in a pinch, but they only cover the database, not your posters, so do not treat them as a complete backup.
Step 3: Copy the data directory somewhere else
Now copy the whole Plex Media Server folder to another location. Another drive, another NAS, or a cloud target all work. The key word is elsewhere, because a backup sitting on the same failing disk is not a backup.
On a NAS, the cleanest approach is a scheduled rsync or the built-in backup app. On Synology, Hyper Backup can target the Plex folder directly and version it, so you keep last night's copy and last week's copy both.
For an offsite copy, I push mine to cloud storage weekly. If you want to understand why offsite matters even for a home setup, this explanation of the 3-2-1 backup rule is the clearest one I have found.
Step 4: Automate it so you never think about it again
A backup you run by hand is a backup you forget. The whole point is to set a schedule and walk away.
- Create a script that stops Plex, copies the data directory (minus Cache and Codecs), then starts Plex again.
- Schedule it to run nightly at a time nobody is watching, like 4 a.m.
- Keep at least three dated versions, so if a bad database sneaks into one backup you can roll back to a clean one.
- Once a month, actually open a backup and confirm the .db file is there and a reasonable size.
That last point matters more than the rest combined. An untested backup is just a hope. I test mine on the first of every month, and it takes two minutes.
The mistakes that quietly ruin backups
A mistake I see constantly is people backing up the Plex folder but never once trying to restore it. The copy runs for a year, everyone feels safe, and then the restore fails because the database was always being copied hot.
The second common trap is keeping only one copy. If your automation overwrites the same backup every night, a corrupt database from Tuesday overwrites the good one from Monday, and now every copy is broken.
Then there is the sneaky one: forgetting the Preferences file. Restore the database and metadata but skip Preferences, and Plex spins up as a brand new server. Your clients see it as a stranger, remote access breaks, and you spend an evening re-authorizing devices.
Keep three dated versions, include Preferences, and test restores, and none of these can bite you.
Step 5: Restore and prove it works
Restoring is the reverse. Stop Plex, delete or rename the broken data directory, drop your backed-up copy in its place, fix the folder ownership if you are on Linux or a NAS, then start Plex.
The moment it comes back, check three things: your watch history is intact, your custom posters are showing, and your collections still exist. If all three are there, the restore worked.
When my own server died that Sunday, I stopped Plex, swapped in Friday's backup, corrected the ownership, and started it. Six minutes later every play count and poster was exactly where it belonged.
Keep it boring and keep it running
The best Plex backup is the one you set up once and forget, because it just runs at 4 a.m. and quietly saves a versioned copy to a second drive.
Spend the thirty minutes now to point a schedule at your data directory and exclude the junk folders. Your future self, staring at a crashed server on a Sunday night, will be very glad the hard part is already done.
Frequently asked questions
Do I need to back up my actual movie and TV files too?
Your media files should be backed up separately as part of your normal file backup, but they are not part of the Plex library backup. If you lose them you can re-add them and Plex will rematch. The library backup protects the watch history, posters, and collections that you cannot rebuild by re-adding files.
Can I just copy the folder while Plex is running?
You can, but it is risky. The library database is a live SQLite file, and copying it mid-write can produce a backup that loads with errors or not at all. Stop the Plex Media Server service first, wait about ten seconds, then copy.
How big is a typical Plex library backup?
It depends on how many items you have, but the databases and metadata together are usually a few gigabytes for a mid-sized library. If your backup is 30 GB or more, you are almost certainly including the Cache and Codecs folders, which you should exclude.
My restored library is empty even though Plex started. What went wrong?
This is almost always a permissions problem on a NAS or Docker setup. The restored data directory has the wrong owner, so Plex cannot read it. Fix the folder ownership (on Synology the user is usually plex) and restart the server.
Does Plex have a built-in backup I can rely on?
Plex writes a nightly copy of the database into a Databases subfolder, which is useful if only the database gets corrupted. However, it does not include your Metadata folder or Preferences, so it is not a complete backup. Treat it as a bonus, not your main strategy.
