Part one of this four-part article explains that although the NTBACKUP program lacks many of the features typically...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
found in third-party backup applications, you can develop a script that allows NTBACKUP to leverage the power of the Removable Storage Manager (RSM) and interact with tape libraries in the same way it works with commercial backup applications. Here, in part two, I will show you the first steps in creating such a script and how to create a batch file that can use the RSM in conjunction with NTBACKUP.
One of the first techniques I want to show you is a method for determining a tape's Globally Unique Identifier (GUID). Part one of this article discussed the concept of preparing a tape for use.
When NTBACKUP prepares a tape, it assigns the tape a GUID. This is important because NTBACKUP has a nasty habit of changing a tape's name from one day to the next, but the tape's GUID will remain consistent over the life of the tape (assuming you don't reformat the tape).
I'll be up front with you and tell you that neither the tape's name nor the tape's GUID are any fun to incorporate into a script. By default, NTBACKUP assigns tapes names such as "Backup Set Created 12/13/2005 at 12:15 PM." In contrast, a GUID is a hexadecimal number consisting of eight characters, a dash, four characters, a dash, four more characters, a dash, another four characters, a dash, and then 12 characters. Basically, it looks like this: b456c789-abcd-1234-a1b4-ab56cd89ef56.
Obviously, you don't want to have to type a GUID every time you want your script to perform an operation against a tape. The good news is that, in many cases, you don't have to. You can simply write a bit of code that will tell the tape drive to read the currently inserted tape and return its GUID. Before I show you how to determine a tape's GUID, I want to remind you that the title of this series of articles is "Automating complex backups." Like any complicated task, the process becomes much easier if you break it down into smaller, more manageable jobs. Reading a tape's GUID won't do anything for you by itself, but it is a key step in achieving our ultimate goal.
First steps: Know how to read a map and build a GUID bridge
The first thing you need to know about the process for reading a tape's GUID is that you have to tell Windows which tape drive the tape is currently inserted into. Just as each tape has its own GUID, each tape drive attached to your system also has a unique GUID.
As you may have guessed, your script will have to reference each tape drive by its GUID. Unfortunately, there is no way to have your script dynamically read a tape drive's GUID every time the script runs. Even if it were possible to do that, it would be a bad idea because an automated script that dynamically reads a tape drive's GUID could potentially run an operation against the wrong drive. I recommend running a simple command to determine the tape drive's GUID and then hard-coding that GUID into the script that we are creating.
To determine a tape drive's GUID, open a Command Prompt window on the server to which the tape drive is attached and enter the following command: rsm view /tlibrary /guiddisplay.
This command gives you a way of interacting with the RSM via the command line. This will be important later on. If you notice the command's syntax, we are basically just telling the RSM to display the GUIDs associated with the tape library. When you enter the command, the output will look something like what you see in Figure 1, but your GUIDs will be different than mine.
Now that we have the GUID for the tape drive, let's get the GUID for the tape that's in the drive. You can do this in as little as two lines of code. Again, you will be leveraging the power of the RSM to accomplish this. The code itself looks like this:
Set drvguid=d5696cdcaf9b45f9b74f078cb6854fdd FOR /F "usebackq" %%i IN ('rsm view /tphysical_media /cg%drvguid% /b /guiddisplay') DO set x=%%i
Now that I've shown you the commands, let's go over what they actually do. The first line simply assigns the tape drive's GUID, which I looked up earlier, to a variable named DRVGUID.
The second line is more complicated; it is basically a "for" command that sets the variable X to equal the result of the code that falls in between the two %%i markers. That code tells the RSM to display the GUID of the tape currently loaded into the tape drive that you have specified. Notice that the line makes use of the %drvguid% variable, which was defined in the previous line. You could actually specify the tape drive's GUID in place of the variable, but assigning that GUID to a variable keeps you from having to retype the GUID in other lines later on. (Remember, this is only the first step in the process). You may also have noticed that the /B switch is being used with the RSM command. This tells the RSM that you don't want to see any information other than the tape's GUID. When the line executes, the tape's GUID is assigned to the variable X.
So far, we have used the tape drive's GUID in conjunction with a few commands to retrieve a tape's GUID. You might be wondering how we can verify that the command worked. In the coming parts of this article, I will show you a lot more you can do with these commands, but I want to leave you with one more line of code you can use to verify that the code you have already produced is working correctly. The line is:
rsm eject /pg%x% /astart
This command tells the RSM to eject the tape that is currently in the drive. The reason you can use this line of code to verify that everything is working correctly is because the code references the tape by its GUID (notice the %x% variable reference). If the tape ejects successfully, it means that the code you produced is working properly.
Now that I have shown you how to read the GUID of a tape, we can build on that and create a script that truly leverages the power of both NTBACKUP and the RSM. In part three, I will talk more about this and show you how to bridge the gap between the RSM and NTBackup. In part four, I will show you the commands you can use to invoke NTBACKUP.
About the author:
Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server and IIS. He has served as CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. He currently writes for SearchWincomputing as well as other TechTarget sites.
Step-by-Step Guide: Automating Backups
Automating complex backups, part 1: Crash course on RSM
Automating backups, Part 2: Creating a script to leverage RSM
Automating backups, Part 3: Building on your script
Automating backups, Part 4: The trick to scripting