So we’ve made it to part three! Still in one piece and still intrigued, mystified and confused at how could such an important piece be left out? Well, like I said in the last part there is light at the end of the tunnel and we will get there slowly but surely.
You might be sitting back in your lounge chair, or glued to your monitor with blood shot eyes if you read part one and two back to back, and asking yourself what’s left? Before we dive deeper into the abyss only to swim our way to the top, we’ll take a quick recap.
In part two we talked about automation, configuration, and load balancing. All equally important pieces that tie in together. Without one you can’t have the other! You create automation so that your configuration is simplified. You load balance your configuration. And finally wrap that all up with more automation handle the load balancing of your configuration. You see, if like the cycle of life or the a vicious cycle of reality, but no matter how you slice it all equally important.
So again we must sit back and ask the question we asked in part two; what could possibly be left? How could this thriller mystery turned drama get worse? Like I said earlier, let’s take a deep breath and dive into the abyss. But keep your gloves on, because this is the final chapter, the murder mystery chapter!
Tape Management and Long Term Retention
I did warn you, this is going to be a murder mystery! Where do we start when the topic of tape backups comes up? Why would I even bring up tape backups in 2013? Does anyone still care for tape backups? Believe it or not the simple answer is yes. Tapes are still an affordable way to get your backups off site. While DPM supports a secondary off site server to replicate to, many businesses can afford that extra costs. Even the Azure component introduced in DPM SP1 might prove too expensive or not a feasible option for security or other legal reasons. So tapes are still the way to go, so let’s explore…
If you have one DPM server and one tape library or drive then no issues there. There mutually attached and none of the aspects we’ve discussed in parts one or two apply. You don’t need centralization, automation, load balancing or any of that fancy stuff. But what if you have two DPM servers, then what do you do? We’ll leave the technical details for another post, but what about the tape catalog? Now you have to maintain two catalogs and keep a record of what tapes are part of what catalog. What if one of the DPM servers went down and you didn’t have a backup of the catalog, how would you know which tapes are part of which datasource. And if you were backing up, you would still have a backup per DPM server to maintain.
Another aspect we need to look at is how do you know when tapes are ready to go offsite? You have to login to each DPM server and make note of the tapes then eject them from that DPM server. Then we look at the flipside, when a tape comes in from off site storage, you now have to remember which slot and make sure you pull it into the right DPM server.
These problems might not seem so grand and you might think I’m going over the top here. But for a moment step back and start multiplying this problem across four DPM servers. Now do ten, then thirty, and you can quickly see how tape management can become a nightmare.
Finally, let’s look at long term tape retention. What if you have different retention periods for different clients in your environment? You would have to keep the tapes and the master catalog around for that retention period so you can restore the data five years ago. But now you’re maintaining several catalogs each with possibly different retention periods. Wouldn’t it be easier to have one catalog that’s backed up to tape and sent offsite with the other tapes? Then you would just go to that one tape, restore the catalog, and recall your tapes from there.
Just think of yourself on the floor with magnetic tape strung all around you trapping you in the data center! See, I said this was a murder mystery! No one will ever know that it was tape management that killed the backup admin!
Workflow
Now we start to slowly swim out of the abyss towards the light. We’ve left the murky waters and moving on to discuss lighter topics like workflow. I’ll admit, this one is just a matter of training the admins to do something a certain way. However, the point here to take home is not the steps in the workflow but the inefficiency because of the lack of centralization.
When you need to do something across DPM servers, you have to follow the same steps over and over again for each DPM server. We touched on this when discussing automation, but here we are talking about simple things like finding what DPM server the client is attached to or managing policies.
Moving the workflow for these common steps to a central server would save each admin hours upon hours of repetitive work and give them one place to start all their tasks from. Keep this in mind as we go through our final topic before reaching the light at the end of the tunnel.
Data Retention Periods and Legal Requirements
Well that’s a mouthful! For the sake of this article coming to a close we will keep this one short and sweet and stay out of the even murkier waters of legal. So let’s take a common example. The legal department has stated that a certain dataset can only be retained for a specified period of time and they need proof. This would be an easy task if we had one or two DPM servers as we could email the legal department the recovery point status report from the DPM servers. But what if you’re protecting other data that doesn’t apply to their policy? The report will contain everything and way more than what legal needs to ensure requirements are met.
Another scenario might be where the DPM admin is given a list protected clients and asked to audit those and come back to legal with the oldest recovery points and frequency of backups. Again, this would be easy if you had all the clients on one DPM server. But what if you couldn’t do that for a simple reason that the number of clients would exceed any of DPMs supported limitations, so you had to spread them out. Along the lines of the workflow problem mentioned before, you would find yourself doing the same thing over and over while asking legal to hold on. And what if they can’t hold on because of an imposed legal mandate?
A final point to bring up is data availability. There are laws out there that determine the number of times a specific piece of data can exist. So trying to explain to legal that you have multiple backup servers would translate to them that you are backing up the same thing multiple times. What if they believed you, but asked you to prove that a client was only being backed up by one DPM server? You would have to take the built reports out of DPM, get a corkboard, lot’s of pins, red string, and start connecting the dots.
See, we made it back to the murder mystery reference with ease! If only centralization was that easy!
Summary
Hopefully you’re still reading this and not thinking from that last line that DPM is as easy as murder! Or that centralization is equivalent to murder! Like I promised there is light at the end of the tunnel and we’ve made it! We’ve lost a few good soldiers and possibly some minions in the process. So to those of you still here, give yourself a pat on the backup!
Rather than recap everything we just went through, because that would amount to torture, let’s talk about this light at the end of the tunnel. Despite all the lack of centralization built into DPM, we do have three tools at our disposal when breaking through to the light.
SCOM
System Center Operations Manager! Since the new licensing model includes all the System Center products, Operations manager, aka SCOM, is an excellent tool and kudos goes to the DPM product team for putting together a SCOM management pack. While this is not the perfect solution and definitely does have it’s limitations it’s a glimpse into what can one day be the holy grail or utopian future of centralized backups. But till then a little more magic sauce is needed and SCOM just scratches the surface of what is possible.
We won’t go into the details of what’s in the management pack, just know that it’s out there and go find it! Google it, BING it, call the mailman, whatever you do, no DPM adventure or deployment is complete without a read into this management packs capabilities.
PowerShell
For those willing to stick it to Microsoft and tired of waiting for the product team to find a solution there’s always the DPM PowerShell module. With it’s set of cmdlets you could theoretically replace the GUI and do everything from command line and scripts. You can do everything from collecting data to configuration to starting jobs, the skies the limit. Of course, that’s assuming you don’t live in Redmond or Seattle where it’s overcast most of the year!
SQL
For those really adventurous who like to live on the edge and can maintain their own tools and reverse engineer tools, this is the holy grail! Everything that is in the GUI or it’s backend, is in the DPM SQL database, the DPMDB. Although the schema is not published, any clever DBA and DPM admin should be able to sit together and roughly figure out the schema. With that power at hand and some clever PowerShell scripting with the SQL PowerShell module you could collect any data you want from all your DPM servers or take action on any DPM server.
Final Words
Think of these next lines as the cheesy voiceover at the end of your favorite medical drama series or any other show…
We’ve covered a great detail of pain points and suffered a great deal. But in the end we need to keep in mind that DPM is just another backup product on the market. And just like any other product out there it’s not without it’s flaws. Centralization is just one of them but not a reason to discard DPM. With some duct tape, zip ties, bandages, and some clever ingenuity we are able to workaround those flaws.
Flaws are flaws, but we should keep in mind that DPM is just a puppy at just over six years old and still has a great deal of maturing to do. I’m confident that Microsoft will put there foot down and bring DPM to an enterprise class status. They will hire a team, buy out an innovator, or just set the copy machines to high, but they will do it.
So thanks again for sticking through it all and I hope you’ve enjoyed the series. Till next time we meet…
“Faithless is he that says farewell when the road darkens.”
J. R. R. Tolkien — British scholar & fantasy novelist (1892 – 1973)
