There is not much upside potential to employment prospects if drastic changes are made to backup procedures. “If it ain’t broke, don’t fix it” is and always will be sound advice. Even more so when the data is mission critical and introducing change increases risk to the business.
Sometimes change is inevitable, and this is likely to be the case with VMWare initiatives. Backup processes that worked fine with “physical=logical” environments do not work as well with VMWare's logical server environments. For example, instead of restoring just the application, the VMWare process may require restoring the operating system as well. To avoid this, backup system agents may have to be deployed – that will probably bring in its wake disruption to the current processes and a requirement to re-architect and retest the backup and recovery system. Traditional target-based deduplication will not help at all in speeding up backup and is likely to increase complexity in a changing environment.
Given that change is “thrust upon you”, it makes sense to re-evaluate the backup software and processes used and see if consolidation or a different backup model is more appropriate. If the servers and storage in the VMWare environment are supporting small databases and have low change rates (often the case with Windows-based unstructured data systems), source-based technology may be more appropriate.
Action Item: Storage executives should take a long hard look at backup procedures well before VMWare initiatives go into production. Consult with the current backup software supplier and evaluate the alternatives. This may include waiting for a new release. Test the optimum alternative. If required, bring in alternative vendors including source-based deduplication. Being part of the solution will optimize employment prospects.
Footnotes: