MooseSentryTM and MicrosoftTM System Center Data Protection Manager
SCDPM Block Diagram
The
MooseSentry appliance is built around Microsoft Windows® Server 2008 R2 and System Center
Data Protection Manager 2010 (SCDPM). It is therefore a Windows Server, and, ideally, should be joined to the Active
Directory Domain that contains the servers and workstations to be protected. The next step is to
install
agent software into the servers and/or workstations to be protected. These agents
are licensed separately, and are referred to as "Data Protection Management Licenses" (DPMLs). As
shown in the drawing at right, there are three kinds of DPMLs:
- Client DPML - used to backup Windows XP, Vista, or Windows 7 workstations.
- Standard DPML - used to backup file shares and directories, and Active Directory System State on
Windows 2003 and later systems.
- Enterprise DPML - used to back up Microsoft applications, i.e., SQL, Exchange,
SharePoint, and Hyper-V, plus the ability to capture images of entire systems for "bare metal"
recovery.
After installing the DPML agents, the next step is to define backup sets, and create an initial full
"baseline copy" of the data in each set on the hard disk-based storage pool of the
MooseSentry. This
can be done in several ways, the simplest of which is to simply copy the data across to the
MooseSentry.
"Express Full" Copies
Create Backup Sets
To understand what happens next, it is necessary to understand what Microsoft refers to as an "Express
Full" copy. Assume for the moment that we are backing up one or more databases on a SQL Server. After
installing the Enterprise DPML agent on the SQL Server, we choose the databases we wish to protect
(see graphic at left).
SCDPM will then automatically discover what files make up those databases, and which physical blocks
of data on which disks make up those files. SCDPM then creates a “bit mask” – a small file with one
bit corresponding to each block that will be monitored – to track changes to those blocks. As file
write operations take place, the bit mask is used to track which blocks have been changed.
Periodically, (typically once per day), these block changes will be synchronized to the DPM server
– this is known as an Express Full operation. The DPM agent on the SQL Server will leverage Volume
Shadow Services ("VSS") to create a “snapshot” of the disk volume prior to synchronization, so that file I/O
may continue while synchronization takes place. Once synchronization is complete, the VSS snapshot
is released, and the bit mask reset to show only those blocks that were changed since the snapshot
was taken. This synchronization
may happen as frequently as every 30 minutes,
must happen at least
weekly, and typically happens nightly. The important thing to remember, though, is that
only
the blocks that have been changed are sent to the DPM server.
The DPM server itself also leverages VSS snapshots to track the differences between the original baseline copy and each
Express Full copy. So as of the first Express Full operation, there are two possible restore points:
the newly synchronized copy, and the original baseline copy, which can be reconstructed from the
snapshot that was retained. This process is repeated with every Express Full operation, and (storage
space permitting) the DPM server can retain up to 512 of these snapshots for
each backup set!
Backing Up Transactional Applications Using Transaction Logs
Day 0: Backing Up Transaction Logs
But it gets even
better. Let's continue with the SQL Server example. SQL is a
transactional application -
by which we mean it maintains transaction logs that track the changes that are made to the database. On
Day "0," after we have made our initial baseline copy, the agent will send
just the changes to
the transaction logs
every 15 minutes. (Click on graphics to view full-size.)
That means we can roll back to any 15-minute point during that day by restoring the baseline copy,
and then re-playing the transaction logs up to the desired restore point.
Day 0: Restore Operation
Day 1: A New Express Full
Now, assume that at, say, midnight, we perform another Express Full operation as we move into Day "1." As
stated earlier, the DPM server takes a VSS snapshot of the baseline copy before it is updated by the
Express Full operation. We also retain the incremental transaction log changes that occurred during
Day 0. As we move through Day 1, we continue to send the transaction log changes every 15 minutes. As
before, we can roll back to any 15-minute point during Day 1. However, since we can use the VSS
snapshot to reconstruct the original baseline copy, we can
also roll back to any 15-minute
point during Day 0.
Day 1: Backing Up Transaction Logs
Day 2: Another Express Full
Midnight rolls around, we perform another Express Full operation, and move into Day 2. Once again, the DPM
server takes a VSS snapshot of the Day 1 image before it's updated, and the process continues. As stated,
given enough capacity in its storage pool, the DPM server can retain up to 512 snapshots
with
their transaction log updates. If you do the math, you'll see that means that if we continue to take one
Express Full per day, we could roll our database back to any 15-minute point in time in the last
16 months!
Microsoft Exchange is also a transactional application, so Exchange Server backups are handled in
exactly the same way.
Express Fulls and Recovery Points
One Express Full Per Day
So far, we have assumed that we're taking one Express Full each night at midnight. It may have
occurred to you, however, that if we want to roll back to 11:45 pm, it might take a long time to play back a
full day's transaction logs for a heavily used database. The solution would be to take Express Full copies
more frequently. For example, if we take an Express Full every 4 hours, as shown in the graphic at
right, we would have far fewer transactions to play back. If we wanted to roll back to
6:45 pm, we could just restore the Express Full from 4:00 pm, and then play back only the transactions that
occurred between 4:00 and 6:45.
Multiple Express Fulls Per Day
Files, Directories, and Non-Transactional Applications
File and Folder Backup
File and directory backups are handled a little differently. As with other
kinds of data, you start by creating a replica on the DPM server of the
protected data. You then decide how often you want to synchronize the
replica with changes that have been made in the protected data - which, again,
can be as frequently as every 15 minutes. We must then decide how often we want
to establish additional recovery points (which are essentially snapshots of the
replica), and how many of those additional recovery points we want to retain. In
the example illustrated at left, a recovery point is established at 6:00 am, before the work day
begins. Additional recovery points are established every two hours until 6:00 pm. Then a final recovery
point is established at midnight to capture changes that may have taken place during the evening.
Meanwhile, changes are being synchronized every 15 minutes. A file
can be restored using the most recently synchronized copy, or it may be restored to any prior recovery
point. (If we didn't expect the data to change very often, we might choose
to perform a synchronization just prior to establishing each recovery point, in which case our only restoration options
would be the recovery points.)
For non-transactional applications, such as SharePoint, we would again decide how frequently we want
to establish recovery points, and schedule our Express Full operations accordingly, as illustrated
at right.
It's also important to understand that you don't have to know anything about Express Full operations,
transaction log changes, or recovery points in order to restore your data. You simply bring up a
restore "wizard" that will show you what recovery points are available to you. You choose the point
in time to which you want to roll back, and Data Protection Manager does the rest for you.
Non-Transactional Applications
Long-Term Archives and Off-Site Replication
Disk-to-Disk-to-Tape and Off-Site Replication
So far, we have been discussing how DPM backs up your data using its hard disk storage pool. However,
DPM also understands how to write data to tape without the need for third-party software. So you could
(if you really wanted to)
install a tape drive in your
MooseSentry appliance, or you could install an appropriate
adapter and connect it to a tape library or autoloader. But one of the reasons we designed the
MooseSentry in the first place was to get away from tape-based backups! So every
MooseSentry appliance includes a clever little software utility called "FireStreamer."
FireStreamer will
emulate a tape library. For example, you can use it to make one of the
MooseSentry's 1.5 Tb hot-plug hard disk drives look (to the DPM software) like a tape library
consisting of multiple 20 Gb "virtual tapes." In fact, FireStreamer can do this with any disk volume
that the appliance can access: a USB- or network-attached external hard drive, a volume mapped to a
file server, even a SAN volume. So when you take a closer look at the drawing at left, remember that
the "tape based backup" can be either physical tapes or virtual tapes. (We much prefer the latter.)
With proper preparation, you can even swap out hot plug drives or external drives to maintain the
same kind of "tape rotation" that you would perform with physical tapes. You might, for example,
want to maintain a monthly, quarterly, or yearly archive in addition to the restore points you are
maintaining on the primary hard disk storage pool.
Finally, the
MooseSentry can solve that nagging problem of how to get a copy of your most
critical data out of the building. Simply set up a second
MooseSentry in an off-site
location, and connect it via a VPN tunnel to your primary network. The
primary appliance will then stream data to the secondary appliance. Because, once again, we are only
sending
changes, bandwidth usage is very efficient. Moreover, you can "throttle" the bandwidth:
for example, you might limit bandwidth consumption to a relatively small percentage of the available
bandwidth during business hours, and remove the bandwidth limits after business hours.
For more information on the
MooseSentry appliance, see our
Pricing and Options page. For more information
on System Center Data Protection Manager, see
http://www.microsoft.com/dpm.
NOTE: The graphics on this page are from a
TechNet Edge video by Jason
Buffington of Microsoft Corporation.
