Quote:
Originally Posted by chaley
Note that books that have had an author or title change since the last backup will be 'lost' if you restore the database. Reason: author and title are used to construct the folder path for the book. When you change one of them, the folders are moved to the new names. Restoring a metadata.db with the old author/title metadata will look in the old (and now non-existent) folder. Result: books are gone.
|
True, any changes since the last backup will be gone. That's the nature of the beast, hardly a revelation.
Quote:
Originally Posted by chaley
This was the reason I decided not to do an automatic backup of metadata.db when you do a search/replace. If you were playing with authors or titles, restoring the old copy could make the problem much much worse. I didn't want to imply a promise we couldn't keep.
|
I'm confused. How will restoring just the metadata.db make things much much worse? It will create blank folders with no books but it won't cause any folders to go poof, will it? Running a database integrity check at this point will point out any mismatches and you can manually search for the missing items or re-add those items via the metadata edit window.
The nature of the beast is that you don't restore from backup until there is a problem. Depending on how you back things up restoring the metadata.db file might be the route to minimized loss of metadata. My metadata.db file is backed-up on the fly every time it is changed. I can try the last 150 backups in order and never physically lose a file because of it.
Of course if restoring just the metadata.db file doesn't produce the results you like, restoring the entire library is still an option.
Maybe I'm missing something, the promise of a backup is that you can recover to the last point in time you actually backed up your files.