Jump to content
KKerezman

CrashPlan Job Log Reporter

Recommended Posts

Posted (edited)

I needed a way to pull the list of "failed" files from the gigantic CrashPlan client logs, and to do so without downloading several gigs of logs locally and eyeballing it myself. So, coupled with the "opportunity" to learn more about how to wrangle things in PowerShell, I have created the attached TESTING script. In a nutshell, it performs the following steps:

  1. Checks if the backup_files.log.0 exists in the CP log directory under ProgramData and emails the tech who ran the script a DIR of the directory if it's missing (then bails).
  2. Makes a "today's date" variable in a format matching what's in the log.
  3. Parses log looking for lines with today's date, twice. Once to pull the timestamp of the latest job run, once to pull the number of failed files in that job.
  4. Generates a "working" (just the desired date/time lines) copy of the log file in %tempdir% and parses that for the lines with the actual failed files. (Upon later runs, the working file is checked for and deleted first.)
  5. Emails the resulting info to the tech who ran the script.

Note that if you do play with this, you should obviously season it to taste. I merely figured somebody somewhere might get some value out of the day I have just spent chasing down syntax errors...

CrashPlan Job Log Reporter (TESTING).xml

Edited by KKerezman

Share this post


Link to post
Share on other sites

Fantastic! I've been looking for something along these lines for a while now - thank you for sharing.

Share this post


Link to post
Share on other sites

You're most welcome!

After a few weeks with this in production (a modified copy of it is run every few hours against online CrashPlan-installed agents and emails Backup Radar in their "generic" format), I should note that if CP is installed "per user" into the AppData hierarchy this script basically won't work. (It will do the thing in the first # point above, bailing when it doesn't find the log file.) You're free to add in some "find where it's installed" logic if you want, but we just decided to reinstall those endpoints "properly" instead. We're fussbudgets that way.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×