Share via

Reminder: Use a UNC path as the destination for the Backup-SPFarm cmdlet

  • Article

As I was preparing to install the SharePoint 2013 December ‘14 Cumulative Update, I decided to take a full SharePoint farm backup, using PowerShell- of course.

The Problem

In a somewhat boneheaded move I was trying to use a local directory the destination to back up my SharePoint 2013 Lab farm:

PS C:\Users\alexsmith.SPSEARCHDEMO> Backup-SPFarm -Directory D:\SPFarm-backup\ -BackupMethod Full –Verbose

This resulting in plenty of errors and warnings in the backup log:

[2/6/2014 4:54:51 PM] Finished with 54 warnings.
[2/6/2014 4:54:51 PM] Finished with 9 errors.
[2/6/2014 4:54:51 PM] FatalError: Backup failed for Object User Profile Service Application_SocialDB_bfef37f1886f4d0f847d518ad8320c49 failed in event OnBackup. For more information, see the spbackup.log or sprestore.log file located in the backup directory.
[2/6/2014 4:54:51 PM] -------------------------------------------------

Further investigation of the log file (D:\SPFarm-backup\spbr0000\spbackup.log) showed:

[2/6/2014 4:53:26 PM] FatalError: Object User Profile Service Application_SocialDB_bfef37f1886f4d0f847d518ad8320c49 failed in event OnBackup. For more information, see the spbackup.log or sprestore.log file located in the backup directory.
SqlException: Cannot open backup device 'D:\SPFarm-backup\spbr0000\00000081.bak'. Operating system error 3(The system cannot find the path specified.).

First I checked the permissions on the destination directory, and made sure that my admin account had db_owner permissions on the databases, etc.  Then I remembered this bit of information from the TechNet doc for the Backup-SPFarm cmdlet:

“…if SQL Server 2008 and SharePoint 2010 Products are installed on multiple computers or if you have multiple servers running SharePoint 2010 Products, you must use Universal Naming Convention (UNC) share paths so that the SQL Server database and search components are written to the same location; for example, \\computer_name\volume\Backup).”

My lab farm has separate SQL and SharePoint servers, and so the SQL server was trying to write to it’s local D: drive where that directory didn’t exist!

The Solution

The fix was to create a network share accessible to the SharePoint and SQL servers. You shouldn't use the administrative shares e.g. \\servername\d$, because the permissions won't be correct.
Permissions on the share and the underlying directory should include “Full Control” for the account you run the backup from, plus the SQL service account. I’m using a Managed Service Account for SQL, but it worked the same as a normal user account.

Once my share was set up, I adjusted my the cmdlet to use the UNC path for the share, and the backup completed successfully:

PS C:\Users\alexsmith.SPSEARCHDEMO> Backup-SPFarm -Directory "\\spsearchwfe01\SPFarm-backup" -BackupMethod Full –Verbose

...

Finished with 0 warnings.
Finished with 0 errors.
Backup completed successfully.
-------------------------------------------------

Happy backups!

Comments

  • Anonymous
    August 31, 2015
    Thank you!
  • Anonymous
    February 04, 2016
    Fantastic, solved the problem. Added full control for the SQL Service account to the backup share and directory.
    Thanks / Mikael