CDP, CAS, Audit, Time Travel, and Old Friend

It was great to see an old friend, Bill Bowerman joining the “Blog” trend by publishing his thoughts at ComputerWorld. At one time, Bill and I were colleagues at KOM Networks. In his blog, he wrote an interesting piece on CDP that resonates with me, having lived through the buzz of Virtualization, ILM, SAN Security and now CDP.

Also, his idea about CDP using WORM Optical solution reminded me of my discussion with him last July, outside Hilton in Downtown Toronto. I was reminiscing about how Content-Addressable Storage (CAS) vendors are claiming compliance with regulations by preventing the deletion of data from their storage. But none of CAS solutions can offer the “true” delete prevention and audit capability offered by the WORM Magneto-Optical (MO) and Optical disks.

In my opinion, preventing deletion of data is only one-fourth of the ‘audit’ equation for regulatory compliance, another one-fourth is the ability to prove the integrity of data in question, another one-fourth is ability to track any modifications made to the data in question, and last one-fourth is ability to see the modifications actually made to the data in question.

And the time travel capability can offer this ability to see chronologically the modifications actually made to the data. We talked about how the vendors who offer time travel capability on MO/Optical disks are missing a great opportunity by not extending this capability to magnetic disks.

As for CDPA (Continuous Data Protection & Availability), I believe there are easier way to achieve CDPA at both File level and at Block level.

File level CDPA is pretty easy to understand for anyone who has used DEC VMS which had versioning and journaling to achieve CDPA at file level. Of course at that time we didn’t give it fancy acronyms like CDPA. I got introduce to these features over a decade ago when I was working at Dow Chemical Company.

Versioning was great as every time a file was saved, VMS saved it with same name but incremented the version number (ex: WORD.TXT;23). So if we ever needed to discard the changes we made between two versions, we just needed to open the older version (ex: WORD.TXT; 15) and resave. Of course, those days storage capacity wasn’t plenty from today’s standards and we always complained about old versions taking up precious space. Almost everyone had a DCL script to delete old versions regularly to recover space.

Journaling offered the capability to recover changes we made in a file but lost them due to some failure before we could save the file.

I guess today’s File level CDPA will be some sort of versioning and journaling.

It may be easier to accomplish Block level CDPA by extending the current Snapshot technology. There are two components to storing data on any block level data storage device:

1. The blocks where the actual data is written, and
2. The blocks where pointers (metadata) to the actual data blocks are written.

Current snapshot technology only tracks the changes in the content of actual data blocks that need to be overwritten and then updates the pointers.

So how do you achieve CDPA using Snapshot technology? You are not going to get to true CDPA just by reducing the time interval between two PIT snapshots, as rightly pointed out by Bill. But you can achieve CDPA by continuously tracking the changes in pointers (metadata) blocks in addition to changes in actual data blocks.

I most probably need to further explain this CDPA concept in another blog entry as I need more time to draw a illustration explaining this concept.