Sync store - best way to populate second mac

DEVONthink Tips
1

I have been using Dropbox for syncing three macs in different locations. It has all been rock solid for several years. My question is whether the process I use for creating a new sync store is un-necessarily long winded, even though it works.

Long-winded way. I populate one mac, then create a sync store to which the databases upload. Then I go to the other macs, and download the databases from that new sync store. That way I know there are no conflicts, and it has worked well for me. But downloading the databases to the 2nd and 3rd mac from the new sync store takes some time.

Shorter way. Having uploaded to the new sync store from the first mac, I use an SSD to copy those databases to the 2nd and 3rd mac. etc. Then I sync the 2nd and 3rd mac to the new sync store.

Is the shorter way as safe?

2

What is a “sycnbase”? Do you mean a “sync location”? A particular database?

3

Sorry, I should have said sync store, not sync base. I have just amended my original post. I have vast over capacity in Dropbox, so I leave earlier sync stores in place and use the latest one. It is not part of a backup strategy, but there seems no point in deleting them (apart from the possibility for confusion).

I hope I now have the terminology right. The sync location is just Dropbox. The sync stores contain several of my DT databases.

In passing, I would mention that I did try having two sync stores, one for regular databases and the other for semi-archived ones etc. That only worked well if I avoided opening databases from more than one sync store at a time. So the actual reason for the latest sync store is to have all my databases (apart from those that are really old) in just one sync store, even if I only open a sub-set of the databases in that one sync store.

I haven’t really come up with a good way to store online very old DT databases. I guess they could be turned into daily backup archives and uploaded to Dropbox. I have them on my own media, but it seems a pity not to use some of that spare Dropbox capacity.

4

Why do you even have several sync stores in the same location? That does not make sense to me.

I can understand having one sync store on Dropbox and one in some other place (NAS, iCloud or so). But having “earlier” and “later” sync stores in the same place? What are you trying to achieve with that?

Regardless of that question: Both approaches are valid, IMO.

Foremost, there appears to be no point in creating new ones.

2 Likes
5

Yes, I agree with you! Creating more than one sync store seemed like a good idea a year ago, because it meant that I could open all my regular databases from one sync store, and my less common databases from the second sync store. But then I found that I was cross populating the two sync stores if ever I opened databases from more than one sync store at the same time. Hence it being simpler to have just one sync store in use, albeit a larger one.

6

You do not “open databases” from a sync store. You use a sync store to sync them. Nothing else.
Which databases you want to sync to which machine is something that you define in the settings of this machine.

Exactly. And since space doesn’t seem to matter …

So, if you have machines A, B, and C and databases 1 through 5 (for example):
Set up machine A so that it syncs all databases to Dropbox using sync store Z.
Then connect B to this same sync store Z and decide which of the databases 1 through 5 you want on that machine.
Repeat with C.

There’s exactly zero reason to have different sync stores for different databases – you end up with at least the same amount of data anyway.

3 Likes
7

There is not a singular correct method. One sync store per database (and yes, I have certain clients who have done that for years), segregated sync stores with specific databases syncing to each, or one large sync store: these are all valid approaches.

Regarding migrating to other Macs, I would advocate shuttling them around on an external drive.

8

Thanks Bluefrog, as always.

1 Like
9

Yes, you are entirely right in saying the databases are not opened from the sync store. That was sloppy language on my part. As you say, I open the databases locally and, in fact in my case, always want them then to sync to Dropbox.

Perhaps there is not precisely zero reason to have different sync stores for different databases where synced to the same location (eg one Dropbox account). But, on balance, I found I caught myself out by having two sync stores, because when I simultaneously synced one database to one sync store and synced a second database to a second sync store, both databases ended up showing in both sync stores (which was the opposite of what I intended when I set up more than one sync store). For that reason, I agree that it is best to have just one operational sync store in any given location.

I think I would be right in saying that if one has more than one sync store in the same location, it is important not to sync to more than one sync store at the same time, and, therefore, important to sync only databases that sync to the same sync store. I found myself forgetting to abide by that rule.

Do you see any logic in having duplicate sync stores in the same location? I could, for example, create a sync store entitled 31 August 2025 alongside my standard sync store. It would be a snapshot at that date in time, never to be accessed again except in case of emergency. After all, I have all that unused space on Dropbox. It is not a standard way to back things up. But is it actually illogical if it comes on top of other methods of backing up? You may say that this is misconceived, because, as you said before, you don’t open databases from a sync store, but instead sync to them. But in truth, you can download from a sync store. So in a convoluted way, you can, I think, open databases from a sync store even if that is not their purpose.

Taking that a step further, if you have databases you probably will never open again, you might decide to create a sync store for them, as well as backing them up in other ways. Or is that a heresy too far?

10

I think you are making it all too complicated and you seem to be using the sync store as some sort of backup—which I do not consider it to be a backup. Backups are different.

11

What you describe sounds like the typical use case for a backup. With the difference that this approach breaks easily:

  • You have to set up a sync store on all machines
  • You have to turn on sync to that sync store on all machines on August 31st
  • and turn it off again everywhere at midnight the same day.

What is the “emergency” that you are planning for? If you, for example, delete a file on machine A on August 31st, that change will propagate to all machines. And the file will be gone from the sync store, too. So, you’d have to sync from a younger one

No. Sync is not backup. If you have too much unused space in Dropbox, why not scale down your plan? Or use Dropbox for regular backups of your database(s), like once a day or whatever. Arq says that it can use Dropbox as a storage location, for example.

Why would I do that as opposed to zipping the database to a USB drive/external hard drive/SSD/NAS? A sync store is NOT A DATABASE. It is nothing but a heap of bytes (for all practical purposes – of course, DT can use it to sync).

A database, otoh, is just a folder. It contains all your data, you can move it wherever you want and retrieve all your files (not effortlessly, but it’s possible). Not so with a sync store.

I feel as if I were talking about block chain – a technology looking for an application. A sync store has a very clear usage pattern. Backup is not part of that.

1 Like
12

Check out the Getting Started > A Word About Backups section of the built-in Help and manual.

2 Likes
13

I do agree that ARQ is probably the better way to go.

However, could I interject a thought in my defence. It may be totally flawed. However, it seems to me that on one mac I can create a sync store called “snapshot on 31 August”. I open my 30 databases on that one mac, and let them sync to that new sync store over night. Next morning I revert to my normal sync store. I have very easily created a backup. Retrieval of a given database from that date stamped sync store in the future is admittedly a bit messy and non standard, and is counter to normal advice for backing up. But if my chances of wanting to retrieve any data are only one in a thousand, (because of other backups routines etc) I am maybe justified in using a very easy creation method at the expense of more difficult retrieval method. I do understand that because of the messy retrieval routine, this is not a recommended backup procedure. But for data that almost certainly will not need to be retrieved, is there not a case for it?

14

I guarantee that real backup software can create a real backup at least as easily as you can create and populate a new sync store.

2 Likes
15

Or use TimeMachine or Dropbox’s new backup (not sync) service for backups. Or use Arq or Chronosync or CCC .

To use sync stores as you propose is perfectly fine if that is what you want to do since there is nothing to stop you. But it’s unlikely to work as you expect. Try it and see. Can you restore ok? Few if any will likely agree to sanction your ideas.

Keep it simple. Set up sync and backup as documented in the DEVONthink Manual.

16

I do agree that the retrieval is difficult from non-current sync stores. I have managed it in the past, but not easily or without frustration. (I had to hide the existing databases). Therefore, if the creation side of the equation can be as quick using CCC, which I have and like, it would indeed be perverse not to go that route. What I don’t like is creating 30 daily backup archives for each of my 30 databases, but I see that is not being recommended here! Thanks for the patient advice all round.

17

That nails it….

18

I wouldn’t call that “easy” and it’s certainly not the intended or “highest and best use” of a sync store.

1 Like
19

Ah … yes, using the built-in DEVONthink capability to make archives zip’s, an idea. They even provide a script to do that. That makes zip archive files that a backup regime will backup. Even more automated reliable and sustainable backups, unlike your plan. Good luck.

1 Like
20

Thanks for the feedback on this! I will use CCC instead. (And/or maybe I will put my DT databases on one of my macs inside a local - but, of course, not online - Dropbox folder. That is in addition to Time Machine on all my Macs, and periodic copying over to external SSDs).