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

[Bob Fischer]

> The most obvious concern is that one overly large file would cause
> all the backups to be pared down to the minimum retain value and
> then fail anyway...

For me, this means that the backup device just isn't big enough.

I think it's important to KISS with backups --- "Keep it Simple
Stupid".  I would want a simple set of rules I can easily analyze, so I
know that the right stuff is being backed up.  If I have to get a bigger
HDD for backups, so be it.

Except for database dump files, most large files on home PC's today are
multimedia --- music and photos.  These files basically do not change,
they are write-once read-many.  For myself at least, the set of files
than change is miniscule compared to my modest (by today's standards)
160Gb hard drive.

> It has just occurred to me that rdiff-backup may not have to 
> in fact perform the backup in order to figure out how much space
> it would require...

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?
 
-- Bob