Delegate restores to save admin effort
Say "restore" and most of us think of restoring the entire file system, either locally or at another site. From a storage administrator's point of view it makes sense to think in terms of such emergencies since that is the worst-case scenario. However, most of the time the entire file system, or even the complete LUN, doesn't need to be restored. In the modern storage environment the most common cause of lost or corrupted files is accidental deletion, followed by corruption of a single file or part of a file. In those cases it makes more sense to let someone else do the restoration rather than directly involving the storage administrators.
LAN administrators are usually the first group to be granted limited restoration privileges since they possess some technical knowledge and are directly concerned with the performance of their LAN. Since they're also usually the first ones the users complain to when they can't access files, having them handle restores cuts down on the bureaucratic overhead of doing a restore.
If permissions can be adequately limited, individual users can do restores on their own files. With modern storage management software, restoring a file is often as simple as a single mouse click. Delegating permission to users has a psychological advantage as well, since the user who accidentally deleted the file doesn't have to admit his or her mistake to someone else.
In delegating restorations, it is important to match the granularity of the permission to the scope of the files involved. For example, you don't want to give individual users the ability to restore all the files in a work group. It is also important to keep permissions up to date so they match the current scope of the would-be restorers' job. Modern storage management software usually contains multiple permission levels for restores, allowing administrators to give others the power to handle limited parts of the restoration. Often these permissions to restore can be changed automatically as file permissions are changed.
Whoever does the restore, it's important that the storage administrator know about it. A corrupted single file may indicate that there are bigger storage problems ahead. Information on restores should be included in the systems daily report to the storage administrator.
While delegating restorations may be a good idea, it isn't always possible. Some storage management products that use snapshots to keep a nearly current image of the file system effectively can't be set up to allow users to do their own restores. Before attempting to implement delegated restores, be sure to check your software's documentation to see if they will work with your configuration.
Tivoli discusses this and other storage management practices in a white paper entitled "Storage Management Best Practices" available on the IBM web site. Maxtor discusses its use of the feature at www.maxstor.com/products/maxattach/products/NAS_PersistentStorage.htm.
Rick Cook has been writing about mass storage since the days when the term meant an 80K floppy disk. The computers he learned on used ferrite cores and magnetic drums. For the last twenty years he has been a freelance writer specializing in storage and other computer issues.