Book Excerpt: SAN Backup and Recovery Page 10
By W. Curtis Preston
Split the backup mirror
As shown in Figure 4-9, once the database is put into backup mode, the backup mirror is split from the primary disk set (2).
This split requires a number of commands on the Compaq array. First, you set the nopolicy flag with the command set mirrorset-name nopolicy. Then you split the mirror by issuing the command reduce disk-name for each disk in the BCV. Then you create a unit name for each disk with the command add unit unit-name disk-name. Finally, you make that unit visible to the backup server by issuing the commands set unit unit-name disable_access_path=all and set unit unit-name enable_access_path=(backupserver-name).
To do this on EMC, run the command symbcv split -g device_group on the backup server. To do this on Hitachi, run the command pairsplit -g device_group. (On both EMC and Hitachi, the backup mirror devices are made visible to the backup server as part of the storage array's configuration.)
Take the database out of backup mode
Now that the backup mirror is split, you can take the database out of backup mode. Here are the details of taking the databases out of backup mode:
- To start Exchange automatically after splitting the mirror, place the following series of commands in a batch file and run it:
- Again, Informix is relatively easy. All you have to do is specify the appropriate environment variables and issue the command onmode -c unblock. Any commits that were issued while the database was blocked will now complete. If you perform the block, split, and unblock fast enough, the users of the application will never realize that commits were frozen for a few seconds.
- Again, you must determine the name of each tablespace in a particular ORACLE_SID, and use the command alter tablespace tablespace_name end backup to take each tablespace out of backup mode.
- SQL Server
- To start SQL Server automatically after splitting the mirror, run the following command:
net start "Microsoft Exchange Directory" /y
net start "Microsoft Exchange Event Service" /y
net start "Microsoft Exchange Information Store" /y
net start "Microsoft Exchange Internet Mail Service" /y
net start "Microsoft Exchange Message Transfer Agent" /y
net start "Microsoft Exchange System Attendant" /y
net start MSSQLSERVER
Import the backup mirror's volumes to the backup server
This step is the most OS-specific and complicated step, since it involves using OS-level volume manager and filesystem commands. However, the prominence of the Veritas Volume Manager makes this a little simpler. Veritas Volume Manager is now available for HP-UX, Solaris, NT, and Windows 2000. Also, the native volume manager for Tru64 is an OEM version of Volume Manager.
On the data server, the logical volumes are mounted as filesystems (or drives) or used as raw devices on Unix for a database. As shown in Figure 4-9, you need to figure out what backup mirror devices belong to which disk group, import those disk groups to the backup server (3), activate the disk groups (which turns on the logical volumes), and mount the filesystems if there are any. This is probably the most difficult part of the procedure, but it's possible to automate it.
It isn't possible to assign drive letters to devices via the command line in NT and Windows 2000 without the full-priced version of the Veritas Volume Manager. Therefore, the steps in the list that follows assume you are using this product. Except where noted, the commands discussed next should work roughly the same on both Unix and NT systems. If you don't want to pay for the full-priced volume manager product, there is an alternate, although much less automated, method discussed at the end of the Veritas-based steps.
You can write a script that discovers the names of the disk groups on the backup mirror and uses the command vxdg -n newname -t import volume-group to import the disk/volume groups from the backup server. (The -t option specifies that the new name is only temporary.) The following list is a brief summary of how this works. It's not meant to be an exact step-by-step guide; it gives you an overall picture of what's involved in discovering and mounting the backup mirror.
- First, you need a list of disks that are on the primary disk set. Compaq's show disks command, EMC's inq command, and Hitachi's raidscan command provide this information.
- To get a list of which disk groups each disk was in, run the command vxdisk -s list devicename on Unix or vxdisk diskinfo disk_name on Windows.
- Import each disk group with the vxdg -n newname -t import disk-group command.
- A vxrecover is necessary on Unix to activate the volumes on the disk.
- On Unix, you may also need to mount the filesystems found on the disk. On NT/2000, the Volume Manager takes care of assigning drive letters (i.e., mounting) the drives.
You now have a list of disk groups that can be imported from the backup mirror.
TIP: It's wise to perform an fsck or chkdisk of the backup mirror's filesystems at this point.
As mentioned before, if you are running Windows and don't wish to pay for the full-priced version of Volume Manager, you can't assign the drive letters via the command line. Since it isn't reasonable to expect you to go to the GUI every night during backups, an alternative method is to perform the following steps manually each time there is a configuration change to the backup mirror:
- Split the backup mirror as described in the previous section "Split the backup mirror." This makes the drives accessible to the backup server.
- Start the Computer Management GUI in Windows 2000 and later (or the Disk Administrator GUI in NT), and tell it to find and assign drive letters to new disk drives.
- A reboot may be necessary to effect the changes.
- After the drive letters have been assigned, you may establish and split the backup mirror at will. However, bad things are liable to happen if you reboot the server (or try to access the backup mirror's disks) while the backup mirror is established.
TIP: It's wise to perform a chkdisk of the backup mirror's disks at this point.
Back up the backup mirror volumes to tape
This is the easy part. Define a backup configuration to back up the filesystems, drives, or raw devices that were found on the backup mirror. Since the volumes are actually imported and/or mounted on the backup server, the backup server should be listed as the client for this backup configuration. As shown in Figure 4-9, the data is sent from the backup mirror to the backup server (4a), and then to tape (4b).
The transaction logs should be backed up to disk and to tape (as shown in Figure 4-7) before, during, and after this operation.
And that's all there is to client-free backup!
Click here to buy book
W. Curtis Preston has specialized in designing backup and recovery systems for over eight years, and has designed such systems for many environments, both large and small. The first environment that Curtis was responsible for went from 7 small servers to 250 large servers in just over two years, running Oracle, Informix, and Sybase databases and five versions of Unix. He started managing this environment with homegrown utilities and eventually installed the first of many commercial backup utilities. His passion for backup and recovery began with managing the data growth of this 24x7, mission-critical environment. Having designed backup systems for environments with small budgets, Curtis has developed a number of freely available tools, including ones that perform live backups of Oracle, Informix, and Sybase. He has ported these tools to a number of environments, including Linux, and they are running at companies around the world. Curtis is now the owner of Storage Designs, a consulting company dedicated entirely to selecting, designing, implementing, and auditing storage systems. He is also the webmaster of www.backupcentral.com.
1. This term may be changed in the near future, since iSCSI-based SANs will, of course, use the LAN. But if you create a separate LAN for iSCSI, as many experts are recommending, the backups will not use your production LAN. Therefore, the principle remains the same, and only the implementation changes.
8. Although it's possible that some software products have also implemented a third-party queuing system for the robotic arm as well, I am not aware of any that do this. As long as you have a third-party application controlling access to the tape library and placing tapes into drives that need them, there is no need to share the robot in a SCSI sense.
9. Network Appliance filers appear to act this way, but the WAFL filesystem is quite a bit different. They store a "before" image of every block that is changed every time they sync the data from NVRAM to disk. Each time they perform a sync operation, they leave a pointer to the previous state of the filesystem. A Network Appliance snapshot, then, is simply a reference to that pointer. Please consult your Network Appliance documentation for details.
12. There are vendors that are shipping gigabit network cards that offload the TCP/IP processing from the server. They make LAN-based backups easier, but LAN-free backups are still better because of the design of most backup software packages.