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

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

Re: [rdiff-backup-users] nagios plugin WAS rdiff-backup fails


From: David Kempe
Subject: Re: [rdiff-backup-users] nagios plugin WAS rdiff-backup fails
Date: Mon, 08 Aug 2005 22:43:30 +1000
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

Hi,
On this topic, I have been trying to write a nagios plugin to check the state of rdiff-backup repos.
Here is the data I have been able to glean off from analysis of backups:


#       States of backup
#
# INITIAL_IN_PROGRESS
# if repo is in initial backup phase:
# there will be 1 file_statistics, 1 mirror_metadata, 1 error_log
# and NO current mirror marker and NO session_statistics,
# AND rdiff-backup --server will be running and owned by $USER
#
# INITIAL_FAILED
# repo will be as above, but no --server running.
#
#
# SUBSEQUENT_IN_PROGRESS
# if repo is in subsequent backup phase, there will be 2 current mirror markers,
# 1 for the last completed backup and 1 for the backup in progress.
# There will be 1 error_log for in progress backup
# and 1 for each attempted backup
# There will be 1 mirror_metadata for in progress backup
# and 1 for each attempted backup
# there will be no session_statistics for backup in progress, but there
# will be file_statistics. (perhaps compare dates)
# AND to check for backup in progress is to check for
# rdiff-backup --server owned by $USERNAME in process list otherwise,
# backup repo is in state SUBSEQUENT_FAILED
#
# SUBSEQUENT_FAILED
# as discussed above - no rdiff-backup --server process and, at least 1 extra # error_log and mirror_metadata then session_statistics, and two current_mirror
# markers
#
# SUBSEQUENT_SUCCEEDED
# 1 current_mirror, matching the sessions_statistics date.

Let me know if thats correct.
The biggest problem with simply checking the process list is that the rdiff-backup --server might not match the repo in question.

eventually, I hope to have a complete plugin to check the overall health of the repo - including healthy size differences, times expected to finish etc. Much better than reading bloody backup logs every day.

Ben, any suggestions to make this task easier would be much appreciated.

thanks

dave




reply via email to

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