What are the limits of data protection management?
Should it report on all data copy operations with a protection aspect?
What are the limits of data protection management (DPM) and its reporting? WysDM is one of the leading DPM vendors; others being Aptare, Bocada and Severgraph. Techworld asked Jim McDonald, WysDM CEO, questions about DPM, where it is going, and how WysDM will get there.
TW: What is your view of the data protection reporting/management needs of your customers now and going forward?
JM: WysDM believes that DPM is a key requirement for every company. If you look at the financial world of a company it has its own accounting team carrying out day-to-day work, however there is also a separate and independent (legally-required) audit carried out at regular intervals to ensure that the financial health of the company is good.
We believe that DPM has a similar role in the data protection activities of a company; a company that fails to protect its data must be considered a massive risk for investors, as has been seen by the number of companies that have suffered from significant data loss and failed to recover.
However, DPM is a much more immediate and hands-on presence within a company and can point out problems, current or potential, with a company’s data protection strategy as they are found. It also provides the ability to optimise the existing environment and provide a firm basis for additional purchases, increasing the operational efficiency of a company’s data protection activities at the same time as ensuring they meet internal and external requirements.
One key aspect that customers are finding more important is to be able to provide business-based information. For example, the ability to provide a report that shows the data protection status of specific applications, business units, critical systems, systems with specific regulatory requirements, etc. is more important to both the company and its auditors than lists of servers and their protection status. The ability for a DPM application to turn the purely technical information of server names in to these more useful categorisations is called business-awareness. (See white paper here)
Finally, although reporting is an important area for customers they need something more pro-active to help them meet their data protection requirements. This is where WysDM’s Predictive Analysis Engine (PAE) comes in to place. The PAE acts like an intelligent operator, scanning the backup infrastructure and processes 24x7 to pick up problems and potential issues and alert operations staff before the issues become breaches of data protection policies. This automated and intelligent system is proving of massive value to customers, especially the larger ones, as it allows them to keep control of their data protection environment without the requirement of hiring and retaining a large number of staff to then carry out what are fundamentally repetitive checks on the infrastructure and how the changing data protection needs affect the infrastructure’s ability to ensure data protection. Long-term, customers migrate from looking at reports to letting the PAE alert them when specific situations occur.
TW: Should a DPM reporter cover all data protection operations? E.g.snapshots, mirrors, replication (async and sync), fixed content reference storage (like EMC Centera, HP RISS), backup to virtual tape libraries, all backup software products, backup to tape autoloaders, backup to tape libraries, off-site electronic vaulting, archive to optical media and devices (e.g. UDO), file archiving, e-mail archiving, database archiving, encrypting data, fixed content data to a content-addressed store or similar.
JM: I think that we have to break this list into three categories. The first are what are traditionally known as backups. These are:
- Backup to virtual tape libraries
- Backup – all backup software products
- Backup to tape autoloaders
- Backup to tape libraries
- Off-site electronic vaulting
- Archive to optical media and devices
The second are items we would not consider data protection of any sort as they are involved with moving or modifying data but not adding any additional protection beyond what was present before. These are:
- File archiving
- Email archiving
- Database archiving
- Encrypting data
- Fixed content reference storage
The third is a grey area and really depends on what you want to include in data protection. For the purposes of our conversation I’d say that these technologies are not data protection, as they do not create an independent physical and logical copy of the data. However, some implementations of these technologies can provide the ability to separate or break the target copy of the data so that it can become independent, at which stage it can be used for proper data protection. These are:
So I would say that, yes, DPM should cover all of the areas of data protection but we do need to be clear on what data protection is. In addition, there are two separate focuses of DPM: the processes leading to the protection itself and the infrastructure used to provide the protection. The former is the focus for service level agreements, compliance, risk, capacity planning etc. and the latter is the focus for asset management, resource utilisation, operational status, performance, etc. A DPM product should provide both, but the focus for this conversation is on the former.
(WysDM includes archiving to optical media and similar devices as a data protection operation but excludes email and database archiving, also fixed content reference stores.)
TW: Does your DPM software product cover all the areas listed?
JM: WysDM covers all of the product areas listed in the first category above. It covers approximately 90 percent of the existing market of backup applications (in terms of penetration rather than number). It also covers those listed in the third category, both those that remain dependent and those that become independent. Again, these are for a majority of the market but not for every single product. WysDM does not cover any of the products in the second category, for the reasons given already.
TW: What is the product development strategy for WysDM?
JM: DPM is evolving along two lines: functionality and scope. In terms of functionality DPM is looking to move from backup reporting in to analytics, process optimisation and data protection planning. WysDM is already much farther along in these categories than any other product within the space. In addition to the foregoing DPM is also evolving in scope as new data protection products are made available; CDP (continuous data protection) was the last set of products to require DPM but as more data protection methodologies, technologies and products emerge this will continue to expand.
WysDM plans to ensure that it continues to cover the majority of data protection applications through simple support as well as partnerships and OEMs.
WysDM believes that its DPM product needs to cover as many of the data protection products as required to ensure that it can provide complete DPM functionality for all of its customers. The flipside of this is that if WysDM does cover all of the data protection products that a company uses then it can provide complete DPM functionality for that given company, and WysDM achieves this for the majority of its customers today.
TW: Are there specific problems in these various data protection operations that hinder your DPM product reporting on them?
JM: No. Easier API-level access is always preferable as it decreases the time taken to obtain data from the application but there is nothing that is actually stopping us from gathering the data if we are willing to put some effort in.
TW: Does DPM have to evolve into uDPM (universal DPM) so as to cover all the electronic data protection activities of an enterprise?
JM: I would not differentiate between DPM and uDPM in the same way that I would not say that there need to be ubackup products because existing backup products do not carry out real-time backups of all object-oriented databases. WysDM will continue to expand its support of data protection methodologies, technologies and products as they themselves increase.
(Our idea of a uDPM product was based on the presupposition that data protection included file archiving, email archiving, database archiving, encrypting data and fixed content reference storage which Jim McDonald has ruled out from WysDM's concept of what DPM covers.)
TW: Does DPM need an enterprise-wide data protection policy?
TW: Does it need a standard interface (APPI) to all data protection hardware and software products rather than product-specific interfaces?
JM: It would be nice but is not today a realistic possibility. Each product attempts to differentiate itself in both theory and practice of operation; this means that even if a standard were introduced and accepted it would be a lowest-common-denominator standard and not useful to capture the important details of each product
TW: If a standard interface was needed should this interface be the SNIA's SMI-S?
JM: It would be nice if there were a simple interface such as SMI-S as the value of DPM is not in the gathering of the data but the way that the data is presented, interpreted and analysed. However, there is no sign that SMI-S is looking to move in that direction. WysDM is a member of SNIA and is talking about the potential of an SMI-S schema that covers data protection, however this is still in the early stages.