2BrightSparks

Before posting, and to avoid disappointment, please read the following:

This forum is not for 2BrightSparks to provide technical support. It's primarily for users to help other users. Do not expect 2BrightSparks to answer any question posted to this forum.

If you find a bug in any of our software, please submit a support ticket. It does not matter if you are using our freeware, a beta version or you haven't yet purchased the software. We want to know about any and all bugs so we can fix them as soon as possible. We usually need more information and details from you to reproduce bugs and that is better done via a support ticket and not this forum.

One major improvement would be including the "delta copying" technology to the product, where only changed parts of large files are copied. Without it SyncBack is not a good solution for backing up large files like outlook.pst, databases etc over FTP/Internet.

I'll 3rd the request.
We use SB at work to copy large (think 60+GB) image files over a VPN. The connection is fast, but being able to copy where the files are "split" would be great because we wouldn't have to worry about those larger files as much.

hi:
i am monitoring syncbackse over 1 year and waiting for this function.
i wonder if there are other good products can do this?
i want to deploy backup software for our company this year. we have hundreds of compurters. i have heard that altiris is good, but is is bought by symantec now.
thanks for help!!

I use rsync too - and there is no better tool to backup files across a slow connection.

But rsync using cygwin has one big drawback - if you use it over a faster connection ie like a internal network - the cygwin file I/O is SLLOOOWWW.. Yes, is is faster than what most of us have over the internet (so is thus not an issue), but on any of my windows machines it is slower than even a 100mbit connection, let alone a gigabit one.
As a rough idea, on a windows machine that the hard disk will do 76Mbytes/sec write, via the cyqwin emulation we get about 9mbytes/sec...

So while I agree that it would be a GREAT feature for PRO, it's not just a case of using the rsync library - it would have to be re written to get proper performance under windows... (something I've been thinking of doing for years, but still haven't got around to..)

You can already use Rsync, Cwrsync, Unison, etc with SyncBackSE (what DeltaCopy uses). SyncBack can kick off the command line after it is finished or before it runs.

Also... for those of you who use DeltaCopy to transfer files over the web vs a regular Rsync server... do you realize how insecure a DeltaCopy server is? It is almost as bad as having full read/write annon FTP servers running with all your private data on them. DeltaCopy is designed to be an internal network resource for small companies who don't want to mess with full blown Rsync.

deltaend wrote:You can already use Rsync, Cwrsync, Unison, etc with SyncBackSE (what DeltaCopy uses). SyncBack can kick off the command line after it is finished or before it runs.

Not really, as you can't use it to shift the files to the destination INSTEAD of using the SE copy function.

deltaend wrote:Also... for those of you who use DeltaCopy to transfer files over the web vs a regular Rsync server... do you realize how insecure a DeltaCopy server is? It is almost as bad as having full read/write annon FTP servers running with all your private data on them. DeltaCopy is designed to be an internal network resource for small companies who don't want to mess with full blown Rsync.

Agreed! DeltaCopy (which I use at times) should only EVER be used over a secure VPN connection, and a secure VPN connection should be IP to IP address supported by a hardware firewall!

deltaend wrote:Ian, go go get that performance up! Do it!

The trouble is that I've got many things to write in my spare time, as so much code out there makes me unhappy! You shouldn't have to write everything yourself to get it done right!

That said, it isn't the rsync camps fault - they only wrote it for UNIX. And it isn't really cygwin fault either, they provide an OK general framework to use UNIX programs on windows.
So it's amazing that it works at all..

But it IS really odd that no one has made a native windows one by now - or not that I can find, and I have looked around a lot!!

hi:
we are about to buy acronis true image workstation as our backup solution. i thought syncback pro is better in many ways, but we have many
outlook pst files to backup in every computer. will syncback pro support "rsync" like function in the near future? we hope we can use your great product.

mickyj wrote:Hi, maybe in future, but we've got many other features to add before then.

As I understand it, rsync ops require a running process at the source. I still prefer the option which the author of zsync was developing, last I heard. ie, one which allows copying from a source without the need for the source to be running a server process.

technically speaking, you are NEVER going to able to run a full rsync type process with something running at both ends, as you need a process at both the source and the destination to doing 'sliding windows' on the files to figure out which blocks need to be transfered.

So you are always going to need software at both ends - though you wouldn't need it running all the time if you could remote start the other end with some other mechanism..

You always going to need a server process of some kind at the source end, but it need not necessarily be an rsync-specific process. zsync was designed to have some rsync stuff going on in the client, but working only with say, HTTP, at the other end to provide the downloaded files.

The other part of the process, dealing with delta details, is supplied by pre-processing at the HTTP end, leaving synching details in a separate static file, so the client can read those details stored alongside the main source.

Most suitable for distribution of a new file release to many interested parties.

yes that will work - BUT you still had to have a process at both ends, you're just running one of them at a different time to make a sync file.

But that isn't really what rsync is truly about - what you describe is more the traditional diff process, where you are updating in one location, then sending the differences to other location to be brought up to date from a known base. Then it makes much more sense to use a static difference file, as we all do!