Sync Timestamp, How To?

[syadnom]

Here is a really brief description of what I'm wanting to do:

 

client machine>btsync>file server

track when client's folder(s) is checked/checks for updated files

track when a sync for each folder is completed.

use this information to derive whether or not the client computer's share is synced or has been within some specified amount of time (say 2 days), store this on the server side/in *sql

 

basically, I can query the file/database to see when folders are not backed up.

 

the API has documentation on how to get a list of the hosts attached to each share, but I can't find anything on how to find out when the last time those hosts 'checked in'

 

a critical part of backups is knowing that they are actually being completed.

 

 

additional info just for fun:

server side storage is on a ZFS file system and snapshots will be made there.  I don't need .SyncArchive.

I will have a local cache onsite with a low power machine+usb disk (non-redundant, literally a volatile cache), possibly on a beagle bone black or pi.  This way I can share out the cache and enable file history for windows clients so restorations are seamless.

 

the missing part of the scenario is determining when a client has actually completed it's backup(s).

 

also, I have considered just putting a scheduled task on the workstation to write to a .track file into the root directory of the local folder and then just using 'find' on the server and parsing out the results but this is a bit less that ideal, if btsync would just update such a file per folder for me as part of the .sync* files then I would be ecstatic.

 

Thanks

[RomanZ]

syadnom,

 

please see "Get folder peers" command in API. It indicates:

1) How much data left to upload (0 means upload complete)

2) Contains the timestamp of last sync.

[syadnom]

RomanZ, I've applied for an API key to get started. 

 

Here is my confusion on the 'Get folder peers', if the language matches the app gui, then last sync is the last time a sync was actually performed.  If no sync was needed, then it doesn't occur and that timestamp doesn't get updated.

 

In many circumstances, this works.  What if a machine is online, but hasn't had any changes to a synced folder for 2 days.  If I'm going to trigger some sort of response, I need to know that that machines at least checked in. 

 

I hope I'm making my need clear, I need to know that a device IS synced within 48 hours.  If they synced 60 hours ago and havent needed to sync, I need to know that they are still in sync.  Else, I might be hunting down a machine for not syncing even though it doesn't have anything new to sync.

 

in a nutshell, I need a timestamp of 'last seen' so I can extrapolate that they are in or out of sync.

 

Also note, I want to do this all 'target' side.  I don't care to run scripts on the workstation, I only want to on the machine(s) that will handle bulk storage.

[RomanZ]

syadnom,

 

That's right. It API also shows the time of last sync, not last contact. I can suggest that the script/app that is calling API can put a special small file and change it once a day to trigger sync and update sync time.

[syadnom]

found a curious oddity in testing this.  I can't just touch the file. btsync will replicate the timestamp without updating the last sync.  I have to actually change the file contents to have it update the last sync time.  Seems strange because it is actually replicating the file timestamp changes.

[RomanZ]

syadnom,

 

It is done intentionally. When BTSync makes full folder rescan, it only checks file size and mtime changes. If they are changed - it is going to re-hash file to see which parts of the file were actually changed and need to be transferred.

 

so, the mtime and file size trigger hashing (and actually save BTSync from redundant hashing).

[syadnom]

touch changes the mtime, so  when I touch the file it does trigger btsync according to the rules you outlined in the last post.  btsync does actually transfer enough data to update the mtime on the remote side(s), it just doesn't update the sync time.  Apparently unless file contents actually change.