@mwsmith824 said:
That’s the part that confuses me the most. Even in the worst case scenario where you had to migrate to a completely different database or structure it shouldn’t take that long to develop something as simple as a database backup/export and make an import function. It could be as simple as dumping to a bunch of csv and jpg files in a big zip archive, or as complex as they decide to make it. But it shouldn’t take three freaking years to put together. I think they’re too distracted getting apps in everything to care much about the back end at this point.
To be honest, I found out the hard way why migrating is such a PITA. It sounds simple, but I tried to move my library across machines (different flavour of Linux), with different mounting points etc. I quickly found out that a lot of data actually is extremely difficult to move and completely useless in the end. It is a mix of a database, a filesystem containing the plugins, cache data with some obscure sort of organisatation, and the media library itself. I invested quite some time in it (to understand how to back up in the future), and just ends as a horrible mess. Since my filepaths were altered slightly, the databases started pruning the old files, etc. And this is just Linux-to-Linux, Windows-to-Linux is much harder since you got huge conversion issues (even a simple txt file must undergo some treatment along th way…) and file-paths are structured differently.
And I would say that by having a migration tool, it keeps development aware of what needs to be kept, and how to organize it. If you were having problems, is that indicative of lack of your knowledge of the structures, or lack of consistency of the product, or something else?
Converting txt files between Linux/*ux and Windows is trivial. Testing or converting CR to CR/LF and back is two lines of code. Converting pathing constructs is not difficult. Given the data, there can be an intermediary export format, with a re-import filter based on the destination OS.
How about a straight export function of everything out to a zip/rar as a disaster recovery, and then the more technical of us can at least hack away at a cross load util? And no, I would not consider SSH’ing into a device for us to do it ourselves an acceptable backup strategy.
Honestly it’s a crime that this isn’t available on Plex right now. Without a feature like this system migration/recovery is not only a nightmare but is near impossible to do. I understand that most of the non-user generated metadata takes up a lot of space but there are some fairly simple things that should be exportable right now at a minimum that are not:
watched status
user ratings
music playlists
And now with the new grand announcement of the Plex Cloud - if it is sustainable, which I assume it will not be, how are people going to get their metadata into this service? People who have 100 TV shows, 800 movies, 10 music playlists, etc. are not going to want to recreate watched statuses, ratings, and playlists.
I would love an easy backup/restore feature. But to add to it, I would love a ‘light’ backup option. Just the settings, configurations, etc. All the media, thumbnails, etc, would be rebuilt. This may be a small use case, but if I rebuild, as I just did, I only restore the libraries, friend access to specific libraries, and a small sampling of configurations. I let the media all rebuild as needed. I did have to fix a movie or 2, but that was worth it for the easy of just starting over.
A definite +1 on this as well. I currently have two Windows plex servers (one movies, one tv shows) with large libraries on both. I am planning on building a single Windows server (20 HD array) so I can combine what is on both plex servers into one since these two servers are getting pretty old and I don’t want to have two servers anymore. Also, I have spent a lot of time selecting different cover art and modifying metadata on both servers. An easy way (make selections within plex) to do this would be fantastic. I know there are steps to move from one server to another (several steps I have seen) but what about merging one database to another? If this process (even if it is two separate selectable processes - one copy, one merge) could be automated as much as possible with selected steps would make it so much easier to perform these tasks that I know every plex user will have to do at one time or another.
I could live without the viewing progress (seen, unseen) backup, but at the very least, backup should allow restoring metadata without having to copy gigabytes of files, manually exporting registry settings, overwriting the auto-generated database, and still having to manually recreate the lost metadata and posters. The backup/restore process should go like this (on a Windows system):
BACKUP:
Select backup location.
Specify backup options (what to back up).
Define backup schedule.
RESTORE:
Install PLEX software.
Install plugins.
Map drive(s) to the share(s) hosting media files (using the same drive letters as on the old system).
Select the restore option, point to the backup folder.
That’s it. All application settings, metadata, posters, etc, should be restored automatically. To save space, PLEX can only back up metadata/posters that the user entered manually (not auto-generated from online sources or media files).
Just consider Lightroom. It’s a similar type of app (catalog, metadata, media files) and Lightroom’s backup/restore works a lot simpler.
I wish by default plex server would just store a backup of the server data with the video data. I keep that all on a NAS anyways, why not store it there too?
