An old storage industry joke says that backups are useless -- it's the restores that everyone wants! But just who...
are these people making restore requests? And how can you adapt your retention policies to their unique needs? The nature of restores changes over time.
Short-term requests are likely to be made by the original owners or creators of the data. Unless you are relying on tape backup for disaster recovery (and you're not, right?), the only person likely to make a request for the restore of a file within the first few months of its deletion is the person who expected it to still be where they left it. These requests are likely to be very specific about which file is needed, and the requestor will probably also know the exact date that it was last available.
At the far end of the spectrum is the long-term restore request, which is almost always made for compliance reasons. These requestors, often lawyers and their clerks, will normally not know what they are looking for but might be quite specific about time periods. For example, they might ask for all drawings of a certain product as of December 1994.
Somewhere in the middle are the maintainers of systems. This group will give you nightmares, likely not knowing what they are looking for or when it was last available. They will ask to browse through file after file, looking for "that old code Rich mentioned before he retired.".
So, how can you deal with these different kinds of requests? Short-term restores are fairly straightforward -- just set a reasonable retention policy, matched to the general pattern of user requests. It can be simple to deal with the lawyers, too -- just keep a regularly scheduled archive of data, and make sure everyone knows what is and is not available. The middle case is the hardest -- how can you give someone what they want when they're not sure what it is?
About the author: Stephen Foskett is the senior consultant GlassHouse Technologies. Foskett writes the Best Practices column for Storage magazine and has done extensive work in SAN design and integration.