How to SYNC VERY large file

[Paraf]

I want to SYNC a system partition backup file which is very large. Most of my usage to date is for offsite backup – just in case!

It is syncing to another desktop (both windows 10) via internet. Due to its size & our internet speed this may take days.

 

What happens is that at each system restart/re-connection SYNC appears to restart from scratch. So on day one we got to about 25% then on restart next day we are back to 1%.

 

Is this how SYNC works? In that a sync must be completed in one session or is it supposed to be able to remember how far it had got & continue?

All other (small) sync’s work fine.

 

Any clarification & suggestions much appreciated.

 

[ivarson]

im in no position of telling how btsync works, but are you sure that the backupfile doesnt change between sync-attempts?

have you taken md5/sha on the file?

surely sync shouldnt restart if the hash stays the same?

[Paraf]

Its actually a windows image backup so a set of folders with several small files & some very large ones. None have had any changes.

Wondering if IP address comes into this at all. What if the ip address changes (VPN use) could this affect Sync?

 

 

[ivarson]

Again, I'm a freshman at Sync, but the way peers address each other really shouldn't affect their content. 

I do work with Windows servers and their bmr/systemstate backup (DPM).

I'd just make sure the vhdx really didn't have its crc changed on either side. If you copy the files into the offsite share by other methods, is it still being overwritten? (it shouldn't). 

Of course there's logs generated by sync probably giving a reason for resending that other guys here can instruct you on, but other than an actual tampering with the file consistency, I don't see why it should resend.. Sorry, hope you'll get better help from anyone else. 

[seren]

I've had this issue in the past as well, so if you figure out the cause, please post an update.

[PaulU]

I have a suspicion that BTSync simply calculated the %age of what remains to be synced each time it starts - i.e. what's not yet been done, not the total. Thus, every transfer is 0 to 100%.

[Paraf]

Thanks for the suggestions, I had not thought of the percentage been representative of the current process only rather than the whole transfer which to me would be more meaningful.

I will do a test on 2 local system I have access to & check the process - will report back here. 

[Paraf]

PaulU is correct - after every pause/restart on sync or any system restart the percentage is reset to zero but the data transmitted so far is saved.

So no problem really except that you just don't know how much has been transmitted unless you have access to the destination device.

I would prefer to have an actual percentage as well & will submit that as a suggestion to the wish list.

Thank you for the input to this query. :-)

 

 

 

 

[seren]

This is good to know. This behavior confused me for a while since I assumed that BTsync was restarting the transfer each time.

[Helen]

@all, Yes, you're right - sync on each start resumes percentage count from 0%. Because when it's OFF, Sync cannot know if anything was changes in the file on either peer --> cannot know how much was already synced, so has to recheck the whole file. Once done, syncing resumes from where it was (if the file indeed didn't change) and sync the missing file pieces.  

 

[Paraf]

@Helen, I think (& maybe its just me) it would be more meaningful to have the actual total % rather than % of remainder. After "indexing" at each end, Sync knows whats where and what remains. So a simple calculation. That is how most applications work.

Anyway the most important part of all - we now know how it works :-)