It’s beautiful when we are able to use features of DPM to backup an application as a whole (say, SharePoint or Hyper-V virtual machine), but what will happen when it is not enough to just copy files and system state (like in OCS in some cases, or Windows Server 2008 BMR Backup), or our MOSS 2007 farm configured in a way we can’t backup it at once (some SQL mirroring scenarios prevent us from doing so)?
Well… It is where scripting steps in. DPM actually lets us to run any script before backup starts or after it finishes. Is it difficult? Not at all. Is it something I can recommend to create comprehensive backup packages, or run a bunch of pre-/post-backup tasks? Not really. Let us discuss why:
1) Difficulty. Actually you have just to publish your scripts to the local drive of a protected computer and change a configuration file. Script may be of any type: shell, VBS, PowerShell or even Perl. For example, script for BMR backup on Windows 2008 may look like
rd /s /q "%BACKUP_TARGET%WindowsImageBackup%computername%"
wbadmin start backup -backuptarget:"%BACKUP_TARGET%" -allcritical -quiet
if %ERRORLEVEL% == 0 (
rem pushd "%BACKUP_TARGET%WindowsImageBackup%computername%"
rem for /f "tokens=*" %%i in (‘dir /b /s *.vhd’) do move /Y "%%i"
(the code is almost from this document)
Anyway, the most important part of the task belongs to the file ScriptingConfig.xml which usually is situated in folder c:Program FilesMicrosoft Data Protection ManagerDPMScripting
The content of the file by default is:
What we need is to add some configuration before </ScriptConfiguration>. The final file looks like that:
<?xml version="1.0" encoding="utf-8" ?>
<ScriptConfiguration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.microsoft.com/2003/dls/ScriptingConfig.xsd">
<PreBackupScript>"Path-To-Script or command line to run script"</PreBackupScript>
You see: everything looks clear in the code.
DataSourceName – the name of the data source before (or after) backing up which the script runs.
PreBackupScript – string which should run before backup
Postbackupscript – string which should run after backup
TimeOut – script timeout in minutes
Pretty simple, isn’t it?
2) Why not to do it unless you really have to? Well… It’ is hard to monitor whether the script worked fine or not. DPM console won’t tell you about it. For example, when we are speaking of Windows 2008 Bare Metal Recovery Backups we may backup any file on a file system preceding the backup with a script which makes BMR backup with WBAdmin. If the file itself is backed up successfully then your DPM server will show you a green mark even if the BMR Backup script failed. The only ways to know if everything went good are:
Make a test recovery (good idea usually, but just imagine hundreds of servers backed up every week… Impossible to check them all every week)
Make the script complex enough to catch errors in a backup and report them. Again, not really bad idea, but it is totally unmanaged and may become very costly in large environments
Use 3rd party tools.
But for some tasks it is really good stuff and you may use it.