The term "Information Lifecycle Management" or ILM was introduced in about 2001 and was widely touted as the product that was going
to revolutionalise the storage industry. Various storage software vendors advertised ILM products and offered consultancy agreements
to help you classify your data and install ILM, yet no-one really knew what ILM was, or at least no two companies could agree on a
defintion.
Now, in 2006 we can pretty much agree on what ILM is and what it should deliver.
The key to ILM is understanding that the value of data changes with time, and that regulations exist that govern how long data
must be kept for, how secure the data store must be, and when the data must be deleted. These values will be different for different
classes of data.
ILM then involves grouping data types into business importance classes, then defining data management polcies for each class that
govern how long the data will be kept, where it will be kept and when it will be deleted. These policies are then translated into software
rules that are used to move data around the storage heirachy, retain it and delete it. This final phase is called the data lifecycle.
Another way of defining the difference between ILM and Data Lifecycle is to say
ILM is about managing data as a business asset, while Data Lifecycle is about managing data as an IT cost.
The diagram below shows the main components of the Data Management Lifecycle. These are also explained in the text below.
Allocate The file must be created on the correct type of storage, for it to get the required performance and protection policies.
Backup The file must be backed up according to predefined policies, which dictate how often the file will be backed up, and how many backups versions will be retained. The policies may also dictate where the backups will be kept. Backups may be a combination of continuously mirrored offsite copies, and point-in-time snapshot copies. Backups are usually recorded in a database to make recovery easy.
Restore If the file becomes corrupt, it must be possible to restore it from backup. Remember, RECOVERY is what backup is all about! The recovery process needs to be granular enough to cope with systems, disks, applications and individual files. It may also be necessary to go back a few days to get a good version of the file. Recovery is usually semi-automatic.
Migrate When the file is first created, it usually needs to be kept on fast access disk as it is used frequently. After a while, the file becomes stale, and can be moved off to less expensive storage with a slower access speed. Migration is the process of transparently moving a file up and down the storage pyramid, so it is kept in the correct place for its current value. However, the file must be accessable at all times.
Recall When a migrated file is needed again, it may be automatically retrieved back to fast storage. This process should be transparent to the user, except that the retrieve may take longer.
Disaster Recovery In a disaster, the file must be recoverable to different hardware in a different site. Of course, disaster recovery involves a lot more than just retrieving data. Hopefully, this will just involve creating a copy of the data at regular intervals, to test out the disaster recovery process.
Archive Backups are typically short term copies of a file. An Archive is usually a copy of an application, taken for legal reasons, and retained for several years. An example of this is tax year end records. Archives are usually recorded manually. It will be necessary to take copies of more than just the data, to ensure the data can be read again in several years time.
Retrieve If the archived file is required again, it will usually be recovered to a different location, and not restored over the original data. Retrieve is usually a manual process.
Delete The file should be retained for as long as it is needed, then deleted. This will be governed by legal requirements. The backups must be deleted too, but the latest backup may be kept for a while as ‘insurance’.