Re: [rdiff-backup-users] Delete Enough To Finish

[Andrew K. Bressen]

Bob Fischer <address@hidden> writes:
> For me, this means that the backup device just isn't big enough.

this is true for me as well; I would want my purging of old stuff to
be independant of ongoing backups; if I run out of space during
a backup at all, something is wrong. But this is an environment
dependant issue; several folks have asked for the "purge enough to
complete" option, and I expect not all of them want the same
behavior as each other, let alone as you or I...


> My biggest concern with rdiff-backup is CPU time.  It's about 5X slower
> than rsync, which performs a very similar computation.  I'm running
> backups on a P-II box because I only had to pay for the disks that way. 
> Anything that increases CPU time could be impractical.
>
> Any chance rdiff-backup might be re-coded in C?  Or at least its inner
> loop in C?

rdiff-backup uses librsync, which is written in c.
rsync does not use librsync, and thus might have some better 
optimizations in it, or the delay could be python related or 
code design related.


> I think it's important to KISS with backups --- "Keep it Simple

Ah, the art of useability. 

The thing about backups is that to a greater extent than 
most other routine system functions, one size does not fit all,
so it comes down to balancing flexibility with complexity.
 
dump is simple, but not flexible, legato is flexible, but not simple. 

I use rdiff-backup because it hits a really nice medium point;
the files are as easy to get to as with dump or tarfiles, 
while space and version management is much better.

it is not just an either/or trade though; you can have a lot 
of flexibility with simple tools if they are done right;
doing it right is, of course, a bit of work.

  --akb
    who doesn't code rdiff-backup, just writes about it