The most common problems with disk-to-disk-to-tape
Requires Free Membership to View
When you register for SearchDataBackup.com, you’ll also receive targeted emails from my team of award-winning editorial writers. Because your job never seems to get any easier, it’s our goal to keep you up-to-date on the latest backup tips, trends and technologies that will help you get the job done.
Rich Castagna, Editorial Director
(D2D2T) backup systems are related to performance. It's not that the system doesn't work; it's that it doesn't work well. Usually this means one of two things: Either the parameters, such as buffers, aren't set properly or your tape's performance is less than optimal.Here is a checklist you can use that can help you determine what may be malfunctioning in your system.
The Easy Stuff
- Check your tape drives
- Check your tapes
When the performance of a D2D2T product deteriorates, either suddenly or slowly, the first thing to check is the tape drives. At times, the drive needs cleaning, and because of this, it is forced to rewrite sectors. Cleaning the heads will often fix the problem.
A related problem is worn or poor-quality tapes. Try using new tapes from a major manufacturer and see if performance improves.
Tuning
D2D2T systems are inherently complex. That means they have a lot of opportunities for tuning -- and a number of places where improper settings can compromise performance.
- Start with your logs
- Pay attention to throughput
- Add data streams
- Adjust your buffers
You should leave logging enabled on all parts of the backup system. The performance cost is minor and the information in the logs is invaluable.
When you suspect a problem with your D2D2T system, inspect the device logs to see what is actually happening -- meaning, check the logs for the network connecting the backup disk array to the main disks and the network connecting those disks to the tapes, as well as the logs for the devices themselves.
Ideally, you should save a set of base logs containing 'normal' data that you can compare the current logs against. You can also find typical throughput parameters in the system's documentation. Use this information to narrow your search for the problem.
In theory, every section of the D2D2T system should be working as hard as it can.
The most critical throughput parameter is feeding information to the tapes. Tape devices are notorious for reacting poorly when data arrives too slowly. This can result in shoeshining and increased wear on the tape mechanism as well as poor performance. Of course, trying to feed the tapes data faster than they can absorb it will also cause problems for tape devices. Make sure that your system is feeding information to the tapes at the recommended speed.
Many D2D2T systems can handle multiple data streams between the primary storage, the backup storage and the tape devices. Additional streams can considerably increase performance by optimizing data flow. However, trying to handle too many data streams can reduce performance as well. Make sure you have the correct number of data streams to maximize throughput.
D2D2T systems have a number of buffers that can be used to match the throughput of the various parts of the system. The default buffer sizes are set by the vendor or system integrator to match the expected loads. However, if your system's loads are unexpectedly large, or especially bursty, the buffer sizes may be inadequate. Increasing buffer sizes can even out the flow of data and make the system perform better.
A word of warning, though: Increasing the buffer sizes can mask problems as well as solve them. Buffers are only there to handle temporary mismatches in data flows. Always try to understand the conditions that cause you to need to increase the buffer sizes and correct the underlying conditions if possible.
Do you know…
How to architect tiered backup with D2D2T?
About the author: Rick Cook has been writing about mass storage since the days when the term meant an 80 K floppy disk. The computers he learned on used ferrite cores and magnetic drums. For the last 20 years, he has been a freelance writer specializing in storage and other computer issues.
This was first published in April 2006