rdiff-backup-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [rdiff-backup-users] 0.13.6 on macosx client


From: Hunter Matthews
Subject: Re: [rdiff-backup-users] 0.13.6 on macosx client
Date: Fri, 13 May 2005 10:52:16 -0400

On Fri, 2005-05-13 at 00:10, Ben Escoto wrote:
> >>>>> Hunter Matthews <address@hidden>
> >>>>> wrote the following on Tue, 03 May 2005 14:20:31 -0400
> 
> > Osx backups seem to work well, but repeated backups show a disturbing 
> > trend - 
> > The mirror metadata file seems to be a fully copy each time.
> > So for a backup that had almost no changes, 
> ...
> > I still get a 20MB mirror increase, due to what appears to be a full
> > copy of the metadata.
> ...
> > Is there anyway to limit this to JUST the needed metadata changes?
> > I can see several machines having MOST of their backup disk space tied
> > up in meta snapshots.
> 
> No, there is currently no way to do what you want.  It is a sensible
> idea, and the filenaming format (e.g. .snapshot vs .diff) was designed
> so this functionality could be added, but it hasn't yet.
> 
> But I think for the vast majority of situations the threat of a
> majority of disk space being consumed by meta snapshots seems remote.
> The metadata is compressed and takes up only a few bytes per file, so
> if the mirror_metadata file is 20MB the source data is probably 20GB+.

185MB.
Which is why I was concerned - I have a 80GB machine to backup.

Which probably means I just need to try it and see how it goes.


> Then it would take about 1000 sessions before the metadata overtook
> the the actual data, even the source remained complete unchanged for
> all 1000 sessions.
-- 
Hunter Matthews                          Unix / Network Administrator
Office: BioScience 145/244               Duke Univ. Biology Department
Key: F0F88438 / FFB5 34C0 B350 99A4 BB02  9779 A5DB 8B09 F0F8 8438
Never take candy from strangers. Especially on the internet.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]