There are some old threads regarding the use of ChronoSync’s “dissect packages” option. However, there users seemed to try to use ChronoSync to sync DEVONthink database.
I want smaller backups. Most of my databases contain mainly indexed records, however e.g. the global inbox doesn’t - which means changing a single record results in a 5 GB global inbox backup.
Does someone use ChronoSync’s “dissect packages” option? Does it work? Which one exactly?
I don’t use ChronoSync but this option sounds especially dangerous if backups are created while databases are in use (or even modified at the same time).
The only option is likely to restore a backup in a different location, to open the database and verify it (including the file integrity). However, the sync should be disabled first.
I have the same question regarding ChronoSync, and for the same reasons: smaller backups. While most of my databases are 2GB or much less, I have one huge database of 65GB that I want to back up but I balk at the inefficiency and resources spent backing up all 65GB just because I added a 25kB file. ChronoSync seems like the answer as it would back up only that single file of the database.
Of course, the assumption is that the backup is performed ONLY when the database is closed (in fact, I would not even have DT running at the time).
Basically, this question applies when using other software like Carbon Copy Cloner, which appears to also “dissect” the DT database files.
Given that for the case of databases created in FileMaker Pro there is no safe option other than full copies of the databases when closed because of the proprietary, monolithic nature of the FMP file format, we are given the hope that DT’s method of storing the original source files within DT’s “wrapper” where the source files are available for retrieval via the Finder, that maybe DT could tolerate ChronoSync’s “dissection” when backing up (assuming the databases are closed).
I and others would really like a formal assessment of this if possible. Thanks!
I used to do this a lot with rsync, so here’s my experience.
If you do a one-way sync when the DB is closed, this is perfectly safe.
If you do a one-way sync while it is running, there is the chance that it will copy files over while they are in an inconsistent state. If your machine then crashed and you needed to restore from the backup, you would have an inconsistent db and the odds are good that a Verify & Repair will get you a working database, though you may have orphaned files and whatnot.
Where this gets into problem is when you are trying to do a two-way sync where files may be changed and databases may be open on both ends. That can really screw up the database. The good news is that your actual data files(e.g. pdfs) are going to be ok but the database can get totally messed up. So this one, don’t do it.
@pete31 and others: thank you for posting your experiences with chronosync and DEVONthink.
one of my database is 20GB - topic for a separate day.
my current settings are as follows. In addition I synchronize deletions and Archive replaced files which are then moved to a separate archive folder on the receiving drive. I backup using Chronoagent to a Mac on Ethernet.
thank you. that is a very powerful idea. did not realize before today. will absolutely look into it.
it seems that you are saying that it is faster - and arguably it should be because DT should know what changed inside of it.
the issue is that my target sync location is only accessible through chronosync because I currently use chronoagent to write to it.
but perhaps I need to look into some sort of ssh connection to that drive - that drive is connected to a Mac mini and the Mac mini is behind my house router when I am traveling.
ideally I would like the backup process to be automatic even when I am out traveling.
One thing you will hear is that syncing isn’t a backup. I’ve never lost anything in a sync. I boldly delete databases that have been synced because I can always download them from the sync store.
It’s also easy to be bold like that with weekly backups outside of sync.
A problem I see with syncing as a backup is a backup should be a static snapshot of your work. If I delete files I wanted to keep there isn’t a way to revert the database to the way it was the last time the sync store saw it. When I sync, it will delete the files out of the sync store, not restore them to the database.
That not my understanding and experience. Chronoagent is the background scheduler that runs Chronosync Tasks. And Chronosync tasks points to file services that your computer has access to. You can surely access those same file service with finder, command line programs, or whatever.
I recognize the distinctions between sync and backup. For DT3 backup:
I’ll automate daily backups using the DT3 provided archive script, possibly with DT3 triggers, retaining only the two most recent backups in the Backups folder. These backups will then be uploaded to to my Mac Mini. The mini uploads to Backblaze personal, which gives me one month of archive.
I plan to sync to a local store for reliable mobile access, as iCloud sync has issues on my phone. Mac mini WebDAV is what this will have to be.
Additionally, I’ll use TimeMachine to a USB-c drive for regular backups of my documents folder, ensuring file safety within and outside of DT3.
I’ll automate daily backups using the DT3 provided archive script
I would dissuade you from this frequency. Especially as databases grow, the archiving takes more and more time. I would suggest you do the database archive on a weekly or monthly basis instead.
ChronoAgent is a separate install from ChronoSync. ChronoAgent is sort of like an ftp server.
For instance, I have ChronoAgent installed on my laptop. Just as I can tell my desktop ChronoSync to sync to a USB disk, I can also tell it to sync to the ChronoSync instance on my laptop.
I liked it in principle. The need to boot up my laptop to run a sync proved a little cumbersome. I still like ChronoAgent, actually, but I don’t often use it.