none
SharePoint DPM Data Source Failing RRS feed

  • Question

  • I'm running SP2010 and DPM 2010.  I have DPM configured to backup the SP farm, but one  of the datasources is failing to backup because the data source path is too long.  The error reads:  The path to the SQL temporary folder for SQL Server 2008 database RAUSTPSW0432\WebAnalyticsServiceApplication_ReportingDB_099aa748-773b-4fa8-9cde-af688a27940d on RAUSTPSW0432.REAL.LOCAL is too long. This can cause backup or recovery jobs to fail. (ID 30163 Details: Internal error code: 0x80990D14)

    Do i need to rename the datasource to shorten the name so the job no longer fails? What is the max character name length?  Also, what are the implications of renaming the datasource and how is it done?

    Sunday, October 24, 2010 12:07 AM

Answers

  • You are both definitely hitting something that cannot be worked around by DPM.

    There is a 256 character limit.  When we start the backup we use the same location for scratch space that the log file sits in and the path referenced by DPM is not just what you see in the error, but the entire symbolic path including a GUID for the disk, and GUID for the junction point into the DPM storage pool, and then you start the server name.

    It is easy to go over the 256 character limit considering exactly what you mentioned.  SharePoint likes to append GUIDs to DB names.

    My recommendation is you work with your SharePoint admins to shorten the DB name.  This will result in having to run a consistency check and possibly even moving the farm into inactive protection and setting the PG up again to pull in the new DB name changes.

    In my SharePoint Farm i have 182 characters on one DB so it’s very conceivable how you would need to watch SharePoint appending GUIDs to DB names


    Walt W [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.
    Monday, November 8, 2010 8:44 PM
    Moderator

All replies

  • I have the same issue too. SP2010 and DPM2010.

    Before I go ask my SP admin to move his DB log locations to a shorter path (which, frankly, is a stupid request - come on Microsoft), what is the actual limitation here? How many characters? Where is this path so we can measure it?

    As I'm sure Microsoft is aware, SP likes to append GUIDs to new databases, I certainly hope the DPM team took this into account when dealing with some arbitrary path limit :)

    Help!

    Friday, October 29, 2010 1:58 PM
  • You are both definitely hitting something that cannot be worked around by DPM.

    There is a 256 character limit.  When we start the backup we use the same location for scratch space that the log file sits in and the path referenced by DPM is not just what you see in the error, but the entire symbolic path including a GUID for the disk, and GUID for the junction point into the DPM storage pool, and then you start the server name.

    It is easy to go over the 256 character limit considering exactly what you mentioned.  SharePoint likes to append GUIDs to DB names.

    My recommendation is you work with your SharePoint admins to shorten the DB name.  This will result in having to run a consistency check and possibly even moving the farm into inactive protection and setting the PG up again to pull in the new DB name changes.

    In my SharePoint Farm i have 182 characters on one DB so it’s very conceivable how you would need to watch SharePoint appending GUIDs to DB names


    Walt W [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.
    Monday, November 8, 2010 8:44 PM
    Moderator
  • Your recommendation to shorten the DB names is no small feat in an established SharePoint environment.  We implemented DPM after we had migrated to SP2010 and now we're finding significant difficulty in renaming the databases.  Is there any guidance on how that can be done in SP2010 without trashing the whole system?
    Friday, December 16, 2011 11:54 PM
  • Best practise always dictate to always name the Content DB yourself and not SharePoint do it.

    I also have DB files or the Log files in the top level folder (E:\DBFILE and G:\LOGFILES, which are both SAN drives)

    Just my $0.02.

    Regards


    Sarbjit Gill

    Saturday, March 3, 2012 3:37 AM