Section 9.6. Disk Targets

9.6. Disk Targets

As mentioned in section "Tape Drives Must Be Streamed" earlier in theis chapter, properly streaming a drive increases both its throughput and reliability. The tactic that most backup software products used to stream drives was to send multiple backup jobs simultaneously to the same tape drive, a technique called multiplexing or interleaving. This technique helps backups but can have a negative impact on the restore of a single backup; the backup software reads the entire tape and disregards the data that it doesn't need. A few backup software products solve the streaming issue with disk staging, in which backups are first sent to disk before they are sent to tape.

If you want to speed up backups and restores, you should buy enough disk to hold all on-site backups.

With the advent of lower-priced ATA-based and SATA-based disk arrays, many backup software vendors are now adding disk staging features to their products, allowing many more people to take advantage of disk-based backups without switching from a traditional backup architecture. Augmenting your tape library with some type of disk has now become commonplace; the only problem is choosing among the various ways in which to do so. The following paragraphs should help.

You can augment your traditional backup system, illustrated in Figure 9-6, with disk. The first two options are called disk-as-disk because they are disk drives behaving as disk drives; they aren't emulating tape. In a SAN disk-as-disk configuration (see Figure 9-7), a disk array is connected to one or more backup servers via a SAN, and a disk volume is assigned to each server. Each backup server usually then puts a filesystem on that volume, and backups are sent to that filesystem. (Some backup software packages can back up directly to a raw volume, but most cannot do so.) In a NAS disk-as-disk architecture (see Figure 9-8), the disk resides behind a filer head that shares filesystems via NFS or CIFS; backups are sent to those filesystems. The next two options use virtual tape libraries, in which disk systems are placed behind an appliance running software that allows the disk array to emulate one or more tape libraries. Figure 9-9 illustrates standalone VTLs that sit next to a physical tape library and emulate another tape library. Once you back up to a standalone VTL, you must use the backup server to copy its backups to physical tape if you want to be able to send them off-site. An integrated VTL (see Figure 9-10) sits between a physical tape library and a backup server, and it emulates the physical library it is sitting in front of. The backup server backs up to the integrated VTL, and the VTL then copies the virtual tapes to physical tapes without using the backup server. Finally, virtual tape cartridges are an interesting hybrid between virtual and physical tape.

Figure 9-6. The traditional backup architecture

Figure 9-7. SAN disk-as-disk

Figure 9-8. NAS disk-as-disk

Figure 9-9. Standalone VTL

Figure 9-10. Integrated VTL

9.6.1. Disk-As-Disk Targets

When backup software backs up to a disk-as-disk system, it knows it is disk, and it typically creates a file within the filesystem. As mentioned previously, some backup software packages are able to back up directly to a raw disk device, but this is rare.

9.6.1.1. Advantages of disk-as-disk targets

The biggest advantage that disk-as-disk targets have over most VTL targets is their cost. Most disk-as-disk systems cost less per gigabyte than VTL systems because you're not paying for the value of the VTL software.

Some people save even more money by redeploying an older, decommissioned array as a disk-as-disk target. Of course, decommissioned arrays are often end-of-life units without service contracts, and those service contracts should be resumed if you're going to use the unit in a production system. Since service contracts on older equipment can be quite expensive, be sure to compare the cost of resuming the contract to the purchase of a new system with a contract already included.

Another advantage of disk-as-disk backup targets is that most backup software companies aren't currently charging you to back up to them. We will discuss in the disadvantages section how this is changing.

The final advantage of disk-as-disk targets is their flexibility, and this flexibility may come into play if you plan on moving away from a traditional backup architecture. For example, if you're looking at adopting a de-duplication backup system, a CDP system, or near-CDP system, all these options require a disk-as-disk target. These advanced commercial data protection options are beyond the scope of this book, so the following are some very quick definitions. A de-duplication backup system attempts to eliminate redundant blocks of data at the client level and transmits only new unique blocks of data to the backup server. A near-CDP system uses replication and very frequent snapshots to create many points in time to recover from, and a true CDP system backs up every block of data as it changes but stores each block in a continuous log, allowing you to restore to any point in time. There's more information about these types of backup products in Chapter 8.

9.6.1.2. Disadvantages of disk-as-disk targets

At this writing, most backup software products do not require additional licenses to back up to a disk-as-disk target, but this is changing rapidly. Backup software companies are starting to charge for what used to be free, and this trend is expected to continue. The backup software companies defend this move because they are adding additional functions to their backup software.

Another disadvantage of disk-as-disk backup devices is the nature of filesystems. Files are written, opened, changed, and stored back to the same place. Often, the new file doesn't fit in the same place where the old file was, so a portion of it gets written to the original location while another portion is written somewhere else on the disk, resulting in fragmentation. The more files you add, delete, and add back, the more fragmented the filesystem becomes. The way a backup system uses the disk will result in significant fragmentation over time that will degrade performance. (Later, we will explain why VTLs don't have this limitation.)

Yet another disadvantage of disk-as-disk backup targets is that some backup software products don't back up to filesystems as well as they back up to tapes. For example, backup software products know exactly what to do when a tape fills up, but they're not always sure what to do when a filesystem fills up. Some backup products require you to point disk-as-disk backups to a single filesystem. When that filesystem fills up, all the backups faileven if there is another filesystem with adequate capacity.

Another challenge with disk-as-disk backup targets is how to create off-site backups. Although it's a best practice to copy the original backup to tape and then ship that tape off-site, most people don't do this with their tapesthey simply eject the original tape and send it off-site. You can't do this with a disk array; therefore, you need to learn how to copy disk-based backup data to tape and how to automate the process. Automating this can range from extremely easy to extremely difficult, depending on the backup product you use, and it may require the purchase of additional software from your backup vendor. Whatever method you choose in order to get the data from disk to tape, remember that the data is now moving twice, where before it only moved once (if you were ejecting originals). You'll need to budget time for the data to make that second move.

Be sure to read the section "How do you eject virtual tapes?" later in this chapter to see whether VTLs have the same problem.

One final disadvantage of disk-as-disk targets is the lack of hardware compression. Hardware compression can increase the speed and capacity of a backup device by as much as 100 percent. Some disk-as-disk products do support de-duplication, which should not be confused with compression. See "Disk Features to Consider" later in this chapter for more information on de-duplication.

9.6.1.3. SAN disk-as-disk targets

A SAN disk-as-disk target (see Figure 9-7) is simply a disk array connected to the SAN and attached to one or more backup servers. The backup server puts a filesystem on the array and writes to that filesystem. The advantage over a NAS disk-as-disk system, of course, is the superior write performance typical of a high-end SAN disk array compared to an IP-based NAS filer.

However, when you use a disk array as your backup target, you replicate into your secondary storage all of the provisioning issues of your primary storage. All of the hassle with associating disks to RAID groups, RAID groups to servers, and volumes to filesystems now needs to be done on the back end of your backup system. This problem is compounded when you have multiple backup servers. When using a tape library or VTL, most backup software packages know how to share these devices. However, if you're using a SAN disk-as-disk target with multiple backup servers, you're usually going to need to decide how big each backup server's volume needs to be and to allocate the appropriate amount of space to each backup server. (Some backup software packages are capable of dynamically sharing disk, and this removes a lot of the provisioning issues.)

9.6.1.4. NAS disk-as-disk targets

A NAS disk-as-disk target (see Figure 9-8) removes many of the provisioning issues of a SAN disk-as-disk target by putting the disks behind a NAS head, making a giant volume and sharing that volume via NFS or CIFS. Generally speaking, such systems are also easier to maintain than traditional disk arrays. However, remember that easier management comes with a cost. Both the filer head and filer OS add to the cost of the system, and performance is limited to the throughput of the filer head. Depending on the size of your backups, though, performance may not be an issue. Also, if you're a NAS shop with many other filers, a NAS disk-as-disk target makes perfect senseespecially if you are going to examine a near-CDP system.

Clustered Filesystems As Targets

Clustered filesystems could address some of the disadvantages of disk-as-disk targets. They help with provisioning by not requiring you to use a volume for each backup server, without suffering the single-head limitation of a typical NAS system. The challenge as of this writing is that clustered filesystems are still considered bleeding edge by many. While they're solving many problems for many people, they also come with limitations that may cause other problems for backup systems. For example, some of them offer very good performance for hundreds of simultaneous streams of data, but poor performance for any individual stream. Clustered filesystems are also typically more expensive than the other options we're considering here. If these limitations are removed, clustered filesystems may someday be an option as well.

9.6.2. Disk-As-Tape: Virtual Tape Libraries

Virtual tape libraries are the alternative to disk-as-disk targets. They are also called disk-as-tape units because they are disk arrays emulating tape. Many people believe that VTL software is something else to pay for in addition to the disk array that they're already buying, and they're unsure of why they should do that. This section should help answer that question. It begins with a discussion of the advantages and disadvantages of all VTLs, and then explains the difference between standalone and integrated VTLs and the advantages and disadvantages of each. Finally, it describes the features that you should consider when deciding which VTL to purchase.

9.6.2.1. Advantages of VTLs

The main advantages of a VTL over a disk-as-disk target are ease of management and better performance. As mentioned in the previous section, a disk-as-disk target requires all of the usual provisioning steps of standard shared storage arrays. In contrast, you tell a VTL how many virtual tape drives and virtual cartridges you want it to emulate, and you're done with provisioning. The VTL software automatically handles all the provisioning, allocating the appropriate amount of disk to each virtual cartridge and dynamically giving access to that cartridge to each backup server that needs to use it.

Not all VTLs eliminate provisioning to the same degree. This is an important thing to consider when evaluating a VTL.

Another important management advantage of VTLs is how easy it is to share VTLs between multiple servers and applications. If you need to share a VTL between multiple backup servers running the same software, you can use the built-in library sharing capability that most commercial backup products already have. If you need to share a VTL between multiple servers that don't support dynamic sharing (such as with an open-source product or when using it with multiple products that can't share with each other), you can just partition the VTL into multiple smaller VTLs, assign a certain number of virtual cartridges to each VTL, and associate each VTL with a different backup server. You can also do this if you don't want to use the library sharing software offered by your backup vendorjust give each backup server its own tape drives. Both of these scenarios are much easier than what is required to share a disk-as-disk target between multiple backup servers.

To understand the performance advantages of VTLs, you must first think about how backup applications write data to tape. Once a backup application starts writing to a tape, it typically continues writing to that tape until it hits physical end of tape. It will append to a tape even if some of the previously written data has already expired. Once the backup application hits PEOT, the tape is considered full, and most backup applications leave everything on the tape until all backups on that tape have expired. Then they expire the whole tape and write to it from the beginning of the tape. Other backup applications wait until a certain percentage of the backups on a tape have expired and then reclaim that tape by migrating all of the nonexpired backups to a second tape and then expiring (and subsequently overwriting) the first tape. The point is that you do not overwrite portions of a tape; tapes simply don't work like that.

This is very different from how backup applications write to a filesystem. They tell the operating system that they want to write to a certain filename and then start writing data to that file. Each backup gets its own file. When that file expires, it is deleted. The backup application has no knowledge of how this data is actually written to disk. Underneath the covers, of course, the bytes of any given file are fragmented all over the disk. This fragmentation results in a loss of performance.

VTLs treat disk like tape. They know they are being used for backups and archives, and they know how backups and archives behave. This allows them to eliminate fragmentation by writing backups to contiguous sections of disk. The blocks allocated to a given tape stay allocated to that tape until the backup application starts overwriting that tape, at which point the VTL can again start writing to contiguous sections of diskjust like we write to tape. Some VTL vendors even control the RAID volumes, allowing them to make sure that a given RAID group is only being written to by a single virtual tape. Think of how well a disk can perform if it is only writing/reading for one application at a time that is always writing/reading with contiguous sections of disk.

Another key performance difference is the use of clustering in some VTLs. While clustered filesystems are still the exception and not the rule, this is not the case with VTLs. Several VTLs offer the idea of multiple data movers, where each data mover adds additional capacity and throughput. The use of clustering along with their customized way of writing to disk should explain why the fastest filesystems write in hundreds of megabytes per second, but the fastest VTLs write in thousands of megabytes per second.

VTLs have other advantages, as well. With one exception (covered in the disadvantage section), your backup software and your backup operators and administrators can use all of their existing technology, processes, and procedures when using a VTL for backups. This means that everything works exactly as it would if you were using a physical tape library (PTL). That is not the case with disk-as-disk targets, where backup software can behave quite differently.

Some VTLs also support compression, allowing you to fit more backups on the same amount of disk. (This should not be confused with data de-duplication, which is covered later in the chapter.) Whether you purchase and use the compression feature of your VTL or not will be based on which VTL you have and how you are using it. Unfortunately, many VTLs use in-band software compression that saves space, but results in a significant performance hitas much as 50 percent. If your backup speed is throttled by the speed of your clients and/or your network, you may not see this performance hit. You will probably see it in local or LAN-free backups, though, as their speed tends to be throttled by the backup device. Some VTL vendors support hardware compression that doesn't impact performance. (They accomplished this by using the same type of chip that is used in front of tape drives.)

9.6.2.2. Disadvantages of VTLs

The first disadvantage of VTLs that many people mention is cost. People believe that if a disk array costs X, a disk array made to look like a VTL is going to cost X + Y. Oddly enough, disk-as-disk units have roughly the same price range as VTLs, which means it's basically not fair to say that VTLs always cost more than disk-as-disk units. Your cost is based on which VTL you purchase and which disk-as-disk target you compare it to. Most VTLs use capacity-based pricing, meaning it costs $X/GB. As of this writing, the most expensive VTL is three times the price of the least expensive VTL, so it pays to shop around. Finally, if your VTL supports data de-duplication, it can make the VTL even cheaper.

Another cost issue that people have with VTLs is backup software licensing. If you purchase a VTL to sit next to your existing tape library, you are probably going to need to buy an additional tape library license...for a library that's not really there. This, of course, adds to the price of the VTL. How much you actually pay is based on how your backup software charges for PTLs and/or VTLs. Some backup software products have a single license for all tape libraries, while others charge for the number of slots or the number of drives. Some also have capacity-based pricing for VTLs. Therefore, consider how your backup software charges for PTLs and VTLs when deciding how to configure your VTL. (When comparing VTLs to disk-as-disk targets, remember that backup software products are also starting to charge you to back up to disk-as-disk targets.)

9.6.2.3. How do you eject virtual tapes?

The answer to this question depends on whether or not you purchase a standalone VTL (see Figure 9-9) or an integrated VTL (see Figure 9-10). As discussed previously, one major advantage of VTLs is that they do not require any changes to your existing backup process or configuration. The one exception to this is if you are not used to copying your backup tapes and sending the copies off-site. Although it is not a best practice to do so, many environments eject their original tapes and send them off-site. This works fine with a PTL, but not with a VTL. Therefore, companies that eject their original tapes and wish to use a VTL must usually do one of two things: learn how to copy tapes or use an integrated VTL. Which of these two approaches is best for your environment will be based on your preferences.

Some say that the tape-to-tape copy method with standalone VTLs is the only proper way to create physical tapes from virtual tapes. It allows the backup software to control the copy process, therefore integrating the copy process into your normal reporting procedures. However, this method has two challenges. The first challenge is how difficult it may be to automate this process, depending on which backup software product you are using. With some backup products, you may simply need to read a new section in the manual and do what it says. With others, you may need to purchase an additional license. Finally, some backup products actually require you to script this process. You need to determine the level of difficulty for your environment. The second challenge with this process is that many environments do not have enough time in the day and resources in their system to copy their backup tapes quickly enough. For many companies, it is all they can do to get their backups done in time for the vault vendor to pick them up. Of course, if you already know how to copy your backup tapes, and you have enough resources to do so, this disadvantage is a nonissue.

If the challenges of copying your virtual tapes to physical tapes concern you, you might consider an integrated VTL. There is a lot of FUD (Fear, Uncertainty, and Doubt) out there about integrated VTLs, so please read carefully about how they work. An integrated VTL sits between your backup server and your physical tape library. It inventories the PTL and represents its contents as virtual tapes in the VTL. For example, if you have physical tape X01007 in your PTL, virtual tape X01007 will appear in your VTL. Your backup software will then back up to virtual tape X01007. At some user-configurable point, virtual tape X01007 is copied to physical tape X01007. Then when your backup software tells the VTL to eject virtual tape X01007, physical tape X01007 appears in the PTL's mail slot. An important point is that physical tape X01007 looks just like it would if your backup software backed up directly to it. Your backup software thinks that it backed up to and ejected physical tape X01007, and in the end, that's what it did. Using bar code matching like this maintains the consistency between the backup software's media manager and the physical tapes. Remember, however, that this method does not result in two copies of the tape. The virtual copy of the tape is deleted when you successfully create the physical copy.

Some integrated VTLs allow you to have virtual tapes with bar codes that don't match physical tapes. Don't do this! Your backup software will ask for one tape, and you'll have to ask your VTL what tape that really is.

There are some challenges with this method as well. The first challenge is what happens when the copy from virtual tape to physical tape fails. If the reason the copy failed is that the actual tape is bad, you need to remove the tape, swap its bar code to a new tape, put the new tape in the PTL, and tell the VTL to try the copy again. (Of course, this works only if your bar codes are removable.) If this happens occasionally, you might not consider this a major disadvantage. However, if it happens every day, it could get quite annoying. It's also important to realize that the entire process is happening without the knowledge of the backup software, which means that if something does happen with a tape copy, the VTL will need to notify you of the problem. This, of course, means you have another reporting interface, which some would consider a disadvantage as well. Another potential problem is what would happen if the VTL put more data on the virtual tape than would fit on the physical tape. You would not be able to create a physical copy of this tape. Integrated VTL vendors make sure this doesn't happen by stopping way before the normal physical end of tape. Standalone vendors mention that this increases the number of tapes to purchase and handle, increasing your costs. Remember that if you purchased an integrated VTL and decide not to use its tape copy features, it can act as a standalone VTL.

As of this writing, some VTL vendors are working with some ISVs to allow the ISVs to control the copy process but still allow you to take advantage of the features of an integrated VTL. That would give us the best of both worlds.

9.6.3. Disk Features to Consider

The following section covers some major features to look at when considering the purchase of a disk target. Because most of the advanced features are being developed by VTL vendors, most of these features apply only to them.

9.6.3.1. Packaging

Since what VTL and NAS vendors sell is basically software running in some type of host or appliance, let's consider how these types of systems are packaged. Some VTL/NAS vendors are software-only, which means that you can buy just their software to run on your own CPU and your own disk. Some VTL/NAS vendors sell you a VTL/NAS head. You use their software and their head, but you supply your own disk. Finally, some VTL/NAS vendors prefer to sell you the entire solution softwarehead, disk, and all. Software only and filer head vendors obviously allow you to redeploy an existing array, reducing your cost. Turnkey vendors cost more but have the fewest integration issues.

9.6.3.2. De-duplication

Probably one of the most important features to consider is the availability of de-duplication. De-duplication is a rather intensive process that examines each block of data as it comes into the device and attempts to determine if it's seen the block before. If it hasn't, it stores it. If it has seen the block before, it throws the block away and stores only a reference to it. Examples of obvious duplicate data that it would identify and store only once are listed here:

• The same file backed up from five different servers

• A weekly full backup when only 5 percent has changed (95 percent would be duplicate blocks from last week)

• A daily full backup of a database that doesn't support incremental backups (most of it would be duplicate blocks from the day before)

• Incremental backups of files that change every day, such as a spreadsheet that gets updated every day; only the changes would get stored every day

Consider a typical data center with a mix of database data and filesystem data, performing weekly full backups and daily incrementals. The average de-duplication system can reduce the amount of storage needed to store its backups by 20 to 1 or more. Those performing monthly full backups see a lower de-duplication ratio. You may see much higher numbers in vendor literature; do not make the mistake of comparing two vendors based on their de-duplication ratio claims. While some vendors may be better than others in eliminating redundant data, what matters is how well that vendor's algorithm works with your data. Be sure to benchmark the performance and de-duplication ratio of each system using your own data.

9.6.3.3. Replication

If you're storing only new unique blocks every time you run a backup, another interesting feature to consider is replication, or cascading, as it is sometimes called in the VTL world. This feature allows you to replicate one disk device's backups to another device. Remember that without data de-duplication (discussed later), what you will be replicating is the entire backup, and remember that most backups are not block-level backups. Even incremental backups take up roughly one to five percent of the amount of data being backed up, which means you will need to replicate one to five percent of your data center every nighta significant undertaking for many environments. Therefore, it may be possible to use this feature only within the campusunless your device supports de-duplication.

Also keep in mind that the backups in the second device will not be considered duplicates by your backup software because they will have the same bar codes or filenames as the original tapes. How you go about using these tapes in a disaster or outage will depend on your backup software. You may need to replicate your backup catalog and start up another backup server in the new location. If your old backup server is still alive, you may be able to tell it that the primary tape library was simply moved to the new location. Make sure you figure out what to do before it happens.

9.6.3.4. Content-awareness

A content-aware disk target understands the backup formats being sent to it and extrapolates the original data from that format wherever possible. A simplified version of this would be taking a tar stream and turning it back into the files that are in the tar stream. If that's all a content-aware system did, it wouldn't be offering any additional features. However, if a disk target can turn the backups into the backed up files, such a system may be able to do something else that we'll call re-presentation.

Content-aware products are typically aware only of the top three to five commercial backup products and may not understand open-source products or products with a small market share.

9.6.3.5. Re-presentation

If your disk target is content-aware and has extrapolated the original data from its backup format, it can potentially do a number of interesting things by re-presenting the data back to you. Some products present the data using a web page with directory trees whereas others present the data via an NFS or CIFS mount. In all cases, you can access all versions of all files that have been backed up to the device in question. Find the file you want, and just drag and drop it to your desktop. There's no backup GUI to learn and no application to install; just use the tools you already know.

This feature breaks decades of backup tradition by giving you another way to access your backups. For too long our files and databases have been put into backup formats that required the backup software to extract them. We've lived with this for so long that it's actually quite hard to imagine the possibilities that this brings to the table. Here's a short list to help you wrap your brain around this one:

• You can point a full-text search appliance directly at your backups and search the full text of all files ever backed up.

• If you're running multiple backup products, users and administrators can use a single method of recovery.

• Imagine how easy end-user recoveries would be if you could just point them at a mount point such as \\backupserver\yourclientname\date.

• If the disk device allows you to mount the backup read/write, you could actually use the backup as the production filesystem if the production filesystem were down.

• What about using this feature to move between backup products?

These last two ideas deserve more treatment than a single sentence. Suppose you could mount your "backup" as a read-writable volume. Your production database could mount that volume if the primary volume were damaged. Any changes would be stored and could be copied back to the primary system after the primary volume was restored.

Finally, the last bullet pointmoving between backup productsis also quite important. Anybody who has been doing backups for a while has been presented with the situation in which you've been using backup product XYZ, and you no longer want to do so. Maybe the product is no longer available, or maybe the vendor providing the product has not been innovating to the degree that its competitors have. Historically, moving from one backup product to another meant that you had to keep your old backup software up and running as long as you wanted to restore from your older backups.

What if you had been backing up to a content-aware product? You would no longer need your old backup software to restore from its backups. One option would be to leave the old backups in the old format and just use the web page or filesystem access to restore from them. The second option would be to mount the old backups to the new backup server and back them up to the new format. Just think of the flexibility that this offers you.

Are Disks Supposed to Be Left Powered Off?

The short answer is no. Disks left powered off were never designed to store data long term. If you ask a disk manufacturer how long you should be able to leave a drive powered off, they will probably tell you it's not a specification that they track. Disk drives are meant to be turned on.

Therefore, there is some question whether removable disk drives are an acceptable medium for off-site backups. Most vendors marketing these products are suggesting that you use them only for "cyclical" backups that are stored for short periods of time, such as a few weeks or months. One vendor is claiming to use something analogous to RAID within a single disk to remove the issues with individual parts of the disk becoming damaged. That vendor uses parity stored on the same disk to allow it to reconstruct data if it is lost due to damaged sections of disk. Time will tell whether these claims are valid.

9.6.3.6. Stacking

Some integrated VTLs offer an additional feature, known as stacking. Stacking is copying multiple virtual tapes onto one physical tape, a feature they borrowed from mainframe virtual tape systems (VTSs). This made sense in mainframes, where applications were unable to append to a tape. The VTS would present to the application hundreds of small virtual tapes and then stack those virtual tapes onto one physical tape, saving tens of thousands of dollars in media. The value of this feature in most open-systems environments is highly questionable because any decent backup product can append to a tape until it is full. Be aware that the use of this feature breaks the relationship between the backup software's media manager and the physical tape. Also, be aware that some products that support stacking must read the entire stacked tape to read just one of the virtual tapes stacked on that tape. Therefore, you should use this feature only if you are gaining a similar benefit to that achieved in the mainframe environment.

9.6.3.7. Notification

It is also important to consider which type of notification your disk device supports, especially if you are considering an integrated VTL.^[*] Some support SNMP traps and some support email notification while others require you to log in to a web page to be notified of any issues.

^[*] An integrated VTL copies virtual tape to physical tape outside the knowledge of the backup server. If something goes wrong, the only notification you will have will come from the VTL; therefore, notification features are much more important in an integrated VTL.

9.6.4. Disk-As-Tape: Virtual Tape Cartridges

Another way disk emulates tape these days is through virtual tape cartridges (VTCs). VTCs are designed to go inside a tape library and behave like tape in every wayincluding removabilityexcept they're actually disk. At this writing, this is a brand new concept that may or may not catch on. There are currently three different styles of VTCs.

One VTC uses an array of disks in a canister that's larger than a normal tape but can be handled by a particular model of tape library. It moves the VTC in and out of a virtual tape drive and puts it back into a slot that allows you to eject it like any other cartridge. The advantage to this method is that the VTC is RAID-protected. The disadvantage to this method is that it is a standard size that works only with one vendor's tape library.

Another VTC puts a single laptop-style drive into a cartridge that looks exactly like an LTO cartridge and uses a specially designed virtual tape drive that accepts only this cartridge. If you put an "LTO" VTC in a real LTO drive, it will eject it, and vice versa. Both the drive and tape have exactly the same form factor as LTO, so they could be integrated into any library vendor that supports LTO. This VTC is, of course, no more or less RAID-protected than another tape. The cost is higher than physical tape, but this type of VTC gives you the benefits of disk and tape in a removable cartridge.

The final style of VTC is from a few companies that didn't feel the need to make a cartridge that was the same form factor as an existing tape. These cartridges are therefore probably going to be limited to standalone use only.

BackupCentral.com has a wiki page for every chapter in this book. Read or contribute updated information about this chapter at http://www.backupcentral.com.