While searching yesterday for an item I saved in DevonThink Pro Office v2.7.4, I was unable to find it (credit card charge) so I went to find a copy of the statement in another folder, and those statements were gone also. My database is in a secure sparse image file. I restored my database using Time Machine and was able to find the item and items in folders in the version backed up on 2/16/14. In the current version of my database, the folders or items are no longer there. The items disappeared sometime between 2/16 and 2/20; any database backups since 2/20 do not contain the items. I keep a log of changes made on my system and do not see anything during this time.
I ran a Verify and Repair on the database and it found one inconsistency and resolved it.
At this point I am not sure what is missing. If I go back to 2/16, who knows what I’d have to manually re-create. I don’t know if it’s an option to go back to 2/16 then import from the most current database without importing duplicates.
I opened a case with support but I saw the notice about vacation and thought I would try here to see if someone has suggestions as to what else I can do to troubleshoot and resolve the issue.
-a will automatically copy file dates, permissions, etc, and will recurse into subdirectories
-v will print out the names of files
–ignore-existing will tell rsync not to overwrite any files that are in the destination
-n will tell rsync to do a dry-run: it will list all the files it would copy, but it will not do actually copy anything! This makes it safe!
This will give you a list of the files that exist in the backup that aren’t in your current database.
Once you have that, you can take the files you were missing and go into the dtBase2 package (right click in the finder and choose “Show package contents”) and copy them out of the backup somewhere safe. Then you can import them into DEVONthink and put them in the new database.
I strongly suggest making a backup and then making a clone of the current instance of the database, and only running the above procedure against the clone and not against the current instance. The OP has already suffered a loss, no need to risk suffering a disaster by rendering the current database unusable.
Wow, that’s very powerful. I’m a relatively new Mac user so I’m not too familiar with rsync. I assume I need to be in the same folder when I run Terminal as where the data files are located.
One thing that is puzzling to me is I think of rsync syncing individual files. I think of a dtBase2 file as a database like a SQL database, so I would have thought rsync would only be copying a single file. Apparently there is more to a dtBase2 file than I thought.
I will give this a shot, thank you.
Thanks for the reminder. I am making copies of both dtBase2 files to my desktop to try this on first. I also run a Time Machine backup before I do anything like this. Best case will be only a few files/folders are missing. Worst case I run the command for real and replace my live database with the modified one.
That will not work. If you add documents manually to the files.noindex folder inside the database package the best case if DEVONthink senses large numbers of “orphaned files” that are not connected with the proper group. Worst case is the database is rendered unusable.
I ran the command and found around 50 items missing. I suppose I could open the olddb database in DT along with the current data, then move the missing files to the new one?
Oh boy, did it ever! After moving the documents (more like 200 of them) I ran the command again. It found almost the same list of documents, but I searched for them in the current database and it found them all; some I had to search for the first part of their filename because even though the names looked the same, they must have been different.
I restored a file from 8/4/13 and compared it, and it appears there wasn’t any further loss.
Thank you so much for the rsync command, I at least feel like I know what was missing and was able to replace it.
Of course, my next question is, how do I avoid this in the future? Is checking the database properties for the Total, PDF/PS values, running a verify/repair, then checking properties again a good approach, or is there a better way to ensure data integrity?