|
Backup is still the greatest pain point for storage managers. The following five vexing backup problems can become less onerous if you use these simple procedures to improve your backup performance and reliability.
- Unhappy tape drives
unhappy tape drives cause more backup and restore issues than any other problem. The most common thing to fail in most backup environments is a tape or tape drive. Tape error may frequently masquerade as another problem. (For example, one backup software product often reflects a drive failure as a network timeout.) And because most environments achieve less than half of the available throughput of their drives, corporate IT buys more and more drives to meet the throughput demands of the backup system.
Modern tape drives are designed to operate at their advertised speeds, and operating them at lower speeds is what causes them to fail more often; there's a minimum speed at which the tape must move past the head to achieve a good signal-to-noise ratio. Even variable speed tape drives have a minimum speed at which they can write data. LTO-4, for example, has a minimum native transfer rate of 23MB/sec. And while few users experience the 2:1 compression ratio advertised by drive manufacturers, whatever compression rate they do experience must be multiplied by the minimum transfer rate of the drive. For example, data that experiences a 1.5:1 compression ratio being sent to a tape drive with a minimum speed of 23MB/sec makes that drive's minimum transfer rate 34.5MB/sec (23 x 1.5).
Depending on which backup software you use, you can increase the speed of backups that go directly to tape with the following: LAN-free backups, multiplexing and not using additional tape drives until you've given the initially used tape drives enough throug...
To continue reading for free, register below or login
To read more you must become a member of SearchStorage.com
hput. The second (and simpler) solution is to stop using tape as your primary target for backups and instead back up directly to disk. Using disk as an intermediary staging device usually gets the initial backup done much faster, and then the local (LAN-free) movement of data from disk to tape can go much faster. These backup methods will keep the tape drives much happier, they'll fail less often and you can reduce the number of tape drives you'll need to buy to get the job done.
[IMAGE] [IMAGE] [IMAGE] [IMAGE]
[IMAGE] [IMAGE] [IMAGE] [IMAGE]
[IMAGE] [IMAGE] Virtual server backup tips
[IMAGE]
[IMAGE] [IMAGE] [IMAGE] [IMAGE]
[IMAGE]
[IMAGE] [IMAGE] [IMAGE] [IMAGE]
There are a lot of questions buzzing around VMware backups, but there aren't a lot of problems. Most people can back up their virtual machines (VMs) as if they were physical machines, and everything works just fine. Most major backup packages have changed their pricing so that you only pay for one license for the VMware server, regardless of how many guests you're backing up.
The big challenge some storage environments face is resource contention, especially if they're doing a lot of full backups. The first thing you can do to solve this problem is to better stagger the full and differential backups across the week and month to minimize the number of backups that could occur at any one time. You should also check out the ability of your backup software to limit the number of concurrent backups on the VMware host. Finally, you should investigate your backup software's ability to do incremental forever inside the VM using features like Synthetic Full Backups from CommVault, Saveset Consolidation from EMC Corp.'s NetWorker, Progressive Incrementals from IBM Corp.'s Tivoli Storage Manager and Synthetic Backups from Symantec Corp.'s Veritas NetBackup.
If, after using these techniques, you still have resource-contention issues inside the virtual server when you're backing up its guests, you should consider more advanced methods such as VMware Consolidated Backup (VCB), esXpress from PHD Technologies Inc., esxRanger from Vizioncore Inc. or using a snapshot-based filer that's VMware-aware.
[IMAGE]
[IMAGE] [IMAGE] [IMAGE] [IMAGE]
[IMAGE]
[IMAGE]
|
 |
|
