Recovering from a disaster - Non-domain server

This post is regarding recovery of a server in a Workgroup.

First perform a fresh installation of Windows server. Change the name and workgroup of the server temporarily to anything simple. Add a static IP address and DNS to the server and add the server's IP to the DNS server of the network. Add the DPM agent as it is added in backup of a workgroup server (for agent addition steps, click here)

Now install Windows Server Backup feature and run wbadmin to recover the system state.
To do this, from DPM admin console, copy the System State of the server to be recovered to a network share. From the windows server that is being recovered, run the following command to get the backup version from the share:

wbadmin get versions -backupTarget:\\192.192.1.15\Backup

This command will list the properties of the backup stored at the network location.
TO actually run the recovery, run the following command:

wbadmin start systemstaterecovery -backupTarget:\\192.192.1.15\Backup -version:06/09/2014-12:34

Now enter Y to the questions asked.

At the end, the process asks for restart of the server. DO NOT PRESS Y HERE!!!

Now from DPM admin console start the recovery of the drives (volumes). Right click the drives of the server that needs to be recovered (At the Recovery tab). Now select an alternate location or the same location based upon the setup of you environment. Select the drive in the location which will overwrite the files if selected. Proceed to restore.

After the restore finishes, at the prompt used to recover the system state press Y to RESTART the server. Now you can relax, system recovered.

Note: Please change the IP address in the above example to the IP of the location of the share where recovered data is stored!

Protecting a Non-Domain Server

1) Map the C: drive of the DPM server at the non-domain server. Provide the domain admin username and password when prompted.

net use Z: \\DPMServer\C$


2) From elevated command prompt, at Z:\Program Files\Microsoft System Center 2012 R2\DPM\DPM\ProtectionAgents\RA\4.2.1205.0\amd64,
run DPMAgentInstaller_x64.exe.
Accept the license and proceed.


3) Now from C:\Program Files\Microsoft Data Protection Manager\DPM\bin,
run:
.\SetDpmServer -dpmServerName DPM_FQDN -isNonDomainServer -userName New_User        -productionServerDnsSuffix Domain_Name

Where, DPM_FQDN:  DPM Server's FQDN
             New_User : Provide a new username that will be used by the DPM server as well.


4) Now from DPM Server's Agent Installation wizard, select Attach agent -> Computer in a Workgroup or untrusted domain.


5) Enter the non-domain server name (FQDN), the username created in step 3 and the password for the user.


6) Attach the agent.

Now you are ready to protect the server.

Note: Remember to change the DNS domain of the non-AD domain server to the one same as of DPM server.

DPM Issues I faced

1) Error: DPM does not have sufficient storage space available on the Recovery Point Volume to create new recovery  points. (ID 214)

When you get this error this means the recovery point volume may not have sufficient space for new recovery points or the attached disks may need to be refreshed from Computer Management console in DPM server. 

In my case DPM did not grow the volume automatically even though the option was selected.
Anyway, I grew the volume by 2 GB and issue resolved. I was able to run consistency check with success.

Volume Shadow Service

Windows Volume Shadow Service usually known as VSS runs as a service on Windows servers and clients.

VSS provides an interface among different components that need and create snapshots.

The components involved in snapshot creation:

1) VSS
2) Shadow requestor processes/applications (usually backup software)
3) Writer Processes
4) Shadow Providers

Shadow requestor application requests VSS that a shadow copy be created of the volume that has to be protected.

Shadow writer is a subsystem of software applications whose persistent data need to be backed-up, like, SQL server, Exchange server, etc.
The writers as soon as they receive a signal from VSS that a shadow copy needs to be created, they sync the data in memory to the disk and block all I/Os to the data to be backed-up essentially making data consistent for a brief period of time. Without this the backup data will be incomplete hence useless to apps like databases.

Shadow providers are the software or hardware that provide, i.e. create, the snapshots.
Once VSS confirms the I/O has been blocked by writers it communicates to the providers to create a shadow copy. A shadow copy can be created at the storage array side or in the OS itself.
Hardware providers ship drivers that can be installed on the OS for creating h/w shadow copies. These are created at the array side and whole LUN is copied.
Software providers employ their own way to create a copy of the volume on the OS itself.
System providers are shipped with Windows OS developed by Microsoft. These too create copy on the OS itself but are based on Copy-On-Write, i.e. they are differential copies and never full copy snapshots. (For more info on Full copy/COW snapshots, search for Snapshot technology online.)

To view shadow copies, use the command vssadmin.exe List Shadows, or vshadow.exe from VSSSDK.

Protect Data Sources using MSDPM

I used Microsoft DPM 2012 R2 to protect SQL DB and other essential infrastructure servers.

What you need to do is:

1) Install DPM agent in all the Servers and clients that need protection. These servers and clients should be in an AD environment because DPM work in that only

2) Install Windows Server Backup feature in all the machines

3) Create a protection group of the servers that require similar config else create different protection groups

4) Start the consistency check if needed.

Now you have a protected server/client which can be recovered without any issue. If you have selected BMR and System State, then you get a running server with all its data intact when recovered. If not, then you can only recover data or volumes or shares that you selected while creating the protection group.

All the information needed to protect a server is stored by DPM in its MSSQL server. The data that is backed-up is stored in disks in the storage pool which comes from iSCSI or FC LUNs that are mirrored or backed-up. But what happens when the SQL server on which DPM depends goes corrupt. You might say DPM has the backup and can be recovered. This will not happen as DPM needs SQL running else it crashes. Enter WSB.

Windows Server Backup can be used to backup the DPM database (named as DPMDB_servername). SQL already includes SQL writer when installed and when WSB is installed the SQL writer is automatically registered with WSB. Schedule atleast a daily backup to backup the DPM DB to an external iSCSI or FC LUN. This is important because a share can only hold one full backup at a time whereas a LUN, which will be formatted in NTFS, can hold a full backup as well as multiple incremental backups since the backup was scheduled. You can also backup whole SQL server if not bound by space constraints.

You need to backup DPM server too to save its registry. Create a full backup schedule from WSB installed on DPM server and choose the target disk as iSCSI or FC LUN.

If you do not want to use WSB you need to use a third party software to backup the DPMDB and DPM server.

Remember: DPM server needs iSCSI or FC LUNs which are exposed to its server. It will not create a storage pool out of locally attached disks (a DAS).