SQL non-system database backup using Powershell

Traditionally most People have been automating database backups in Microsoft SQL server using TransactSQL, and then using osql to execute the code through Windows Task Scheduler. With the advent of MSSQL 2012, using Powershell to automate SQL related taks has suddenly become a lot easier.

This script selects only user databases though, ignoring system databases and leaves you with only what should be important to you.

As a part of a migration at a client, I was given the task of creating an efficient backup strategy with minimal effort. Using TransactSQL would definitely solve the task, but for future reference, I always try to use Powershell when applicable.

So how does the script work? Well, first we collect paths and dates necessary to perform the backup and name the file for the backup set. The backup file is tagged with the week number and the script is meant to create a backup set every week.

Next we create two Functions. The first creates a full backup, the second will add incremental backups to the backup set file created by the first function. I.e., the second will be pointless if the first has not run.

Last, we choose which of the previously created functions to run. This is also where you choose when to create the full backup set. Simply change the weekday in the script. Mind your spelling though, it needs to be accurate.

So this is all nice and dandy. It’ll keep churning out backup sets every week, filling up your storage SAN, local hard drive, cloud storage or what ever storage you choose to add the backup set to. So what can we do to clean it up?

Well, keep in mind that all backup sets are tagged with the week number in the file name. This makes it easy to choose which backup set to restore, but it also makes it easy to choose which to delete. Simply {$CurrentWeek – 2}. Here a script that does exactly that:

Please feel free to leave your comments if you have and questions regarding this solution, and I’d love to hear from anyone who uses this fully or partially 🙂

Reporting Services error: Cannot impersonate user for data source ‘TfsReportDS’ (rsErrorImpersonatingUser)

After moving a reporting services database from SQL server 2008r2 to 2012, we had a problem running reports in TFS.

The error was:

An error has occurred during report processing. (rsProcessingAborted)
Cannot impersonate user for data source ‘TfsReportDS’. (rsErrorImpersonatingUser)
Log on failed. Ensure the user name and password are correct. (rsLogonFailed)
For more information about this error navigate to the report server on the local server machine, or enable remote errors

Add a local policy on the SQL server allowing the Report Services User (Reader Account in TFS Admin console) to log on locally or add it to a group which already has these rights.

log on locally