Script to automate backup for each DB, regular intervals?

I have TM backing up all my data locally to a RAID NAS, and have the same data sent to a ‘cloud’ online backup. So I believe my underlying data is protected.

But-regarding my database structures, I have been searching the forums, and might just be dense, but I cannot figure out the following:

  1. How to backup each database without opening each and selecting the Export > Daily Backup Archive

  2. How to arrange this on an interval, let’s say once every six hours, or once per day

  3. How to determine the place these backup .zips are stored

I would greatly appreciate someone pointing me in the right direction if these questions have been addressed.


As I was searching for where my ‘Daily Backup Archive’ files were kept (I still don’t know!), I realized that under preferences, there is an option for ‘Backup and Optimize’ on a regular basis.

Is there a difference between these two choices (Export>Daily Backup Archive and the ‘Optimize and Backup’ performed under preferences)?

Where are the backup files kept? Are they stored in the same database?


In the Backup folder under your home folder.

I’d like the script to prompt for a location (or at least indicate where it is), but am too AppleScript-inept to customize it. :wink:

Tools > Backup & Optimize updates one of the (by default) three rotating Backup folders inside the database. I recommend this, but it’s not the same as having a good backup strategy that should include full database backups stored on an external medium (ideally, including offsite storage of backups).

For example, if your hard disk were to crash, the database internal Backups and the actual files stored within Files.noindex may not be recoverable.

Thanks again, Bill! I have read many of your posts, and agree with you wholeheartedly about redundancy and backing up.

I backup the entire database folder.

I use TM locally, with a NAS and RAID, which gives me multiple backup points, as well as redundancy in RAID 5.

I also backup offsite to IDrive, just in case I should have a fire or theft that eliminates my primary computer and the RAID.

But…what I am missing until now is a backup of the database structure, which I have just learned about. What I would like to do is to automatically backup this internal database structure on a regular and automatic basis, so I won’t forget, and then to have my 2 backup systems backup these database files.

What I don’t understand is:

  1. Does the Tools > Backup & Optimize = the Export > Daily Backup Archive?
    (I am guessing not, since the B & O lies within the database, and the Export goes out to the Home folder…)
  2. What are the differences? Should I be using the Export to save to other media? Or can I rely on my current backup strategy reasonably protecting the B & O files within each database?
  3. Any way to run these automatically?
  4. Need I do this for every database?

Hopefully there are short and sweet answers to each of these :wink:


OK, kept searching, and found some answers:

  1. I now understand that Backup & Optimize involves just the database structure, and is stored within the database itself.

  2. Export is the full database and data, minus the internal backup folders.

So, to update my questions:

A. Should I use the Export > Daily Backup if I backup my DB files via TM and offsite storage (beyond the space savings by having the file .zip’ed)?

B. How do I set the destination for the Export > Daily Backup? Need I change the script?

C. If I can use my original backup strategy instead of Export > Daily Backup (TM and offsite web backup of my database files), then I don’t need to create an automatic backup strategy for the Export > Daily Backup-correct?

D. I am assuming that the Backup & Optimize occurs automatically as set in preferences. Is this so?

Thanks much. Just trying to be on the safe side!

There’s no reason to if you trust TM and offsite storage backups.

Yes, you could change one line in the script to use some other destination than ~/Backup and/or change the output filename.

Simply backing up .dtBase2 database packages directly with whichever utility you prefer, whenever and to wherever you want, may be sufficient. To be safest, ideally when DT isn’t running or at least when there’s no db update activity. Using the Daily Backup Archive script is one way to keep DT dedicated to the backup task since it locks out other interaction during that time. And the script excludes any internal Backup* folders, which may or may not be desirable.

Yes, or the reason for Preferences > Backup would be puzzling. :slight_smile:

Backup & Optimize “internal” backups may have generally been more useful in DT v1, when most database content (excluding indexed documents) was contained within DEVONthink-.database files. With v2, most database content is in external files under the Files.noindex hierarchy of the db package and the DEVONthink-.dtMeta files that supersede .database are much smaller. Even if you didn’t create external copies of v1 internal Backup folder there could be a chance of recreating a larger portion of a database from one of them. With v2, there’s only one instance of Files.index per db, which Backup & Optimize ignores, so restoring from v2 Backup* folders won’t recover a significant amount of content like it could in v1.

Backup & Optimize can be useful in several ways.

  1. When I’ve invested significant time and effort in modifying a database, manually invoking Verify & Repair followed by Backup & Optimize takes little time and let’s me “save” my work without waiting for the next scheduled backup. Is that a bit paranoid? Maybe, but I recommend it. Perhaps the next thing I do might screw up the database, and unless I had made that backup, hours of work would be lost.

  2. Restore Backup can be a form of “Undo”. Suppose I’m reorganizing a database, adding and removing groups and moving documents around in the revised organizational structure. Now I realize that I’ve screwed up, and manually correcting the mistake would be difficult. Here’s where Restore Backup can be used to restore my database to it’s state before I screwed it up. If I had not deleted documents during my reorganization, my mistakes will be undone.

  3. Recovery of a database that’s so damaged that it won’t open can be done by copying the contents of an internal Backup folder, plus the Files.noindex folder, into a new Finder folder. Use the Info panel to rename that folder by adding the suffix, “.dtBase”. Close the Info panel, Presto! We have a database created from it’s state before it was damaged. Were new files added after the time of the internal backup that we used? If so, they will be identified as orphans, and we can run Verify & Repair to index their text content.