Backup Strategies

[JCHHenderson]

@chrillek

I never understood the need for a “daily backup my DT databases as ZIPs” script anyway. Maybe that’s a remnant from the time before Timemachine, Arq, Backblaze etc.

…so do you just use Arq / Timemachine etc on the (possibly open) .dtbase2 files without separate archived copies?
This is what I have been doing until recently. Arq to B2 and a local NAS has always worked for me, but I recently added storj.io which gives errors backing up open .dtbase2 files.

[JCHHenderson]

@Stephen_C

No - the very point of the script is that it’s archiving open databases. Of course, I’m not working with the databases at the time the script runs.

You misunderstand me (sorry if I wasn’t clear). I meant whether it is OK to use Arq or Time Machine to backup the (possibly open) .dtbase2 files (without requiring the intermediate step of using the script to create a zipped archive for Arq/Timemachine to then backup offsite (or wherever).

[Stephen_C]

I strongly concur with @chrillek’s comment here. I always try to ensure that my databases are closed when backing up to Arq, Time Machine or CCC. However, if I do, on occasion, overlook that, I don’t worry too much because whatever else I’m doing I’m certainly not working on any of the databases at the time any of those backups runs.

Edit: I certainly wouldn’t bother to create a DEVONthink archive simply for the purpose of backing up off-site (or wherever else you may choose).

Stephen

[JCHHenderson]

@Stephen_C

I strongly concur with @chrillek’s comment here.

got it - thanks for clarifying!

[chrillek]

@JCHHenderson

…so do you just use Arq / Timemachine etc on the (possibly open) .dtbase2 files without separate archived copies?

Exactly. I don’t really care about open/closed, since at the time the backup occurs, nothing is going to change in the database. And frankly, even if it where: There’s always the next backup…

[chrk]

@JCHHenderson

I meant whether it is OK to use Arq or Time Machine to backup the (possibly open) .dtbase2 files (without requiring the intermediate step of using the script to create a zipped archive for Arq/Timemachine to then backup offsite (or wherever).

Given that Arq, Time Machine, and Carbon Copy Cloner* use snapshot based backups, there is no need to close any databases.
I have DEVONthink open 24 hours and use all 3 backup apps mentioned. Since I use Arq with Google Cloud & Storj, that’s 4 backups per hour.
Never once has this been an issue. You can even modify content in an open database while backups are running. Snapshot based backups are frozen in time, it doesn’t matter if data changes while backing up.

(*when used with APFS volumes)

Also, see this comment for documentation screenshots from Arq and CCC that confirm this.

[JCHHenderson]

@chrk

Given that Arq, Time Machine, and Carbon Copy Cloner* use snapshot based backups, there is no need to close any databases.

That’s great to have confirmed - thanks.

[Roger1938]

I have seen several indications that Backblaze dose not save metadata. I just restored one of my images from Backblaze and all of my metadata was there?

What am I missing?
Roger

[Blanc]

@Roger1938

all of my metadata

Are we talking image-specific metadata here (so perhaps camera and lens type, focus etc.), or file-specific (such as creation date)? Or does “image” refer to a backup as a whole? In which case, a backup of what exactly?

[chrk]

Details from Backblaze themselves:

Backblaze backup of metadata...are forum warnings still valid?

FWIW, here’s the response from Backblaze support: “Extended attributes aren’t included in the backed up files. This means no finder comments, no finder tags, no quarantine information, and a few other items. Permissions and modified dates are retained. Creation dates are technically backed up as well but they aren’t retained when restoring a file so they’re essentially not backed up as well. You might also find modified dates to be changed to the date that files are restored via zip restore a…