Yes, that answers my question, more or less. To clarify, doing a diff-only backup solution without a periodic build of a consistent snapshot means that when you do need to recover the backup copy, you have to read and apply all the diffs, which is bad for recovery response. The file system analogy is like having a journaling file system with a journal with infinite space and never flushes.
On Sun, Jul 10, 2011 at 3:51 PM, Patrick Kilgore <[email protected]>wrote: > Does rdiff do any compression > > zlib compression when sending the diffs over the network. Space efficiency > is from keeping diffs and not multiple snapshots. I think I found a stat > somewhere that its > 90% more space efficient than full snapshots. > > How is the retrieval latency with that or is a full snapshot periodically >> built when the number of diffs reach a threshold? > > > Not quite sure what you're asking. Yes, restoring data from an increment > (or the mirror) takes some time, but addressing the original post (dealing > with daily backups of large sets of data), using diffs just always seemed to > be a much better solution to me, and much more efficient than compressing > the whole deal. I suppose the point is moot if that data is being generated > 100% new everyday, but really how many times is that true? > > --::-- > Patrick Kilgore > 617.910.0332 > > > > > On Sun, Jul 10, 2011 at 12:59 AM, Stan Park <[email protected]> wrote: > >> Does rdiff do any compression > > > -- Stan Park
