Hi! I had to recover my Devonthink Pro database from mozy.com after a crash of my HD. The file is shown as a “real” Devonthink file with all the files in the package (more than 300 MB). Unfortunately all I get is an empyt database when I open the file with DT. What shall I do?
Assuming that you have backed the internal backup folders regularly, perhaps the best approach would be to open the damaged database and choose Tools > Restore Backup. Choose the most recent Backup folder. This will reversibly swap the current (damaged) database with the state of the database as of the most recent backup. If necessary, choose the next most recent internal Backup folder.
As you are a user of DT Pro I highly recommend running Scripts > Export > Backup Archive after you have spent a few hours of effort modifying a database. That script will verify and optimize the database, then produce current internal and external backups. The external backup is compressed and dated, and can be copied to an external medium (external hard drive, another computer, a CD or DVD) as added protection if your hard drive were to die.
After a HD or system crash it’s a good idea to run OS X and disk directory maintenance to correct any lingering errors.
I’m not familiar with mozy. And I’ll confess that I’m reluctant to entrust data to any medium that I don’t control. Whenever I use backup software, e.g. to clone a drive, I like to make certain that all databases (not just DT Pro databases) are closed properly.
You many have a good internal backup in the database. To check that, try Tools > Restore Backup. Choose the most recent backup folder and confirm that you wish to restore it. This will (reversibly) swap the corrupt database with the state of the database as of the most recent internal backup.
In the worst case, as you have over 300 MB files in the internal Files folder, you can copy the Files folder and import the contents into a new database. You will, however, have lost all text, HTML and WebArchive files, as well as the organizational structure and any keywords or notes previously added to the Comment field of the Info panel of those documents.
I wouldn’t hesitate to keep a copy of the archive file produced by Backup Archive on a remote storage area, as that’s “just a file” and not an open, working database. It’s a good idea to store such archive backups on another medium, in case of a hard drive failure.
I’m having the same issue. This is the first time DT has let me down. I’m diligent about verifying and using the backup (internal not the script). I did a bunch of work this morning but this afternoon I started up DT and it said I had 612 errors in memory and 82078 file errors. All the choices do not seem to work. The rebuild comes in blank and the restore comes in blank. Is there anything else to try?
The default in Preferences is for three internal backup folders, i.e. three increasingly older states of the database.
Try Restore Backup and choose the next most recent internal Backup folder.
That database problem may indicate that it’s time to do maintenance of the operating system (OnyX or similar utility) and the disk directory (Disk Utility repair disk and/or DiskWarrior 4). Routine preventive maintenance can save a lot of grief.
Although I haven’t had to resort to a backup in more than two years, I run the Backup Archive routine when I’ve spent hours modifying material in my database. When I take a break it takes seconds to invoke Scripts > Export > Backup Archive. When I return after the break the database has been verified, optimized and has current internal and external backups. The external backup archives are compressed and smaller than the working database, so I keep a history of them for a while, deleting the oldest ones periodically. And I copy the external archive file to another drive or storage medium just in case the hard drive were to crater.
Thanks Bill. I actually run Cocktail everyday on my system and try to keep it maintained. What puzzles me is that last night when I quit I know I hit the verify and backup buttons before I quit. If there was an issue wouldn’t I have found it then?
I found the 3 internal backups but as I mentioned trying to restore anyone of those resulted in a blank DB.
Although the verification can not discover every possible problem, the answer is nonetheless “probably” and therefore this could be an external issue (like a damaged filesystem, a power outage or an empty battery, a kernel panic/system freeze, forced quit or computer reset)
Please select the database package in the Finder, choose “Show Package Contents” in the contextual menu and copy (!) one of the Backup folders to the desktop. Copy (!) the Files folder into the copied (!) Backup folder and finally append the extension “.dtBase” to the copied folder’s name.
You should be able to open this backup now by double clicking on it - does this procedure work for any of the Backup folders?
Well with the exception of a possible file system issue, none of the above has taken place. The only variable I can think of that is new to my system is that I’ve been running Lightroom while DT has been open. Yeah I know it probably means nothing but having run DT for a few years now and having this happen out of the blue, I’ll look at any variable!
I need to write this down or future reference. As it turns out I found a backup copy I made of the whole db on another drive. It was missing the changes I made in the morning, but it did open and I was able to catch up.
Here’s another question. As long as I’ve been using DT I’ve been storing and running the actual db from a disc image. That way I can have all my information in one encrypted place and it makes for an easy offline backup since it’s 4.2 gigs. Is there anything inherent about the integrity of a disc image that I should be aware of in regards to DT? As I mentioned I’ve been using this method for about 3 years now with no problems. The above issue is the first I’ve had with DT.
Using a disk image is OK. It does add one more potential for things going wrong in the sense that it’s a file and could become corrupted. I would consider it a safe and reasonable approach, especially if one needs to add encryption to a database for security reasons.
Christian’s tip for recovering data is a valuable one.