[Discuss] Sync Revisited

[Richard Pieri]

On 7/30/2014 12:03 PM, John Hall wrote:
> How elaborate are your custom scripts for unison? I assume it just
> requires rsync and unison on the server?

It's just a simple for loop:

for s in ~/.unison/*.prf; do
  unison -auto -batch -terse $s
done

Initiated manually from desktop icons. SSH is used for transport, public
key authentication required, and ssh-agent doing its agent thing.


> Is https ftps file access from anywhere with login a requirement for
> you? multiple user support?

In addition to the administrative overhead, I don't like the idea of
having a web server with access to such a huge chunk of my life
listening on the open Internet. ownCloud might make sense on a private
intranet but exposed to the world? Not on my servers.

At the enterprise level? I'd deploy OpenAFS internally and use the
corporate VPN to encrypt traffic on public networks. After all, Dropbox
was inspired by the AFS deployment at MIT. It doesn't make sense to me
to run a replacement for a replacement when I can run the original for
the same or less effort.


> *BTSync*
> How much extra memory does this consume and is it choking on large files?
> How much slower is it?  
> Can you limit bandwidth as with a good BT client?

BTSync does support bandwidth limits. Currently they are global for the
entire node but BitTorrent are working on per-directory limits.

The in-memory databases peaked for me at around 500MB. They've made
improvements for directories with lots of small files but there's a
limit to how much optimization can be done. Note that this isn't a
problem unique to BTSync; anything using in-memory databases for file
metadata is going to chew up lots of RAM.

Startup times are the slowest aspect. The software needs to scan
everything to build up the in-memory databases. It's a killer on my
notebook.

Very large files are still problematic. FLAC files are okay but I wasn't
able to reliably sync VMware disk images. Again, it's a known problem
that they're working to resolve.

-- 
Rich P.