This was announced a few days ago, but not on HN in any way:
We've been explicitly supporting git-annex on our platform since our friend Jason Scott first showed it to us and we will be contributing to the new campaign.
And just so people know without having to check the site:
> git-annex users may sign up for our full featured offsite filesystem at a rate of 10 cents per GB, per month. An annual payment is required, and the minimum account size is 50 GB. There are no usage/bandwidth charges, no signup fee, and no contract to sign.
I have an existing account, how can I move to this?
I work with a lot of smart engineers, and periodically ask them what they do for personal backup of images, video, etc. I don't think I've yet talked to someone who was satisfied with their system.
Git annex (with the assistant) brings me closer to my ideal system than I've been before: a drive at home, one in my desk drawer at work for fire-proof backups, easy automatic shuttling of data between them using my phone or USB sticks, and pluggable cloud storage if I decide I want it.
Oh, and a friendly, responsive and excellent developer behind it, developing software in a cabin, in the woods. :-)
rsync to take it to a second box in the house,
rsyncrypto to take it offsite to two separate cheap lowendbox VPSes (was originally rsync'ing a truecrypt container)
I might rearrange a couple of these steps to move the retention stage slightly further away from my main workstation, to better protect against the kind of malware that encrypts all your files and extorts a ransom
Time Machine could easily be replaced by cron and tar or some other local backup option. Other backup providers are easily found.
This is not to say anything about git-annex's usefulness or the value of supporting the developer. It just surprises me when engineers are still struggling with backups. I can kind of understand "regular folk", but that's not really the git-annex market, either.
We need integrity checking both at file-system level and at backup-solution level. If I'm not mistaken, with Time Machine on an HFS+ volume, we don't have the former, and the latter is file-based and not block-based (making it not very efficient, space-wise).
I haven't used it yet, but the git-annex assistant is trying to target that niche, with a goal of an easy-as-Dropbox user experience that hides the technical aspects of git-annex under the hood: http://git-annex.branchable.com/assistant/
It's not for snapshotting or mirroring. I used to use CarbonCopyCloner to clone my boot drive to an external USB drive every morning at ~4am, so if the internal drive on my iMac died I had an immediate bootable replacement.
(And when the internal drive DID die, I just rebooted the machine and took nearly a year to get around to replacing the internal drive!)
"Git-annex now auto-syncing photos from my android phone
to a Tor hidden SSH service I control (via
@guardianproject's Orbot) #prismbreak"
> So the whole house runs on 12 volt DC power to avoid the overhead of an inverter; my laptop is powered through a succession of cheap vehicle power adapters, and my home server runs on 5 volt power provided by a USB adapter.
I think he was also involved with the Debian GNU/Linux installer.
Yes he was (might still be, too). That where I'd first heard of Joey.
(I'm a big fan of Joey's other work, so I bet this is top notch, there just seems to be more momentum behind bittorrent-sync.)
I think they could potentially complement one another, especially if bittorrent-sync used an open protocol, so I could adapt one of the haskell bittorrent clients (which seem to make excellent use of haskell's concurrency from what I've read) to use it.
The great thing about git annex is that each clone of the repository has the entire tree structure of the repository, but by default has none of the data. So if I'm going on a trip I can just cd into the right folder on my laptop and type "git annex get ." or "git annex get Windows*.iso". Being able to tab-complete all the files in the annex even though you don't have a copy of most of them makes it very convenient.
The numcopies constraints also help enforce redundancy on the data. I could use raid to have local redundancy, but that only protects against a harddisk crashing. If I have four repositories in different physical locations and set numcopies to three, then git annex helps make sure there are always enough copies of a file (in three different physical locations), so I won't lose data even if my house burns down.
I think my biggest problem was by and large I want a versioning sync tool, and worry a lot less about managing what's on my devices.