Blogroll

The Right Way to Configure Administrative Backup

Ran into this again this week, and figured it was worth a blog post. As any administrator will tell you, Project Server provides the option to create scheduled backups of projects, settings, resources, and custom fields. This is a great feature, but the user interface often leads to some confusion. The goal of this post is to alleviate some of that confusion.

Before we do that though, let’s first address where to actually find the Administrative Backup settings:

Project Online (Office 365) – It’s not available for end user access. That makes it simple.

Project 2013 (On-Premises) – Now found in the Manage options for the Project Web App in Central Admin’s Project Server Service Application (go ahead and send this link to your SharePoint administrator because they’ve probably locked you out – and if they haven’t, they probably should have.)

Project 2007-2010 – Project Server Server Settings.

Here’s what it looks like in the pre-release version of Project 2013:

Here’s what I typically see this set for in many clients:

Note that unless you have extenuating circumstances, the items highlighted in red probably need to be revisited:

Project Retention Policy usually should be set to something along the order of 10 or less versions. Anything higher than that would probably need to be vetted by your SQL folks and combined with the development of some database management protocols. Otherwise, your Archive database is likely to grow too large to be safely managed. I’d also point out that it’s a rare organization that truly requires more than 5 versions of the project.

Everything else should be set to Never. Why? Because Project Server doesn’t retain multiple versions of these settings. Every time you save a new version of the settings, it overwrites the old ones. This means that if you make a change to the environment, and don’t catch an error, the setting will be overwritten that night when the administrative backup is run again.

Hence, I always encourage my clients to configure these settings as follows:

While I am on the topic, a couple other common misconceptions around this screen are probably worth mentioning:

Project versions are archived daily. This means that if the project is edited multiple times in a single day, only the latest version is archived at the end of the day.

Project versions only get archived if something has changed. If the project hasn’t been edited on a given day, the new version won’t be archived. Note that you may need to revisit these settings if you have some sort of customization running that automatically updates the project file on a daily or weekly basis. These updates would trigger the archive process, and potentially could result in overwriting the last good version of the project.

When you trigger an Administrative Backup, the backup may not simply overwrite the existing elements. For example, if I backup the resource pool, then add a couple of resources accidentally, the administrative restore won’t really do all that much. The only thing the administrative restore will do is restore any resources I may have accidentally deleted. The same applies for views. (Fields on the other hand appear to be restored to a point in time, so any new fields get removed.)

As for how this should all be used? My general recommendation is to set the project retention policy to 5-10 projects, and then manually trigger the backups for everything else prior to a major change event. I also tend to use this in conjunction with the Playbooks tool, which helpfully documents all of the configurations and custom fields into an XML file that may then be opened into Excel. I’d definitely recommend including both options in your typical release checklist.