First, thanks Bill to provide this information. Please read my answers bellow.
Bill Thorsteinson wrote (14 Apr 2006 02:12:48 GMT) :
> Mail system was broken because /var/lib/metche used all available
> space on /var. No space was available for incoming files.
> Metche should provide some sort of quota system to prevent this.
Agreed. metche could have a configuration option (MIN_FREE_DISK_SPACE
for example) that would prevent it from saving any backups if this
minimal free disk space is not available on the partition. I'll add
a wishlist item about this to our ticketing system.
> Hours of identical backups done every 5 minutes do not provide
> useful rollback capabilities. When these backups result in functions
> like e-mail and system logging they become a liability.
metche is not supposed not save identical backups... it depends on
what you call "identical" ;) See bellow for more discussion on
this topic.
> Lack of incremental backups need not be that much of a liability,
> but should be documented. On my system the backups run 6MB each.
This will be documented.
> "metche list" after a few minutes is as follows. I have now modified
> to run hourly. That change is the only change in /etc since metche
> was installed.
>
> stable-200604132028
> stable-latest
> testing-200604132028
> testing-latest
> unstable-200604132028
> unstable-200604132035
> unstable-200604132040
> unstable-200604132045
> unstable-200604132055
> unstable-200604132105
> unstable-200604132110
> unstable-200604132115
> unstable-200604132120
> unstable-latest
>
> I believe the problem lies in creation or removeal this may be where
> the problem lies. I would suggest running a tar diff against the
> last save state before creating a new save state. Generate a new
> save state only if state has changed. Changes in mod-time only
> should be ignorable.
Before saving a new state, metche checks with "find -newer" if changes
have happened, and therefore detects a change . Using tar diff instead
would be more accurate, and prevent it from saving a new state when
only one mtime was changed, *but*... it would be too CPU-hungry to do
so every five minutes.
The fact is, we have to make a balance between disk space and
CPU usage.
We'll consider adding a configuration option allowing the user to
choose {him,her}self, even if I generally prefer to use a few dozens
megabytes on /var, or add a few "status" files to an exclude list,
than to have a CPU-hungry cronjob running every five minutes.
> I noticed that webmin status monitoring incorrecly locates some state
> information in the /etc/ directory. These files have their timestamps
> updated, but the content is stable. I have updated my conf file to
> include /etc/webmin/status.
Your guess is correct, metche saves a new state every five minutes
because of this file's mtime constantly changing. I'll add this file
to the default exclude list.
Would you file a bug against the Debian webmin package about this ?
(I'm a beginner in this area and don't know if it's to be considered
as a bug or not.)
Since metche is a quite young piece of software, it's obvious our
default exclude list has to be expanded, thanks to new users input
such as yours :)
Ciao,
--
intrigeri <[EMAIL PROTECTED]>
| gnupg key @ http://intrigeri.boum.org/intrigeri.asc
| The impossible just takes a bit longer.
pgpBrD71LiJzp.pgp
Description: PGP signature
