There's a free MySQL / MariaDB app out there that I use to do exactly what your attempting. It's called HeidiSQL:
https://www.heidisql.com/
It's reasonably easy to use, and is much more user-intuitive than SQL Workbench (if memory serves). My Dbs are running on a QNAP NAS, so I'm in much the same sort of scenario as you.
Connect to the IP and port that the NAS SQL server is running on using your ADMIN credentials (You may need to allow remote access to the SQL server, in the NAS GUI in order for this to work). You will want to save the credentials in HeidiSQL for future use.
1. Backing Up The Database(s):
With the required database selected (in the left pane), right click on the database you want to
export with the right mouse button or context menu key on the keyboard, and select the option "Export Database as SQL"...
You should then see a new dialog window pop-up with a number of export options...
Once your happy with your selections (and target file name/path) just click on the "Export" button to the bottom-right of the Window, and the database and it's contents will be exported to disk. You can export multiple (selected) databases to a single SQL file, or you can do as I do, and simply repeat the process for each of the two databases Kodi uses.
Note: You may wish to play about with the "Max INSERT Size" setting to avoid fragmented queries when restoring the database, but I think this will largely be dictated by the SQL server settings for Max Inserts, and the amount of (free) RAM your NAS is able to use. Don't quote me on that though, as this is supposition on my part.
EDIT: I'm changing my advice / stance on this setting, due to an issue with truncated tables / data I myself experienced recently (i.e: last weekend) trying to restore a database backup. If your doing this procedure for the first time, and are backing up a fully-working set of databases, from a Kodi install with no (major) issues, and want a 'foundation' on which to build / test, knowing you have a rock-solid backup to go back to and not have to re-scrape your entire library again (as I had to do), then keep the 'Max INSERT Size' setting in HeidiSQL at '0' (Single INSERTS) for your first backup of both databases, and select the output file from the pull-down menu below it, to 'ZIP compressed .sql file' instead.
Be aware this will take
MUCH longer to export / import, but will avoid HeidiSQL having to guess where to split queries that are too large to send all in one go. Because in my experience it tends to get the split-points all wrong with regards Kodi's databases, and the imported data is either malformed, truncated or at worst unusable. Especially for TV shows where the number of seasons are large (8-10+). Also, the LAN is the weakest link, and sending large payloads of data to a low-power device like a NAS is at best, risky. As always, YMMV.
2. Restoring the Database(s):
To restore an exported database, you have two options from the "File" menu. "Load SQL File (CTRL-O)" and "Run SQL File". It's highly likely that your NAS will baulk on the SQL file if run directly, so you'll probably want to use the "Load SQL File" option, then run the resulting SQL queries that were loaded by going to the "Query" tab and pressing the blue "Play" icon in the toolbar, and thereby apply the changes to the database server...
You should see the progress of the import on the fly, same as occurs with the initial export process. Once the loaded SQL has been run, check for any errors in the log/status window at the bottom, and you should be good to go.
3. Database Optimization (Experimental!):
By default, Kodi uses the MyISAM database engine for it's databases. Which on a fully-fledged system, is probably OK. But since most consumer NAS devices use low-power sillicon (Atoms, Celerons, etc.), once the databases start to grow in size, scraping and library updates can become painfully slow, depending on the size of your media libraries. One tweak that can be performed, which I can confirm has a
noticable speed improvement, is converting the database table engine from MyISAM to InnoDB.
For Pros and Cons, just Google MyISAM vs. InnoDB. There may be a specific reason why Kodi defaults to MyISAM, but I have tried this tweak and not noticed any issues during day-to-day running, with one caveat. A converted database will not be processed correctly by Kodi during a version upgrade. I tried it and it failed, at least on my QNAP(s). So you will probably need to revert the change prior to migrating between Kodi versions, which may come with added issues. But that's why you backed up your databases to begin with, right?
Edit: The above caveat only applies, generally, to major-release version updates where the database version has been updated and thus both databases need to be "migrated". Point releases, where there are no database structure / version changes will not require reversion back to MyISAM tables in order to apply the point release (e.g: 19.0 to 19.1 if/when it is released).
Edit2: I've determined that Kodi doesn't 'choose' a database engine type when creating the databases fresh. It simply uses the 'Server Default' setting (as defined in the my.cnf / my.ini or mariadb equivalent). Therfore you may want to change the default to 'InnoDB', but be aware this may break operation of any newly installed addons that may rely on the database engine type being 'MyISAM'. It should circumvent the need to switch back database engines prior to installing major new versions of Kodi however. I'm now convinced the failure I had, was due to it trying to write from a set of converted InnoDB databases to a set of newly-created MyISAM databases and fell on it's face for some reason. As usual, proceed with caution.
To perform the switch, with the target database selected, open the "Tools" menu from the main window, and select the option "Maintenance". In the dialog window that opens, select the "Bulk Table Editor" tab, and select the checkbox for the "Change Table Engine" parameter. Open the drop-down list to the right and select "InnoDB" as the table engine. It is possible to expand the database tree and select each
table in the database prior (as this procedure won't work on "views" or "triggers", only "tables"), but as HeidiSQL simply ignores "views" and "triggers" anyway, it's not an essential step as far as I can tell...
[b]
[/b]
Press the "Update" button to the bottom-right of the window and HeidiSQL will then go through all the tables in the selected database(s) and convert them from MyISAM to InnoDB. Do not perform this switch on any of the default databases the NAS ships with, as there are some databases on the SQL server that must remain as MyISAM for the server to function correctly.
As alluded to above, I'm not aware of any pitfalls from making this alteration, and if the devs know of a reason why this
shouldn't be done, i'll happily edit the post and remove this section. But doing the change literally
HALVED my library update / scraping time on my TS453-PRO with both a raw (i.e: empty) database and updates to a heavily-laden (i.e: fully loaded) database. I'm no SQL whiz/expert, so use this tip with due caution.
Dan / Gib.
