Is it acceptable for the $file in a returned PositionedChunk to be some file outside of the backup source path? I ask because I have a bunch of files that need special treatment to copy them safely -- databases, for example -- and with this "smart chunking" it could perhaps do the "hot copy" step into a temporary directory and use that file in place of the original file.

(I'd also like to do some "smart chunking" for SQLite databases and the like to avoid re-uploading the entire database whenever something changes, but that's not really bothering me enough to do it yet since my SQLite databases are small.)

Perverse, but that could work I think.

It's a shame you can't do some kind of smart delta. But that would require having a local copy of the latest backed-up version...

One of us is confused. And I think you. :)

I don't need the latest backed-up version. If the file doesn't exist already on the remote data store, I cut it into chunks (smartly) and see which of those chunks already exist on the remote store. In the retagging case, the 5M+ chunk is already there (likely from a different offset, but the remote store knows nothing of offsets or file lengths, just digests... it's content-addressable), and then I upload the changed chunks (the ID3 tag metadata).

So it _is_ a smart delta, in a sense.

Before I could already rearrange all my files and backups would still be instant. Now I can even change parts of files and only the changed parts (regardless of offset in file) need to be backed up.

With mart's work, we can also now mount any backup, so we essentially have a snapshotting filesystem. If I don't touch my files for a week, but I do daily snapshots, those snapshots are free, re-using the same chunks. The storage cost is only proportional to changes.

*laugh* No, neither of us is confused. With the latest backed-up version, you could simply store the bsdiff of the new version against the old one, effectively getting the smart chunking you talk about.

(Note that re-using chunks is a design tradeoff -- if a chunk gets corrupted, then all of your backups that use that chunk are corrupted.)

Yeah, but that's a pretty minor problem: when asking the remote store if it has a chunk, it can double-check it to see if its bytes still match its digest. Or it can be done in the background, with two copies of each unique chunk stored, and then the corrupt one replaced with the good one. etc, etc.

Mostly I'm optimizing for not having to think (backup daily, automated!) and upstream bandwidth sucking. Everything else can be engineered away.

Hello. Just wanted to let you know that I added you. I see that you scuba dive and so do I. Just want to read up on your dives.

If you want me to unfriend you, pleas let me know!

=)

So, I don't think this is the best place to ask this, but I don't know where I should be asking, so here goes:

I started using Brackup to backup to an external on Vista. It works (with some minor hacking) for non-encrypted targets, but if I add an encryption key it writes one chunk then just exits with no error message. Any ideas at all as to what could be happening?

I also get this error (warning?) every time I run brackup, but it doesn't seem to affect anything:

"Use of uninitialized value in concatenation (.) or string at C:/Users/Caleb/Programs/Brackup/lib/Brackup/Target.pm line 17"

Thanks!

I'd ask the mailing list. Somebody there (mart?) would know the answer for Windows. I sure don't.

http://lists.danga.com/mailman/listinfo/brackup

There's no brackup tag on this entry...