 |
|
Evan Marcus
|
|
 Evan Marcus is our expert in high availability. Evan is also a Principal Engineer at Veritas Corp..
If you have a question for Evan, enter it here.
Also, if you are looking for more on high availability, view more of Evan's expert answers.
|
|
|
In Part 1 of this series, we introduced the idea that implementing availability requires taking a layered approach, and in Part 2 we discussed the first layer of the availability index, good system administrative practices. Figure 1 reviews that layering.
I often find myself pulled into the debate on whether or not backups are an element of high availability. My answer is always the same: Absolutely they are. Backups are your last line of defense between your data's being damaged, and your data's being lost forever. The recovery time if you have backup tapes that you can restore from is much less (hours or days) than it would be if you didn't have backup tapes to restore from at all (forever). Since the presence of backup tapes decreases your downtime, backups increase your availability.
This tip will discuss a technology that can speed up both your backups and restores. Most technologies that can speed up backups will slow down restores, and vice versa. With one notable exception, all of the tips that can speed up backups will slow down restores, and vice versa.
Try this exercise: Go onto one of your critical and regularly backed up systems that has been around for a year or two, and run a search for all files that have not been accessed (read or written) in over a year; make sure your output includes file sizes. Chances are you'll find quite a few, and that they represent a large amount of storage space. Every byte in every one of those files gets backed up when you do a full backup. Each and every time you perform a full backup, these untouched files all get written to tape again, wasting tape space, network bandwidth, and time.
You can solve this problem with a technology that's been around for years called Hierarchical Storage Management. HSM takes these old files, and migrates them to alternate storage, where they remain available, almost transparently to the user community. The only difference is that the first time a user tries to access one of these migrated files, there will be a delay, as the file is located on its new medium. After the first access, the file is restored to its regular storage location, and access times return to normal. A small (less than 8K Byte) stub file that points the file system to the file's new location replaces the original file. This alternate storage could be other -- cheaper -- disks, tape, optical drives, another system where storage is cheaper, or almost anywhere else files can be stored.
HSM will also speed up restores by prioritizing them. The files that are actually part of the backups will be restored to the file systems first, along with the stubs. If the storage that the stubs point to is not available as quickly, that is most likely not a big deal since those files had not been accessed in some time, and are presumably less critical to the business.
An additional benefit of HSM technology is that your file systems and disks will go much farther than they did before. 10G Byte file systems can appear to hold 15 or 20G Bytes, depending on configurations and how much data gets migrated. Good HSM software will allow the administrator to set up policies that determine which files get migrated and how often.
I believe that HSM is not commonly used because of the perception that it is old technology, having originated on mainframes. With larger file sizes and larger disk sizes, HSM is surely no less valuable today than it was years ago.
Copyright 2002, Evan Marcus
