Script-Based SharePoint 2007/2010 Site-Collection Backup - Part 3: Notifications

This is the third and final article that describe a script-based method for creating backups at the site-collection level.
At this point, if you've gotten through parts 1 and 2, you have a fairly automated site-collection backup process in place. But you will probably want to keep an eye on things to make sure everything is running smoothly. The script also provides some useful (albeit very basic) information in terms of how resources are being utilized.

You will likely be dealing with several web applications as your SharePoint infrastructures grow. I don't manage what I consider to be a huge farm, but when you also factor in development, staging, testing, etc. farms, I was running around 20 backup jobs a night. That translated into around 20 emails in my inbox every morning. This was on top of all of the other system-generated mail that I get.

To combat the self-imposed spam I turned, once again, to SharePoint. I found that email enabled discussion lists seem ideally suited as a target for storing these notifications. Since the emails themselves are HTML encoded, the final result is not bad at all.

I then created a view that only displays topics added "today". Now anyone with access to the site, has the ability to monitor the status of jobs.

Some of you are probably thinking, "That's great, Tom. But now I have to go check the site every day. I'll never remember to do that." Quite right! But if you set up an alert for the list....

What I've done is to create an alert for myself that lets me know of everything new that has been added since the last time I was alerted. I schedule this to run around 8am every day. Now I get one email (well, two emails during our transition for SP2007 to SP2010) that shows everything. I chose 8am as the time for the alert because that is late enough to grab my attention when it comes in, but early enough to hit that window in my day where I am dealing with such things.

One nice thing about the script, IMO, is that if it hits any errors they are rendered in the message body in a big, in-your-face yellow box. While the email might be quite long now, most of the time I can do a quick scan for yellow and immediately delete the email if all I see is nice, normal blandness.

If you take a more leisurely approach, you can also keep up with how large each site collection is getting, how many users have provisioned "My Sites", how long the jobs are taking (which, if you see a jump in times, can be an indicator of other problems) and so on.

So now you have a large number of emails going to a SharePoint list on a daily basis. It won't take long for things to get out of hand. Depending on your needs, cleaning this out periodically would not be a bad idea. Once again, SharePoint to the rescue. By creating a retention policy, I have set each discussion topic to expire 30 days after it has been added.


As I said in the first part of this series, this script-based method of backups is no substitute for a more complete backup solution that requires an investment in software/hardware. But it is definitely better than doing nothing. If you are on a tight budget, you could do worse than using this series as a starting point. Feel free to modify and improve!

If you find this to be useful or if you have suggestions for improving upon any aspect, please drop me a comment or give me a shout on Twitter at @tomgehrke.