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

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

Re: [rdiff-backup-users] Limit creation of log and sesssion data


From: Maarten Bezemer
Subject: Re: [rdiff-backup-users] Limit creation of log and sesssion data
Date: Fri, 16 Dec 2005 00:56:45 +0100 (CET)

On Thu, 15 Dec 2005, Ben Escoto wrote:

> >>>>> "Hans F. Nordhaug" <address@hidden>
> >>>>> wrote the following on Tue, 13 Dec 2005 09:47:15 +0100
> >
> > However, other (easier) approaches come to mind:
> > 1) Never, ever gzip an empty file. All my error_log files have size
> >    108 in stead of 0 zero because they are compressed.
> > 2) Don't write any logs or session data if there are no changes.
> >    (Make it an option or the default.) This would help a lot!
> 
> Yes, I think the error_log file could be skipped if there are no
> errors.  Anyone see any drawbacks to this?

Which filesystems allocate disk space for an empty file? AFAIK, ext2 only
uses an entry in the 'directory', but no blocks for contents. So, by just
not gzipping an empty file, it will probably take less space already.

I currently use the error_log file as a means to check the result of the
rdiff-backup run. Attaching the contents of `ls error_log*|tail -n1` to a
cron email is quite easy, but would give strange results when no error_log
file was created in the last run.
While my crude error_log selection line could be adjusted to use e.g. the
timestamp from the current_mirror file, I really prefer to have all log
and session files, even if they're empty.

If deleting (or not creating) file_statistics files is possible, and
mirror_metadata files are managed incrementally, I doubt there will be
much overhead in disk usage. And a few megabytes is a small price to pay
for long-term "incremental restores".

A switch for not writing session_statistics files might be useful, but
adding an 'rm rdiff-backup-data/session_statistics*' in the script calling
rdiff-backup shouldn't be too hard either.


-- 
Maarten





reply via email to

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