Backup-to-disk performance tuning


This article can also be found in the Premium Editorial Download "Storage magazine: Upgrade path bumpy for major backup app."

Download it now to read this article plus other related content.

Benchmarking was critical to the project's success. Each benchmark included backup times from legacy tape backups and various backup-to-disk configurations. Some servers performed better with certain configurations than others. After examining all of the benchmark data, we designed backups for each server based on its particular results. For example, a server that had poor results backing up to disk with a specific storage configuration had increases from 6MB/sec to 100MB/sec. This wouldn't have been realized without benchmarking different storage configurations on the backup disk. With disk backups, restore speeds are normally twice that of backup speeds; our fastest restore for a single server was 180MB/sec.

For a file server, it's common to have data stored on random blocks across a storage array. During a backup to disk, the data is written sequentially. As a result, the read speed during a restore is substantially faster than tape. Even though data is written to tape sequentially during a backup, the tape-restore seek times tend to cause overhead that results in restore speeds that are 50% less than backup times. If you're multiplexing/multistreaming, it also adds more restore calculation times and causes additional delays.

The benchmarking testbed included a Web server, file server and database servers for Windows, Solaris and HP-UX. It's impossible to say that a particular server or OS performed better than

Requires Free Membership to View

another because of the uniqueness of the data on each server. For instance, a Windows file server will perform slower than a Unix database server because the file server works with random writes while a database is sequential. It's therefore more beneficial to explain the results we achieved on each OS and server type, and how we managed to improve various results.

The Solaris and HP-UX database servers performed the best for standard file-system backups. Our best Solaris server peaked out at approximately 100MB/sec or 360GB/hour for backups, and restored at close to 180MB/sec or 648GB/hour. It was an Oracle database server on nine Veritas file systems on nine LUNs, each getting its own backup job. On the same server, however, there was a 4TB mount point that couldn't be made to run faster than 6MB/sec because of the underlying storage configuration. This was the case across the environment; with a larger file system and fewer LUNs, backup and restore ran slower.

The Windows file servers had the poorest performance. The poorest performers used built-in Windows volume management with no striped volumes for data storage. As a result, any I/O was single-threaded and often competed with user activity. Our fastest Windows file server ran at approximately 5MB/sec no matter how many streams were used. Next up was the Solaris file server, which came in at a whopping 7MB/sec. A good way to increase those numbers is to implement Veritas Flash Backups or some other form of snapshot technology.

The bottom line is that the key to faster backup to disk is how the production and backup storage is configured. This company wanted a restore capability of 1TB within eight hours; it can now restore a terabyte in less than two hours on its fastest server.

This was first published in September 2006

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: