Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

report emails should include count of minor/major errors in Subject line #22

Closed
pm215 opened this issue Dec 29, 2014 · 2 comments
Closed

report emails should include count of minor/major errors in Subject line #22

pm215 opened this issue Dec 29, 2014 · 2 comments
Assignees
Labels
Milestone

Comments

@pm215
Copy link

@pm215 pm215 commented Dec 29, 2014

I typically only scan the subjects of my system email, so it would be useful if rsbackup's report mails could have an indication in their subject lines of whether there are issues within that need urgent investigation or not.

Suggested implementation: categorize everything in the report by severity (major/minor/info, error/warning/info or similar), and then have the subject be "Backup report ($DATE) [errors: 1 major, 2 minor]" (or perhaps "[1 error, 2 warnings]").

Example major errors:

  • always-up machine not present
  • device and host both present but rsync failed
  • host has not been backed up in $LIMIT days [configurable]

Example minor errors/warnings:

  • Unknown volume $VOL on host $H

Example info:

  • Log pruning
  • Host H skipped because not present
@ewxrjk ewxrjk added the usability label Jan 2, 2015
ewxrjk added a commit that referenced this issue Jan 3, 2015
@ewxrjk ewxrjk added this to the 2.0 milestone Jan 3, 2015
@ewxrjk ewxrjk self-assigned this Jan 3, 2015
@ewxrjk
Copy link
Owner

@ewxrjk ewxrjk commented Jan 3, 2015

Have a look at the issue22 branch: https://github.com/ewxrjk/rsbackup/tree/issue22

It's not quite the same as you ask for but it does include details of various error/warning conditions in the subject line.

always-up machines not being present is the trickiest to implement. There isn't really a sensible way to record that this was true on the last attempt to make a backup and checking each time the report is generated would be slow. The only thing I can think of is faking up a failed Backup object for at least one (volume, device) pair for that host.

However setting a low max-age for such machines should make the same condition visible in the subject line.

ewxrjk added a commit that referenced this issue Jan 3, 2015
The effect is that if an always-up host is down, the backup failures
will be recorded and available in report generation.

re #22
@ewxrjk
Copy link
Owner

@ewxrjk ewxrjk commented Jan 3, 2015

I think this is in its final (or at least, releasable) form now.

@ewxrjk ewxrjk closed this in 1e3d41a Jan 5, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants