@ korm: I agree that itās a good idea to remember that all drives will eventually fail. For that reason, I change out the drives (I rotate two drives, one of which is stored off-site and switched every few days) that I use for Time Machine backups after about two years of use, and always make sure that the replacement drive is a high quality drive from a reputable manufacturer, and has considerably more storage space than the drive it is backing up.
The last two times Iāve bought a new computer, Iāve transferred data from the older computer to it via a Time Machine backup and had no problems. (As Iāve been able to use a Thunderbolt connection from the backup drive, the transfer speed has been fast.)
@ Calapso & Cassady: Both the commands File > Export > Database Archive and Scripts > Export > Database Archive allow the user to select the location to which the Database Archive file will be saved. But the ādefaultā location is already set, so make certain you check it and choose another location, such as a mounted external drive, before hitting OK!
The resulting Database Archive file for a database will automatically be given the Name of the database file plus the date the archive was created, plus the .zip filetype of the compressed database file.
To use a Database Archive, e.g., for recovery of a damaged database: This should be done with the DEVONthink application Quit. First double-click on the archive file to unzip it. Then move the uncompressed database file to replace the damaged file, so that it is in the location expected by DEVONthink. (Also, if recovering from Time Machine or other external backup system, do so while DEVONthink has been Quit.)
Regardless of the backup system used (except for Database Archive), the backup system will happily backup up DEVONthink databases that have errors. For that reason, I periodically run Tools > Verify & Repair on my databases (and immediately do so if anything flaky has happened). I havenāt seen database errors in a long time; my databases stay stable. But I stick with those habits!
A cautionary note: The older a backup file, the more likely loss of files added after the time of backup becomes. Thatās one of the reasons I like Time Machine, as it is set to make hourly databases and will keep those for up to 24 hours. It then converts a set of hourly backups to daily backup, then weekly, etc.
So to avoid loss of work, if it is necessary to resort to an external backup file, choose the most recent one that will restore a working database with minimal loss of new content or edits made after that backup file was created.
With that in mind, if the database damage had occurred within the time span in which internal Backups had been made in the database, the first thing I might try would be use of DEVONthinkās Tools > Restore Backup procedure. By default, there are three rotating internal backups of the state of the database. Iāve got Preferences > Backup set for daily internal backups. So even if I had to resort to the third most recent internal Backup folder to return to a good working state of the database, any new files added since that backup was made wonāt be lost. The new files added to the Files.noindex folder inside the database will be found by running Verify & Repair and placed in an Orphan files group, from which they can be properly filed into the database. And of course any edits that had been made in the files contained in Files.noindex will also be up to date.
The next step I might take, if Restore Backup didnāt result in a working database, might be Tools > Rebuild Database, for the same reasons, to preserve contents of newly added or edited filesāespecially if a lot of work on the database had been done subsequent to the time of the most recent working (i.e., āgoodā) external backup file.
There are preventive maintenance procedures that can help prevent database problems or correct them before damage escalates. 1) Verify & Repair to confirm that no database errors exist, or to become aware of them and correct them. 2) Appleās Disk Utility app to check for and correct permissions errors and to check for Disk errors and correct them if found. 3) OS X maintenance procedures to keep the operating system clean, lean and efficient, either using Terminal.app procedures or (in a more user-friendly way) a utility such as C0cktail or OnyX (thatās updated for the installed version of OS X).