I have three computers that I would like to sync files across automatically using RealTimeSync. The problem is that not all folders are available all the time across the 3 computers, so RealTimeSync will wait until all folders are available before running the sync.
What I envision doing is using one computer as a "hub" and then allowing the other two computers to sync to the "hub" computer. But only one other computer may be available sometimes, the other computer unavailable. I'd like to allow syncing to happen between two computer even when the third isn't available.
Is this possible?
Thanks in advance.
Automatically sync multiple folders, but selective folders, with realtimesync?
- Posts: 3
- Joined: 21 Jul 2011
- Posts: 6
- Joined: 1 Jul 2015
I've never synced three computers using FreeFileSync, only two. But as no one else has responded, I'll share my ideas. If I've overlooked something important, I hope someone with more experience will chime in.
The following assumes that you will be doing TWO-WAY syncing.
I think you might be able to create two separate real-time jobs, one for syncing your "hub" computer to "peripheral" computer A, and the other for syncing your hub computer to peripheral computer B. Then run both jobs concurrently from the hub computer. When one peripheral computer is offline, its batch job won't run but the other one will, and when both perhipheral computers are online, both jobs will run. I don't know whether conflicts would arise, how RealTimeSync/FreeFileSync would handle them, or whether specifying different idle times (delays) for the two RealTimeSync tasks or running them from the peripheral computers, one per computer, would help.
If you wanted the peripheral computers to sync when when the "hub" computer is offline, I suppose you could create three separate real-time jobs: one running on the hub, syncing the hub with computer A; one running on computer A, syncing computer A with computer B; and one running on computer B, syncing computer B with the hub. Regardless of which computer was offline, the other two would continue to sync. However, I haven't thought through how to handle the problem of duplicate versioned backups.
Again, though, I hope someone with specific experience in this area will respond.
TIP: To avoid unwanted surprises, make sure all three computers are online and that no RealTimeSync tasks are running before you modify the jobs in the future.
TIP: In each job (or with each folder pair), pay attention to which computer/drive hosts the folder you initially write your FreeFileSync backups to. You'll get faster syncs if you write them to the drive that usually hosts the most out-of-date data folders, especially where big files are concerned. (Assigning a new pathname to an old file on its original drive is a lot faster than physically copying it to a different drive.) Even if you sync your backups folder -- which you should, if you want local, non-networked access to your backups from any computer -- it still saves you one copy operation per deleted or updated file. If you have really big files (e.g., HD videos, virtual machines), choosing the most suitable drive for your FreeFileSync backups folders can make a dramatic difference in how long your syncs take to complete. And if you have SSDs and slow transfers aren't a significant problem, it's a little less wear and tear on the SSD.
TIP: If your job generates backups and you are syncing the backups, make the backups folder the very last (bottom) folder pair in the job and choose local synchronization settings for it that don't generate backups of the backups. (i.e., choose either Permanent or Recycle Bin for the "Delete files" option). That way, the job will (usually) sync the backups generated by the current run.
The following assumes that you will be doing TWO-WAY syncing.
I think you might be able to create two separate real-time jobs, one for syncing your "hub" computer to "peripheral" computer A, and the other for syncing your hub computer to peripheral computer B. Then run both jobs concurrently from the hub computer. When one peripheral computer is offline, its batch job won't run but the other one will, and when both perhipheral computers are online, both jobs will run. I don't know whether conflicts would arise, how RealTimeSync/FreeFileSync would handle them, or whether specifying different idle times (delays) for the two RealTimeSync tasks or running them from the peripheral computers, one per computer, would help.
If you wanted the peripheral computers to sync when when the "hub" computer is offline, I suppose you could create three separate real-time jobs: one running on the hub, syncing the hub with computer A; one running on computer A, syncing computer A with computer B; and one running on computer B, syncing computer B with the hub. Regardless of which computer was offline, the other two would continue to sync. However, I haven't thought through how to handle the problem of duplicate versioned backups.
Again, though, I hope someone with specific experience in this area will respond.
TIP: To avoid unwanted surprises, make sure all three computers are online and that no RealTimeSync tasks are running before you modify the jobs in the future.
TIP: In each job (or with each folder pair), pay attention to which computer/drive hosts the folder you initially write your FreeFileSync backups to. You'll get faster syncs if you write them to the drive that usually hosts the most out-of-date data folders, especially where big files are concerned. (Assigning a new pathname to an old file on its original drive is a lot faster than physically copying it to a different drive.) Even if you sync your backups folder -- which you should, if you want local, non-networked access to your backups from any computer -- it still saves you one copy operation per deleted or updated file. If you have really big files (e.g., HD videos, virtual machines), choosing the most suitable drive for your FreeFileSync backups folders can make a dramatic difference in how long your syncs take to complete. And if you have SSDs and slow transfers aren't a significant problem, it's a little less wear and tear on the SSD.
TIP: If your job generates backups and you are syncing the backups, make the backups folder the very last (bottom) folder pair in the job and choose local synchronization settings for it that don't generate backups of the backups. (i.e., choose either Permanent or Recycle Bin for the "Delete files" option). That way, the job will (usually) sync the backups generated by the current run.
- Posts: 6
- Joined: 1 Jul 2015
I just had a thought: if the second (three-job) approach does in fact result in duplicate versioned backups using the "File time and size" Comparison variant, changing local comparison setting for the backups folder pair to "File content" might solve the problem. However, the comparison stage of your backups folder syncs will take considerably longer.
- Posts: 6
- Joined: 1 Jul 2015
Update: My third tip might be wrong. I've been reading back chronologically through the topics in this forum, and unless something has changed, a FreeFileSync job will not process files that are added to its lower/later folder pairs by higher/earlier folder pairs in the course of the a given run. My own (inexhaustive) trials seemed to suggest that they were, but apparently they aren't. Accordingly, to sync backups generated by a RealTimeSync/FreeFileSync job, you should move backups folder pair(s) to a separate RealTimeSync/FreeFileSync job.
