Book Excerpt: SAN Backup and Recovery Page 13 - EnterpriseStorageForum.com

Book Excerpt: SAN Backup and Recovery Page 13


By W. Curtis Preston

Server-Free Restores

When restoring data from a server-free backup system, you typically restore the data on the image level (file recoveries are rare but technically possible). Image level restores copy the entire image back from tape to disk. File level restores act just like nonserver-free restores, copying the file(s) you select from tape to disk. However, it's important to mention that performing server-free backups doesn't necessarily mean you are going to perform server-free restores. In fact, some server-free backup applications don't support server-free restores at all. The ones that do support server-free restores do so only for image-level restores. To see why this is the case, let's see how a server-free image-level restore works.

Image-level server-free restores

The server-free backup system in Figure 4-17 is the same one illustrated in Figure 4-16. Recall that we created a split mirror or snapshot, then used extended copy to back up that snapshot or mirror to tape. To reverse the process, you first have to create the snapshot to which you're going to restore. Since the entire snapshot is going to be overwritten, it really doesn't matter if it's an older snapshot or one that was just taken. Regardless, the snapshot or split mirror must be created, as shown in (1) in Figure 4-17. Next, the server-free backup application can use the xcopy command to restore the backed up data directly from tape to disk, as shown in (3).

Figure 4-17. Server-free restores

 

The next step is important. Just as you need to stop the application that was writing to the disk during backups, you need to do so during the restore. Otherwise, you'd really confuse things and corrupt the data. Also, depending on your operating system and filesystem type, you usually need to unmount the filesystem you're about to restore. (This is shown as (4) in Figure 4-17.) The reason for this is that the next step is going to completely overwrite the blocks underneath the filesystem. If you do this while the filesystem is mounted, the filesystem is immediately corrupted. Finally, you can restore the image from the backup mirror or snapshot to the primary disk set. Once this has been accomplished, mount the filesystem and resume the application. (If the application is a database, you will probably need to perform a transaction log restore first.)

TIP:  A fully functional server-free backup system automates all the previous steps when you select an image-level restore.

File-level server-free restores

As complicated as image-level restores may seem, file-level restores from server-free backups are even worse. In the top-left corner of Figure 4-18, you can see the original file-to-disk mapping shown in Figure 4-15. Below that, you can see that a snapshot or mirror is created of it, and that mirror is backed up to tape.

Figure 4-18. Movement of file blocks

 

Time passes; files are added, deleted, and modified. Due to the way disk technology works, you can see that File A and File B still use the same blocks, but the blocks are now in completely different places on the disk. Now assume that File B has been deleted, as represented by the white disk blocks.

To perform an image-level restore, you first need to create a snapshot or mirror to restore to. This, of course, duplicates the new block layout of the disk. If you then restore the blocks of data associated with File B, you can see you're restoring them to the wrong place. This overwrites the blocks of some other file, which corrupts that file.

Therefore, file-level restores from server-free backups need to be performed from the filesystem level, which is why file-level restores from server-free backups aren't server-free at all. When you request a file to be restored, the backup software knows that the file was backed up via an image-level server-free backup. It then consults its file-to-block map made during that backup and knows which blocks of data it needs to read from tape. Those blocks are then passed to the client software running on the client where the file needs to be. It then reassembles the blocks into a file it can pass to the filesystem. The filesystem then places the file's blocks in the appropriate site.

Advantages and Disadvantages

The advantages of server-free backups and restores are rather significant:

  • Offloads backup traffic from LAN, CPU, and I/O channels of both clients and servers
  • Neither backup client nor backup server's performance is impacted
  • Safe, reliable online backup of active filesystems, although this can be accomplished in other ways
  • High speed data transfer
  • Full or incremental backup (not available with all server-free products)
  • Image, directory, and file restore (not available with all server-free products)

Cost is the main disadvantage in server-free backups. Server-free backups usually require some change in your primary disk set; it definitely needs to be on a SAN. Depending on the backup vendor you choose, you then need to do one of three things. You can:

  1. Put your primary disk set on an enterprise storage array capable of making split mirrors.
  2. Use an enterprise volume manager that can make split mirrors that are visible to other hosts.
  3. Use an enterprise volume manager that makes snapshots visible to other hosts.

Option 1 requires an enterprise storage array. Options 1 and 2 require additional disks, if you aren't already using split mirrors for backup. Option 3 requires additional software. However, some backup products include the software to do this when you purchase the server-free backup add-on to their product. This software, of course, also comes at a price. The data mover can also exist as intelligence on the disk array, a Fibre Channel router, or another dedicated appliance on the SAN.

The other disadvantage to server-free backups is that the process is rather complex. It requires much more design on the part of the backup software company, since it needs to do the file-to-block mapping. When something goes wrong, there are more pieces of software to troubleshoot.

LAN-Free, Client-Free, or Server-Free?

Which backup option is appropriate for your environment? The answer may be apparent if you ask yourself a few questions:

  • If you're currently performing standard, LAN-based backups, is it negatively impacting the performance of any clients, or are any of the clients difficult to back up during the available window?
  • The easiest way to solve this problem is to turn the affected backup clients into device servers and attach them to one or more tape libraries. The difficulty comes when deciding which tape libraries to connect them to. Suppose that you've only got one client with this problem. You don't necessarily want to buy a separate tape library just for one client. You can physically connect some of your first library's tape drives to the affected client and use library sharing[14] to share the library between this backup client (which is now a device server) and the main backup server. Unfortunately, you probably sized that tape library based on how many drives you needed for the main server, and you are now taking away some of its resources. When you are in this situation, you will almost always benefit from LAN-free backups by connecting the main server and device server(s) to a SAN and using drive sharing to dynamically allocate drives to the servers that need them.

  • If you've already turned more than one of your clients into a device server that backs up its own data to locally attached tape drives, but aren't yet using drive sharing, would being able to dynamically share drives between multiple device servers be beneficial to you?
  • This scenario assumes you already encountered this situation, and have already physically allocated certain tape drives to certain servers. Depending on the number of servers and tape drives involved, you'd probably benefit from a LAN-free backup configuration.

  • You've already turned one or more of your clients into a device server--whether or not you're using drive sharing. The I/O load of backing up its own data to its own tape drives is certainly less than what normal LAN-based backups would generate, but it still creates a load. Is the load generated by LAN-free backups still greater than what you'd like?

If you've answered yes to the questions so far, you are a candidate for either client-free or server-free backups. The decision between the two is a bit more complex. Basically, you should get quotes for both systems, evaluate the cost of each in your environment, and then compare that cost to the benefits in Table 4-3.

Table 4-3: Comparison of LAN-free, client-free, and server-free backups

 

LAN-free

Client-free

Server-free

Backup client CPU, memory, and I/O load of TCP/IP processing to transfer data across LAN

Significantly reduced (must still send metadata to backup server)

Significantly reduced (must still send metadata to backup server)

Significantly reduced (must still send metadata to backup server)

Backup server CPU, memory, and I/O load of TCP/IP processing to transfer data across LAN

Significantly reduced (must still receive metadata from backup client)

Significantly reduced (must still receive metadata from backup client)

Significantly reduced (must still receive metadata from backup client)

Backup client CPU, memory, and I/O load of moving the data from disk to tape

Same as LAN-based, since client is now responsible for moving split mirror or snapshot's data from disk to tape

No I/O load

No I/O load

Backup server CPU, memory, and I/O load of moving the data from disk to tape

Significantly reduced (must still handle I/O of index operations)

Same as LAN-based, because server is now responsible for moving split mirror or snapshot's data from disk to tape

Significantly reduced (must still handle I/O of index operations)

Must client be on SAN?

Yes (for drive sharing)

Yes

Yes

Must client's primary disk be on a SAN?

No

Yes

Yes and SAN must support extended copy

File-level recoveries

Yes

Yes

 

Probably not

 

 

Snapshot

Backup mirror

Snapshot

Backup mirror

Additional disk

None

Cache disk only

Equivalent to usable disk on
primary storage

Cache disk only

Equivalent to usable disk on
primary storage

Additional software

Dynamic drive allocation

Snapshot control, backup control

Backup mirror
control, backup control

Snapshot control, backup control with xcopy support

Backup mirror
control, backup control with xcopy support

Additional server

No

Yes

Yes

No

No

Allows homegrown solutions

No

Yes

Yes

No

No


Click here to buy book

Building SANs with Brocade Fabric Switches

Author
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.

Footnotes:

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.

2. As mentioned later in this chapter, SCSI devices can be connected to more than one host, but it can be troublesome.

3. This is actually a high rate of change, but it helps prove the point. Even with a rate of change this high, the drives still go unused the majority of the time.

4. 1.575 TB ÷ 8 hours ÷ 60 minutes ÷ 60 seconds = 54.6 MB/s

5. There are several tape drives capable of these backup speeds, including AIT-3, LTO, Mammoth, Super DLT, 3590, 9840, and DTF.

6. 20 minutes × 24 hosts = 480 minutes, or 8 hours

7. These are Unix prices. Obviously, Windows-based cards cost much less.

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.

10. It was the Microsoft's partnership with Veritas that finally made this a reality. The volume manager for Windows 2000 is a "lite" version of Veritas Volume Manager.

11. Prior to 9i, this was done with the suvrmgr command, but this command has been removed from 9i.

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.

13. It's not quite 100%, since the second stripe doesn't have to be a RAID 5 set. If it were simply a RAID 0 set, you'd need about 90% more disk than you already have.

14. If your backup software supports library sharing.


Page 13 of 13

Previous Page
1 2 3 4 5 6 7 8 9 10 11 12 13
 

Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 

Storage Daily
Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date