A Tarsnap-Alike for Private Storage
synctus.com
synctus.com
That being said, the market for a Windows version should NOT be individuals, it should be marketed to the enterprise. Tarsnap solves a problem that many companies have and pay buckets of money to cure.
(edit: I say that even though I don't even possess the aptitude necessary to fully respect his skills; he's a genius, and that's not a word I ever use lightly. I just hate to see a great work of engineering, like Tarsnap, languish in relative anonymity because it's poorly handled as a business.)
It is super exciting sometimes running my business, helping give transfer some of those business skills that change their lives and those of their customers.
And I can't / don't speak about Colin in this comment.
It'd be nice to see a brief comparison of ddar, rsnapshot, and other things that might fit that role.
Some others are briefly mentioned under "Alternatives", including a comparison with Tarsnap.
I only have direct experience of Tarsnap and duplicity. Additions/corrections welcome.
As I store the backups on a shared machine, the most important feature for me is that the backupped data never passes through the target machine in unencrypted form, at any stage.
Sometimes, though, it can be challenging to get it working, and it has a few other issues (e.g., moving backups for systems from one pool to another) that can make it difficult in the long-run for some use-cases.
How is this different from something like rsync?
ddar is for storing things de-duplicated, possibly over the network. It will save both storage and bandwidth. However, you won't get a tree on the other side, just an opaque container than you can extract the data out of again.
So: rsync to bring two trees in to sync, Tarsnap or ddar to store things (eg. for backups).
You could use rsync to store backups, but only really with the help of other tools. Tools like duplicity, rdiff-backup or rsnapshot.
Tarsnap was the first common system (to my knowledge) to do full de-duplication for storage. ddar works in the same way.
By full de-duplication I mean for the system to have an overview of all data in order to optimise transfers and storage.
For example, if I were to download a large image (say a Debian ISO) and then back up my machine using Tarsnap or ddar, then delete the ISO and perform another backup, then download the ISO again and perform a third backup, the third backup will optimise out transmitting the image because it is already stored. I don't think that rdiff-backup, rsnapshot or duplicity can do this, since they only consider one backup at a time. I believe this applies to renaming files around as well.
rsync does a lot to maintain file attributes across heterogeneous systems, does ddar address this issue as well?
So, every day at 10pm, I want to make a backup of my server to another server. I ddar or rsync the files to another server. Monday at 10pm, I do it; Tuesday at 10pm, I do it; Wednesday at 10pm, yep, did it. Now it's Thursday and for whatever reason, I have to restore the system to the state that it was on Monday. With rsync, changes have been overwritten.
ddar and Tarsnap are useful because they allow you to have a full backup of each of those days, rather than just the latest. Likewise, they package it better than the old "do a full backup and then do incrementals on top of it" way so that you don't have to restore the original and then replay all the incrementals. Now, you could just store full backups each night, but that would take an incredible amount of space. ddar and Tarsnap allow you to have the convenience of full-backup while having the data de-duplicated so that it doesn't take up too much disk space.
Rsync is more about saving bandwidth while transferring large amounts of files.
I wouldn't really call it deduped storage at all. The optimisation it does do might well be sufficient for your needs though.
ddar is generic and just stores whatever you put in. You also need to use the tools you used to format the data in to read them back out.
If you've stored files using tar, then you want `ddar xf /path/to/ddar/directory|tar t` to see the files. Or if you've also gzipped them, then `ddar xf /path/to/ddar/directory|tar zt`.
Does this help?
OP should clarify that Synctus has no issue with this project, prove he has rights to release, etc, and stick that in the license.
This feels like a copyright morass (although probably isn't).
You should probably do the short amount of paperwork required: http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html
"If you think that the employer or school might have a claim, you can resolve the problem clearly by getting a copyright disclaimer signed by a suitably authorized officer of the company or school. (Your immediate boss or a professor is usually NOT authorized to sign such a disclaimer.)"
Stick everyone's mind at ease.
Neat project (which is why I care enough to get the ducks in a row).
So my company retains copyright but licenses ddar to the public under the terms of the GNU GPL 3. Thus there is no disclaimer to sign, since my company still claims copyright.
Of course, now that ddar is released under the GPL, it will be forever (in the same manner as any other open source project).
None of this affects Synctus, which is not open source. If anyone contributes code to ddar, those contributions would not be permitted to be used in Synctus without a further licence from the contributor. I've considered this carefully and decided that this won't be a problem for me.
A disclaimer isn't needed now that it's clear in the COPYING file that TBL Ltd (the copyright holder) is the one publishing it. Thanks for clearing the air.