So it’s 4:00 on Wednesday afternoon, and you have a print server with a bad drive in the RAID array. Tomorrow is Thanksgiving, and with it, a long weekend. A chance to work on that project at home that you’ve been putting off, or maybe just some overdue family time planned. You don’t want the server to lose another drive in the array over the weekend and be dead in the water. So you hop over to the data center with the replacement drive, after all, RAID is the best thing since sliced bread, right? Pull the failed drive, slap in the new one, and magically the array rebuilds. Problem solved! Only, when you pulled out drive 2 from the RAID 5 array … too late, you realize the bays are numbered 0-3. Doh!! It was the second drive – residing in bay 1. Now you’ve broken the array, and you get to spend the entire Thanksgiving weekend rebuilding the server and reinstalling a hundred or so printers. Like the insurance commercial, that actually happened to a coworker at a previous company I worked at, and he covered it – we know a thing or two because we’ve seen … yep, that one. I’m reminded of a famous quote from Will Rogers,
“Everything is funny when it is happening to somebody else.”
It became a standing gag at the office before every holiday, someone would be asked to make a big change at the last moment (their clue was the sound of subtle snickering). It did become part of company policy though, don’t schedule a major change or update the day before a holiday.
Speaking of scheduling changes, backups remain one of your biggest assets. Still trying to manage that old hardware a little while longer? That phase-out of Windows XP and Server 2003 not yet complete? So you’ve had to take the MacGyver approach to your IT strategy – keeping those legacy machines running with a paper clip and a roll of duct tape. In a previous blog, I wrote about a strategy to get email alerts on your backups from Server 2008 and 2012. Read that blog here. But what about Server 2003 and earlier where you are still backing up data and systems with … ulp! … NTBackup? The topology is different than on newer systems, and the scripts I described previously won’t work. Well then, how do you gain insight on the status of those backups without having to manually check those servers? The drudgery of manual maintenance will give way to assumption, and you know where that leaves you. Certainly, we have moved on from the days of carrier pigeons, smoke signals, and FAX machines (don’t get me started on this one – maybe another day), although we are talking about technology that is nearly 15 years old now. In any event, we can implement a similar strategy as in Server 2008 and 2012 to email the job report created by NTBackup. Here are the details on configuring backup alerting for NTBackup, that I set up on Server 2003 R2 servers:
Ready to Migrate from Server 2003?
Let our professional network team help with your server migration plan and execution. You’ll have the benefit of an experienced team who has completed many successful server migrations, less downtime and a happier workforce than if you go it alone. Start the conversation by completing the form below or give us a call at 405.810.8005.
How to Configure NTBackup Alerts
- Download and extract Blat for Server 2003 R2. My version is 3.2.17. (Note there is an x32 and x64 version)
- Copy the (blat3217) folder to C:\. It will contain 2 folders, docs and full. The blat.exe is the full folder.
- Register blat with the target mail server and email address of the user with access to the mail server at a cmd prompt: blat -install server_name your_email_address
- Open NTBackup and create a backup job. Specify a schedule for the backup.
- Make a copy of the following script to use for emailing the report (Give it a name, i.e. Portal D.bat):
set SMTP=smtp.domain.comset Subject=Backup Report
set LogFileFolder=%UserProfile%\Local Settings\Application Data\Microsoft\Windows NT\NTBackup\data
for /f “delims=” %%a in (‘dir /o:d /b “%LogFileFolder%\*.log”‘) do set LogFile=%%a
“C:\blat3217\full\blat.exe” “%LogFileFolder%\%LogFile%” -f %From% -to %To% -server %SMTP% -subject “%Subject%”
- Update lines 3-6 with your information for To, From, SMTP, and the report Subject line.
- Only update line 7 if your logs are in a different location.
- Update the C:\blat3217\full\blate.exe if your information is different.
- Open the Task Scheduler, then open the backup job you just created.
- Copy the entire command line for running the backup with all the switches created by NTBackup.
- Paste your command line into the script in place of the %Systemroot%\system32\ntbackup.exe … line.
- I always copy the line into a notepad file in case something goes wrong, I can put it back. Also, it gives you the option of adding switches more easily, if needed (maybe you want to rename the report with a date extension, for example).
- Now change the command line of your task to start the script, i.e. “C:\Backup\Portal D.bat”
- Change your Start In setting to C:\Backup.
- Enter your Run As user credentials.
16. The task will now run the backup, then at the end, it will go grab the most recently created report and email it.
So at times, if you need to rescue those older systems, you won’t have to channel your MacGyver-like creativity and ingenuity to work magic that would even make Angus himself take notice. The old adage “lack of planning on your part does not necessitate an emergency on my part” comes to mind. If you fail to plan, and don’t know your backups are trash, then you will have created your own emergency.
I remember a story I heard years ago about the folks from, we’ll call it Boldavia, who did not want to get behind in the space race. Forget going to the moon or to Mars, they said. Our ambitions are much higher, we’re planning a mission to the sun. Incredulous, the other countries’ brainiacs told them that it was absurd, they’d burn up! Not at all, the Boldavians maintained. We’ve planned this and thought it through very carefully. We’re going at night! So it all comes down to planning, but make sure your plan is sound. At the end of the day, we system admins still want to maintain the image of having the capability of walking on water, don’t we? By the way, I’ve heard some actually do! For those of us who have yet to add that feat to our repertoire, we can rest assured that we are covered while battling the effects of tryptophan.
About The Author
Donny Hilbern is a network and systems consultant specializing in analyzing, designing, and implementing network and enterprise systems. Donny has been working in the IT field for over 25 years, with nearly 20 years of that time invested in network and system administration and infrastructure technology. He has experienced a number of undocumented or lightly documented issues during that time. His desire is to leverage that experience in sharing about some of those issues and how they were resolved to make IT work for his clients.
Leave A Comment