Inactive backup warning!

[handyguysoftware]

Inactive backup warning!

[HandyGuySoftware]

...If they bother to read them completely

Some things I can't program around ;-)

Once a backup set (src/dest pair) has been recorded in the database, dR will always look for emails from that backup set. If it doesn't see them when the report is run (because you haven't run a manual backup or something is preventing the backups from running/completing) you will get the "last seen x days ago" message in the report. I'm not sure where else/how to process and produce that warning. What did you have in mind?

[dcurrey]

I was thinking of a separate warning email similar to the way warnoncollect works. But also send independent emails on report.

Just an extra warning that would stand out from the main report. This is similar to what crashplan sends me if backups haven't been done in 5 days.

To execute say have command line option -n

 if globs.opts['nobackupwarn']:
        globs.db.create_no_backup_warn()

create_no_backup_warn() would basically be the sql statement to check for inactive backups create the email and pass it to sendemail()

Here is the result

[HandyGuySoftware]

OK, I get it.

Once upon a time I had the idea of assigning "owners" to each backup set and put their email in the [src-dest] sections of the .rc file. I run the backups on my kids' laptops and occasionally they forget to leave the machine running long enough for the backup to run. The idea was that if a backupset from their machine hasn't been seen for a certain number of days it would send them a reminder email. That's actually where the idea for the separate [src-dest] sections in the .rc file came from, I just repurposed it for the date/time format stuff and never got around to implementing the nag email. This sounds a lot like that.

I was going to start working on the email purge function (issue #42 ) this weekend. Once I get through that I'll take a closer look at this and see what can be done.

Keep 'em coming!

[dcurrey]

Nice!

You shouldn't have to much trouble, I have some beta code that seems to function properly on my test server. Only dealing with 1 backupset and about 10 emails but everything seems to work correctly.

Let me know if you want to see any of it.

[HandyGuySoftware]

Sure. Can you post any code/snippets you have?

[dcurrey]

Added code to pull request!
Edit: Hope I did that right. If not I am sorry.

I can repost it here if needed.

[HandyGuySoftware]

Added this feature today. Took a look through your code but tried a different approach. Rather than adding fields to the DB I just used the data already available as the program was running. Put operating parameters in the .rc file instead of the DB as that makes it easier for the user to configure. Configurable on a whole-program or per-srcdest basis. Check out the readme.md file at the end of the [report] section and the [source -destination] for available options. Let me know what you think.

[dcurrey]

Sounds good with everything being in the rc file.

You might want to double check on the collect option. If I remember correctly I added what became the lastBackupstamp for a reason. Originally set this up on version I think was 2.01 when you used the lastdate, lasttime combo. But I think its needed on check only, otherwise I think it matches the lastTimestamp

Unfortunately I don't have time today to test the current code. :(

[HandyGuySoftware]

No worries, whenever you get a chance.

[HandyGuySoftware]

Just re-reading your last comment. Should the inactive check be performed if only running in collect mode (-c)? Right now it runs as part of the reporting routine, i.e. not in -c mode. If it needs to run under -c it's a small change in the existing code, but doable. Should still be able to do it without adding fields to the db, but I'll need to look at that. Just checking to clarify.

[dcurrey]

Yea, that is the idea to do the addition check during the -c run since you don't see any report data. Although a second warning email during normal report mode isn't a bad thing.

When checking it with normal report mode could the line that reads "No new activity. Last activity on 2017-11-17 at 20:00:16 (30 days ago)" be changed to red when the nobackupwarn is hit? Just something to make it pop out like the errors and warnings do?.

[HandyGuySoftware]

OK, getting clearer now. I can just move the checking routine out of report.py and into the main routine in dupReport.py. It'll take a few more DB queries, but still doable (in my head, at least :-) There should also be a way to specify when if you want it run (-c, -t, or always).

Adding colors are easy. I'll add that to the next update.

[HandyGuySoftware]

Added in latest Beta upload. nobackup warning can be configured on a global or a per-backupset basis. Warning email receiver can be set globally or per backup.

Check out description for nobackupwarn and nbwsubject in [report] section and [source-destination] sections, as well as -w option.

Let me know what you think. (And what doesn't work ;-)

[dcurrey]

So far looks good.

The only think I have found that if you run "dupReport.py -i -c" Don't ask :) You get the following error.

Traceback (most recent call last):
  File "./dupReport.py", line 245, in <module>
    sendNoBackupWarnings()
  File "./dupReport.py", line 111, in sendNoBackupWarnings
    diff = drdatetime.daysSince(latestTimeStamp)
  File "/home/dcurrey/dupReport-2.1.0_Beta/drdatetime.py", line 178, in daysSince
    then = datetime.datetime.fromtimestamp(tsIn)
TypeError: a float is required

I am not sure why you would need to start with this combination so a workaround may not be needed. It was just an accident I hit it.

Just wanted to give you a heads up in case it pops up under some other weird circumstance.

[HandyGuySoftware]

OK, -i -c now works & fix uploaded.

Just for giggles I tested if "-i -t" (an even weirder combination) works. It does.

[HandyGuySoftware]

Fixed in 2.1.0 Beta