I have never been able, no matter which version I have used along the way, to set a backup preference in DEVONthink Pro. The Destination is always grayed out. I fail to see the reason for having in inactive preference. 
I suggest using DT Pro’s Scripts > Export > Backup Archive.
My philosophy is not to depend on scheduled backups. When I’ve made significant changes to a database, at break time I’ll invoke Backup Archive. When I return from break the database will have been verified, optimized and backed up internally and externally.
The archive file produced by Backup Archive is the smallest possible compressed and dated backup of your database. It’s a good idea to keep copies on external media, in case of a hard drive failure or a stolen laptop.
Although I haven’t had to resort to a backup in more than two years, backing up is one of my standard procedures. It’s easy to do, and is insurance against potentially catastrophic data loss.
That’s good advice, but still doesn’t explain the broken feature.
thanks
Lou
Thank you for your quick response. I agree, this is good advice re backing up my database. But I also agree with Lou–why is the preference available if it is not useable? Nothing wrong with having an auto-backup option, along with the manual.
See documentation about the external backup preference. It’s been reserved (for a long time) for future implementation. So it’s not an “undocumented feature” (bug). 
Thank you, Bill. I have not read the documentation in detail and I refer to it only if I run into a problem. I never guessed there would be something there about an intentionally disabled feature. I will not lose anymore sleep over this preference!
OK–I tried the Export script and I got back an error message–“Backup Failed”
Tried it twice with same result. Now what?
You did try to run Scripts > Export > Backup Archive. Right? And the failure report resulted from an attempt to save the archive to your boot disk?
Sounds like you’ve got a database problem. (Unless you had run out of disk space in which to store the backup archive, which itself would be a serious problem that would ultimately lead to database corruption.)
First, run Tools > Verify & Repair. If you get a message that the database can’t be repaired, do not at this time run Rebuild Database.
Instead, run Tools > Restore Backup. This routine will let you revert the database to an earlier state contained in an internal Backup folder inside the database package. (Note that although in DT Pro Preferences > Backup, although you can’t specify and external location for saving a backup, there are options for the frequency of saving internal backups. Let’s assume that there has been at least one automatic internal backup. Note also that at any time you can manually trigger an internal backup using Tools > Backup & Optimize, and it’s a good idea to use that routine once in a while.)
So select Tools > Restore Backup. Choose the most recent of dated internal Backup folders. Revert to it (this will reversibly sway the current state of the database with that previous state). Examine the result, assuming success. You will have lost all data added or modified after the date of the most recent backup. Run Tools > Verify & Repair. If no un-repairable errors are reported, you’ve got a usable database. But if that database is also corrupt, repeat Tools > Restore Backup and select the next most recent Backup folder – and so on (the default is three internal Backup folders).
You might take a look at my recent post extolling the virtues of having a clean, unmodified operating system and running routine preventive maintenance on the operating system and disk directory, at http://www.devon-technologies.com/phpBB2/viewtopic.php?t=4313.
The advice here and in the other post about avoiding haxies is excellent.
But I have one question: Other than Safari, what other caches routinely need emptying? Does Devonthink Pro (I’m using 1.3.1) cache data?
Sorry for the ignorance. But what’s a “haxie”?
-Lou
Robert, the operating system and many applications – including DT Pro – cache data to save time when frequently used code is needed.
Once in a while a cached file might be corrupted, perhaps because there was an error in memory when it was being saved; if so, that error may be repeated each time the cache file is loaded. So when I see anything flaky going on, I might decide to clean out the existing cache and application files. That will slightly slow down some operations for a while, but the caches will be recreated.
Lou, haxies are applications or utilities that deliberately modify the operating system. Examples include ShapeShifter, FruitMenus, WindowShade and so on. Currently, ShapeShifter has been causing problems with saving PDFs to a DT Pro database. Some haxies seem to cause few or no problems, but can ‘break’ and cause problems if Apple modifies the OS. My own preference is to keep a pretty stock operating system, pretty much as Apple designed it.
Thanks for the details. And I agree with you, keeping a stock OS is better for stability.
All the best.
-Lou[/list]
Bill:
Thanks very much for the cache information. I don’t know why, but it never occurred to me that apps other than the browser maintained caches.
That’s until I looked in the ~/library/caches folder and saw the list. It’s the cache mother lode in there. And it’s a place I’ll keep in mind when there’s maintenance to be done.