Project Server 2013: Check your administrative backups before you need them

I spotted this strange behavior on my own server – and after being put right by Adrian and realizing what the real issue was I thought we should share.  If you have migrated from Project Server 2010 to Project Server 2013 then you should take a look at your administrative backups – just to make sure they are working.  I took a look at my server which had half a dozen or so PWA instances all with different names (obviously) – yet when I looked at my timer jobs I saw what I initially thought were my 6 admin backups for the 6 PWA sites but all with the same name!

Timer Jobs

However, this is correct (almost) – and there is a job for each of the different items that you can back up – or 5 if you are in SharePoint Permissions mode.  One ‘gotcha’ on the Project Server permissions view – the Categories and Groups option should not be there as it isn’t actually hooked up to anything – so don’t rely on having a backup of your groups and categories…

But what threw me, was that I have 6 different PWA sites, and if I look at the Daily Schedule Backup options for one of them show that I should have 2 Project versions backed up – and each of my backup items is set to schedule! (You can ignore the category and group settings option here too – it doesn’t do anything here either…).  But nothing recent in my backup – last time was before migration…

Backup Schedule

It is not until I click save that I see the extra timer jobs for this other PWA instance (called PWS) created (visible through central Administration, Monitoring, Timer Job Definitions)

Timer Jobs with extra PWA set

So if you are using Project Server 2013 always a good idea to check that you see these timer jobs – and also go in to Administrative Restore and see if there are backups showing with dates that make sense.  Always better to find you have a good administrative backup before you need it – rather than after…

Comments (6)

  1. anonymouscommenter says:

    Hi Brian and everyone,

    the behaviour has been like that since 2007. Whenever you transport/migrate an instance, none of the timer jobs are created even though the PWA settings still claim that they are running on schedule. Hence the following addition:

    1) This is relevant for any kind of transport/upgrade/migration/refresh process.
    2) Besides backups (5-7 jobs), the OLAP, group sync, Resource Pool sync and Resource capacity timers are affected as well.
    3) Opening and saving the backup dialogue pages does not necessarily fix the issue. I have found it necessary to disable+save+enable+save the settings, or change-sync-time+save+change-sync-time-back+save.
    4) Is the issue’s impact large enough to warrant a future fix, even if only in Version 16?

    Kind regards,

  2. anonymouscommenter says:

    Hi I agree with Adrian. Known issue that you have to disable / reenable scheduled backup after transport of the data to a new system. But even worse These timer jobs some day suddenly stop working and you find out some months later when you would like
    to restore a backup. That forced me to create SQL Agent Jobs to check if scheduled backups still work… Regards Christoph

  3. JohnHolding says:

    Hi Brian, despite turning the backup schedules on and off I can’t seem to get them running. I had a look for the backup job in my Job Definitions but it simply doesn’t exist, any thoughts?

    1. Booga says:

      Hi John,

      I am currently in the same exactly situation as you were, if there is any chance to know how did you fixed it would be much appreciated.

      1. Vygantas says:

        I know this is an old article. But anyone knows how to restore these Admin.backup timer jobs?

        1. Maicco Ferreira says:

          Sires, I’m facing the same issue. The Timer Jobs simply don’t get created. I tried Disabling/Enabling but no luck. Should I open a ticket with MS?

          Thanks in advance

Skip to main content