HOW-TO:Backup the video library

This guide will show you how to backup the video library using NFO files and local images. These NFO files are little text files that save all the "metadata" (summaries, credits, playcount, and other library data) for each individual video that are then placed along side the actual video files. These act as a backup for each entry, and can also be used as a way of changing library information or for scanning files that are not recognized by a scraper website. This also saves any changes you've made in Kodi, such as changing the title, sort title, selecting specific images/artwork, movie sets, video library tags, watched history, and resume points.

Backing up the video library is a good idea for several reasons: rebuilding your library in case of damage to your main HTPC, mistakenly removed library entries, duplicate the same library on other Kodi installs, or let you to easily move your video files without losing special changes or your watched history. It also allows for off-line library scanning or if a scraper website goes away.

Moving the library
The steps in this guide include how to use the backup to move video files to a new location.

When you scan video files into the library, Kodi will remember the exact location of the files used. If you'd like to move the video files, say from a local hard drive to a NAS or changing the file sharing protocol you use, then you will need to update paths stored in Kodi's library. Exporting NFO files will preserve your Kodi library when you move the location of your video files and ensure that all of the "metadata" (summaries, credits, etc) is preserved, along with your watched history and resume points.

What is not backed up
This guide only covers the information stored for the video library. It doesn't include the following, which is covered in Backup:
 * Kodi itself and general settings for the GUI, audio/video, hardware, etc.
 * Playlists
 * Add-ons and their settings
 * Passwords are not saved in any NFO file, even if stored on a password protected file server.

Why "multiple files" and not single-file export?
You can use a single-file export for backup or library migration, but there are some added complication involving images:

When images are downloaded from the internet during a library scan, Kodi saves those images locally in a cache (the thumbnails folder in the userdata folder). If the images are missing, like they would be on a new Kodi device added to an existing MySQL setup, or if an image became corrupted/missing, then Kodi looks for a URL to download the image again. When importing from the "single file" (which is a single XML file inside a folder with images), the image URL replaces the online URL with a path that points to the exported folder.

So instead of, we get something like   or whatever file path it was loaded with.

A new Kodi instance would be confused, because it probably doesn't have that folder in the same location, or because the user deleted this folder after importing. You can get around this by doing your import step by using a network source, like an SMB share where the video files are, so the URL works from all the computers. It would make the path something like, and then there would be no issue.

Once the images are cached/saved locally on each Kodi device, the exported image copies are only used if something happens to the local copies (or if a new Kodi instance is added to a MySQL setup).

Alternatively, you could do a single-file export without exporting images, and the image URL shouldn't be touched at all. The big reason for not suggesting that is some people have very old libraries and their image URLs no longer work (the scrapers sometimes change the URLs or delete specific versions of an image, maybe the user changed a DVD cover with an image they made, etc). Because of that we encourage people to use an export/import step that uses the images they already have on their original library, since we can't be certain those images still exist online.

For MySQL:

As for why images aren't directly shared across Kodi instances, this is for a few reasons. The biggest is performance/speed. Images are much larger than text movie summaries, so we can normally get away with a central text database, but images make a much more noticeable impact for some libraries. Another reason is that individual Kodi devices can have their own settings for the resolution of the images. For example, the Raspberry Pi will save images at a lower quality/size in order to compensate for the slower CPU, but on more powerful Kodi devices we don't have that issue and we want to show the higher quality versions of the images when we can.

There are additional technical reasons for not sharing the image cache. The basic gist is that Kodi doesn't anticipate sharing images with other Kodi instances and it can cause various errors.