Kick the TAPE!

Kick the Tape! By Eric B. Rux, MVP MVP logo

Back in the day, backing up to tape was the preferred way to ensure that your data was safe. Most companies had a few megabytes of data to safeguard, and the early dat drives were sufficient. As time went by however, megabytes turned to gigabytes, and gigabytes turned to terabytes. Not only are tapes too small to backup this much data, they are too slow.

When our server ran into this problem, we immediately started researching “tape jukeboxes”. Instead of one tape drive asking you to manually feed it blank tapes, the jukebox would take care of everything. They are really quite impressive. However, this convenience (& capacity) comes at a premium. Depending on how much you want to backup, these devices can cost anywhere between $5000 and $20,000+. Enterprise solutions can cost even more.

After we realized that it wasn’t cost effective for us to continue using tape, we started to think out of the box. This led us to a “Backup To Disk”, or B2D solution. The solution we chose has a large capacity (2 terabytes uncompressed, 4 compressed), and is VERY fast. Backups that used to take hours, now take minutes. It is also cheaper as the hardware is nothing more than a fileserver with removable drives. The company that we bought our solution from (Aberdeen) has a server that will backup over 6 terabytes of data, or 12 terabytes compressed!

In order to Kick the Tape, you will need three things:

Dedicated Backup Server
Backup Software (Veritas Backup Exec, ArcServe, or similar)
Backup Network (optional)

HARDWARE

The first item to consider is the Backup Server. In reality, any decent fileserver will do. However, a little planning now will save you heartache later. Consider for example the costs of the disks. You will no doubt want to have an “offsite” set of disks in case of a disaster. This will at least double the cost of the storage media. You will also want to be thinking about how you will use the disks in the event of a disaster (where you physically lose the original Backup Server due to fire/theft/flood). How will you get to the data on the disks?

The solution that we came up with was to use an Aberdeen server containing a Serial ATA IDE drives on a 3Ware 8 port controller. The drives are fast, huge, and cheap (compared to SCSI). The drives are NOT configured in a typical RAID array, but in what’s called JBOD (Just a Bunch Of Disks). When setup this way, I can take the disk to a PC with a standard ATA controller and access the data. Simply import the disk using the Disk Management MMC, then catalog the disk. Unlike a tape drive based disaster recovery, no expensive hardware is needed; just old PC’s with ATA cards.

The 3Ware controller is connected to an 8 port Backplane. The hard drives slide easily into position and latch securely into place. The combination of the 3Ware controller and the ATA drives have resulted in some extremely fast backup rates. Our Oracle 9i database has a backup rate of over 600 MB/MIN.

This is important: In order for the "Recovery" part of Disaster Recovery to work, you need to be able to READ the media (tape or disks). I specifically set up the hard drives as "JBOD". Setting it up this way allows the disks to be read by any ATA controller on the market. And, at around $50 a pop, having a few cheap offsite controllers isn't that expensive. Compare that with having a dedicated offsite DLT & DAT tape drives just sitting around.

SOFTWARE

The second item to evaluate is the backup software. While some Administrators will argue to their grave about the virtues of “Brand A”, or “Brand B”, I believe that any of the major vendors will work. It’s really personal preference. I like Veritas Backup Exec. I’ve been using it for 6 years, and I understand how it works. Give me 6 years with ArcServe, and I’m sure I’ll love it too. Anymore, you can easily evaluate new software without even talking to a salesman. Do yourself a favor, and be sure to install a few products and kick the tires before you buy.

NETWORK

The last part of this solution is totally optional. I chose to implement a separate “Backup Network” because we sometimes backup & restore our Oracle database during the work day. Because the database is so large, it just makes sense to keep this network traffic separate. And, it really didn’t cost that much. You can purchase a 24 port, unmanaged gigabit switch for under $500. If however, you conduct your backups only at night, then a separate backup network may be overkill.

SETUP

VERITAS

First, create a "Removable Backup To Disk" (or B2D) Device.

After a few seconds, Veritas will setup the drive for you. It will create two files:

Changer.cfg

Folder.cfg

Do NOT mess with these files.

After the drive is ready, right click on the new Device, and choose Properties. Click on the Advanced TAB. Change the "Maximum size for Backup-to-Disk files" to a size greater than what you plan to backup. For example, my Oracle 9.x database is about 45gig. I set the Maximum size to 100gig. If you don't do this, Veritas will create a BUNCH of individual backup files instead of just one per backup.

Next, you need to create a "Media Set".

But first, a word on manually managing media. STOP IT! Do NOT try to “manage” your media. It doesn't matter if it's a tape, or B2D, you NEED to let your backup software manage the media. I used to pull my hair out trying to get the stupid backup program to use the "Thursday" tape for the Thursday backup. Don't do that. Let the software take care of what "tape" is next. This can be accomplished with Media Sets.

Right Click on Media Sets and choose "New Media Set".

I want to keep these backups for three weeks, then reuse the media. I do NOT want to append to the media, so I set it for 1 hour. If the backup runs one a day (for example at midnight), then 23+ hours have passed, and there's no chance of appending (for our schedule, that's good). Depending on your backup/restore requirements, these values may or may not work for you.

Here's an example of the results:

Media B2D000177, 179, 181, 183, & 185 are ready to be overwritten. 187, 189, 191, & 193 cannot be overwritten until the first of July. Notice that I didn't change the Media Label; I just let Veritas do its thing.

What does the "Media Label" represent? If you have a tape drive, then it's the physical tape. If you are doing B2D, then it's the FILE ON THE DISK. In B2D, the disk is the Device, and the file is the Media. What's really cool about B2D is that when Veritas needs more Media, it doesn't ask you for another "tape", it simply creates another file, labels it, and starts the backup job.

Once you create your "Devices" (drives or folders), and setup the Media Sets (tapes or files), the rest should be hands off.

OK. Now that you have B2D all set, what happens if the building burns down? Well first off, place your backup server at the other end of the building (or another building if possible). Next, you need to come up with an Offsite Rotation Plan for the physical disks/tapes. For our company, we swap disks every Monday, and archive to tape every month. The disks are constantly overwritten. The tapes are kept forever (to a point).

NOTE

This is a Business Decision, not an “IT Decision”. Only the business can determine what they can live without. How much data can they afford to lose? How much do they want to spend?

MOVE THE MEDIA OFFSITE

Changing out the physical disks is a five step process (but it's easy):

Shut down the Backup Server

Swap out the hard drives (caddies)

Power on the server & logon

Using the Disk Managment MMC, import "Foreign Media"

Reboot the server

Compared to running to multiple servers with tapes, this is simple.

To keep from having to reboot twice, you can use the “diskpart” utility. You can download it from Microsoft here: http://www.microsoft.com/windows2000/techinfo/reskit/tools/new/diskpart-o.asp

I wrote the following simple command script to import all of the foreign disks upon boot:

Diskpart.cmd

echo . >> d:\scripts\importlog.txt

echo | date | find "current" >> d:\scripts\importlog.txt

echo | time | find "current" >> d:\scripts\importlog.txt

diskpart /s D:\Scripts\import.txt >> d:\scripts\importlog.txt

echo ________________________________________________ >> d:\scripts\importlog.txt

echo .>> d:\scripts\importlog.txt

Import.txt

select disk 1

import

The “importlog.txt” captures what happens when the script is run. Its output looks like this:

The current date is: Mon 08/02/2004

The current time is: 7:46:41.87

Microsoft DiskPart version 5.2.3790

On computer: BACKUPSERVER

Disk 1 is now the selected disk.

DiskPart successfully imported the disk group.

Using Group Policy, run this script on MACHINE Startup. (not when the user logs on). It’s important that this script runs before the “Backup Services” start. If you are having trouble with the Backup Services starting before this script, then you may be able to make this script a “Service”, and make the Backup Services dependant on it. So far, I have found that if scheduled via a Group Policy, the script runs well ahead of the Back Services.

Contacts & Links:

Aberdeen http://www.aberdeeninc.com/index.html

Sales David Valencia DavidV@aberdeeninc.com

3Ware http://www.3ware.com/

Sales 3waresales@amcc.com

I hope you found this document useful. I’d appreciate your feedback. I can be contacted at: ebrux@mvps.org

Eric B. Rux

Information Systems Manager

Pearson Packaging Systems

MCSE, MVP