Backup/Export Best Practices

that is what indexed files are for.

Frankly do not see the point. These files are used only by DEVONthink and unless you can figure out what they are then useless to you.

Pardon my ignorance, I think I am misunderstanding.

But if I am trying to view the files on my synology NAS (say from a windows PC) I am not able to from the sync store as the files are encrypted, thus not giving me access to the indexed files?

What I am trying to achieve is the above (Aka files in folders on the NAS accessible from windows if I desire remotely).

the indexed files remain outside of DEVONthink and are accessible if they are accessible. nothing to do with DEVONthink.

While you can backup a sync store, the thing you should be more concerned about is backing up the database. Personally, I don’t backup any sync stores except incidentally with local sync stores I’m testing.

1 Like

Gotcha. I think I was confused on what that meant. Sounds like maintaining a file structure and indexing them solves that issue, and then allows me to backup that folder structure with the NAS more easily without risk to the database.

Thanks!

I cannot think of any reason for mear mortals unlike you @BLUEFROG to backup the sync store. am i naive?

Makes sense. Thanks

If you have local sync stores on your Mac or an external, there’s no harm in it. But any real use of it would be outliers.

Perhaps it does, provided you’ve read and understood the In & Out > Importing & Indexing section of the Help. :slight_smile:

My reasons are
. access to my data independent of Devonthink
. restore selected corrupted/lost files directly without doing a whole database load thing

To achieve “Backup/Export Best Practices” I think you are heading in an erroneous direction. Up to you, though.

For this, index the files into DEVONthink. The files are not in DEVONthink and you can do with them what you want. Read about that in the “DEVONthink Manual”

If you indexed files, then you can and must restore any of those files lost or corrupted by your own means independent of DEVONthink. If you lose or otherwise corrupt imported files, then that means the database is corrupted and you will have to do the “database load thing”.

No, I prefer the files contained in the Devonthink database
And I’m comfortable with the export as part of my backup process

Ok. Up to you. I guess I’m puzzled how you access the data “independent of DEVONthink” if the files are inside DEVONthink database? You accessing the files inside the DEVONthink “package” with Finder or other apps?

Edit: to clarify as I’m curious, of the many options under the Menu: File → Export, which do you use? To database archive (which I use in a weekly automated script)?

My backup process includes

  1. direct backup of the database files (software TimeMachine/Arq, hourly incremental)
  2. File > Export > Files and Folders (weekly, full) (also backed up by Arq)

Thank you. This is very helpful. I think my initial thought process was the same about keeping files in the database and wanting to export as part of my weekly backup.

Can I ask how big your database are and how you divide them up? I was planning to use multiple database but the export might be easier if it is one big database that I can export rather than multiple weekly. Since my use case is a lot of iOS/iPadOS I could just use those devices on demand rather than downloading whole database.

I was planning to use multiple database but the export might be easier if it is one big database that I can export rather than multiple weekly.

I would not make a decision on the division of data based on the possibility of doing exports at some point.

Also, using a shallow sync with a gigantic database is not a surrogate for using smaller, more focused databases.

Organize based on actual needs and uses of the data you’re working with.

1 Like

I have a 15GB database with 30,000 records
Just a single database (for now)

If by any chance you’re tempted to try a little AppleScript there’s an interesting thread here (starting where I have linked it) about automating export of open databases. I use a script weekly which saves me a lot of time—based on what was discussed in that thread.

Edit: added the link!

Stephen

1 Like

Thanks, I need to look into automating my process
It’s a little more complicated with Export>Files&Folders