Re: [rdiff-backup-users] Suggest feature --no-archive-if-no-changes

[Andrew Ferguson]

On Jan 18, 2009, at 12:48 AM, Dominic wrote:
> As I understand it, every rdiff-backup run produces a record in the  
> rdiff-backup repository. Many of my archives have source data which  
> changes infrequently or in a few cases not at all, but rdiff-backup  
> is run daily just in case. This means an accumulation of backup  
> records which although they probably take up very little disk space,  
> can greatly complicate understanding and retrieving data at a later  
> date. For instance, archfs loads more and more slowly as the number  
> of backup runs in the archive increases, and it creates an entry in  
> the virtual directory structure for every backup of every file  
> regardless of whether the file had changed or not.
>
> I think it would be good if rdiff-backup had a switch something like  
> --no-archive-if-no-changes which would mean that if there were no  
> changes in the source data then nothing would be changed in the  
> archive at all, and there would be no record of that rdiff-backup run.


Dominic,

When very little has changed between runs, the files which rdiff- 
backup writes use very little disk space, so I don't see your feature  
request as that important for rdiff-backup. It would be strange to  
look at a backup repository and see that the most recent increment  
file was from two weeks ago, but to believe that rdiff-backup should  
be running every night, or something like that.

Really, I think your problem is simply that some tools for looking at  
the repository (eg, archfs) are not optimized for the case of many  
trivial increments.

Although I don't know how easy or hard such a feature would be to  
implement in rdiff-backup, I think what you really want to do is fix  
tools like archfs.

I believe it's better for rdiff-backup to continue presenting lots of  
data, and then to have tools which organize or pare down that data,  
rather than to work out ways to suppress rdiff-backup from generating  
data in the first place.


Andrew


PS -- As always, I am happy to evaluate patches. :-)