Hell of a year

It's been a hell of a year. Personal and professional circumstances have converged and prevented me from working on peerbackup.

What can I say? It's still vaporware.

I've discovered recently a great project from which I intend to borrow code and ideas. Its name is Camlistore and some of the concepts it uses are going to be extremely useful in peerbackup.

Next step: store metadata using sqlite and try make a backup and restore it.

Lots of ideas and so little time.

Quick and dirty tests

I'm starting to test hash (sha256 and adler32)  and compression (gzip and lzma) algorithms. Right now the program breaks its executable file into pieces, and writes them compressed with gzip using their sha256 hash as a name.
Not much, but a beginning.
Now I'm thinking about how metadata should be stored, how to test for new files and modifications inside a file already backed up.
Next, I'll try to back a file up storing its metadata and restore it in other directory.
In order to detect changes in a file already backed up I need a rolling checksum algorithm. I've found an implementation and asked for permission for using it, giving proper credit, of course.

Lowering expectations

It's time to admit that peerbackup will never be anything else than vaporware blogware if I don't lower my expectations about it (and start producing some actual code).

The best way of getting a first version done might be simplifying its network requirements. In theory it would be great to have a truly decentralized and distributed backup system, but in real life it might work as well a reduced version of it.

To put it bluntly: node management won't be automatic. A node will add another peer manually. The number of nodes will remain low and known. I'm thinking about an scenario where a group of people (friends, family, co-workers) agree to set a backup network. 

It makes the project infinitely more boring. No real p2p, no real anonymity. 

What remains then? Once the network is set up, a distributed encrypted backup. It will be more similar to an array of disks (or a RAID) than to a bittorrent network.

It may have some benefits, though. First of all, you should be able to tell when a node is down and warn its propietary. It also solves the problem of trusting unknown nodes. You know where your data is. 

But truth to be told, despite some potential benefit, the decision is to sacrifice functionality in order to get anything at all done. If it works and I get it done, there's always the possibility of a better second version.

State of the project

Short version: Stalled.

I'm still interested in peerbackup. Actually, more than ever before. But it seems that I can't manage to get time for it. I hope that I'll pass all my exams in june so that I'll have the whole summer for reading documentation and coding. Hopes and wishes by now. Let's see how it turns out.