Search Current Space

Version 6 by David Wartell
on Oct 12, 2008 18:53.
<< Changes from 5 to 6
compared with
Version 7 by Jennifer Bolduc
on Jan 05, 2009 09:38.
Changes from 7 to 8 >>
Key
This line was removed.
This word was removed. This word was added.
This line was added.

Changes (11)

View Page History
...
# AND The flexibility to select what files and folders were included in their backup sets just like they had always done with their [Legacy File-Based backup software|TP:Categories of Backup Software].

Geez talk about wanting to eat your cake and have it too\!&nbsp;

Everyone including myself said it was not possible or too hard and too prone to error.&nbsp; How could we exclude files and still have a consistent low level file system image?&nbsp; We always thought that to gain the advantages of CDP and disk imaging you had to back up a Disk or Volume all or nothing.

h3. A Very Simple Idea
...
It was spring of 2008.&nbsp; Late one evening while sitting around with Mike B. and Brian V. (aka Brain) in our development room tossing around ideas Brain said, _"David your ideas are all too complex.&nbsp; If we exclude files from the block level backups our method has to produce a perfect file system image.&nbsp; And it has to be easy so we don't mess it up.&nbsp; File systems are way too complicated for us to mess around with them excluding blocks.&nbsp; We need to let the O/S do the excluding for us."_

But how would this be possible I thought?&nbsp; In Linux we take a point-in-time block level consistent snapshot of the disk while the server is running using the R1Soft CDP device driver.&nbsp; And in Windows we combine our [near-Continuous delta computation method|TP:Computing Deltas - near-Continuous (CDP)] with Microsoft Volume Shadow Copies.&nbsp; Microsoft VSS give us consistent block level snapshots.&nbsp; We combine VSS with our own Volume filter driver in Windows to tell us what the deltas are in-between backup sets before the backup starts.&nbsp; This means the difference between a backup window that takes 8 hours v.s. one that takes 8 minutes.

I knew that Windows standard Win32 APIs can tell us what blocks or sectors belong to a file.&nbsp; Windows made this API for file system defragment applications.&nbsp; We could exclude the blocks belonging to the files that the user wanted to exclude and the Win32 API could tell us what those blocks were.&nbsp; The challenge with this way of doing things is that it leaves the file system in a broken state.&nbsp; I didn't like this and neither did Brain.

Brain continued, he said, "*{_}You know.&nbsp; If we could some how just make a Volume Shadow Copy WRITABLE it would all be fairly simple._*&nbsp; *{_}The same for our Linux snapshots{_}*", he continued.&nbsp; _"If our snapshots were writable we could just use standard file API calls like delete or unlink to remove the files we didn't want.&nbsp; Then the O/S (Windows or Linux) would take care of modifying the file system to remove the unwanted files form the snapshot image in a way that was perfectly consistent and it would all be very fast.&nbsp; If the user wanted to exclude an entire directory for example we could just recursively delete that directory from the snapshot.&nbsp; This would be very fast since delete operations involve VERY FEW disk writes.&nbsp; Since the actually writes to disk are so few when deleting even large sets of files we could potentially store all of those Writes in RAM making the exclude operation fly."_

Well great I thought.&nbsp; All we have to do now is re-write our Linux CDP snapshot device driver so it could some how make a snapshot writable.&nbsp; AND some how we had to trick Windows into making a Volume Shadow Copy writable\!&nbsp; Oh My.&nbsp; Not trivial.
...
h3. It Might be Possible in Windows

The next day I emailed our Windows device driver wizard.&nbsp; I told him we needed to some how trick Windows (XP through 2008) into making its read-only Volume Shadow Copies writable\!&nbsp; The email I got back said, "Wow that sounds like a challenge.&nbsp; It would be amazing if we could do that but I don't know if it's possible.&nbsp; Let me do some research and I'll get back to you."

Two months later he got back to me.&nbsp; He said there was still a lot of risk but that he thought he may have found a way to do it.&nbsp; It would require a new device driver capable of hooking-in below the file system (in the VSS snapshot) and above the Virtual Volume Shadow Copy Disk.
...
In the spring&nbsp; we had already begun work on a new Linux Device driver.&nbsp; We decided that we would make it a requirement to incorporate writable snapshots into our new Linux CDP device driver.


h3. Two new Drivers and a Hurricane&nbsp;

In September of 2008 a category-2 hurricane went ripping through down town Houston.&nbsp; Power was out for a month in some areas and curfew was declared in the city of Houston with the down town area looking like a war zone with all of the damage.&nbsp; R1Soft scrambled to set up an emergency base of operations at the Hotel Zaza and employees gathered at the homes of other employees with power to keep R1Soft open for business.

During all of the madness I got an email from our Windows device driver wizard.&nbsp; Writable VSS Snapshots were Alive\! It took 2 months longer than planned but they were here and worked well.&nbsp; Not only could they handle the light disk I/O required for large scale deletes they could handle large scale writes almost as efficiently as the real disk.&nbsp; We now had writable Volume Shadow Copies\!


Even better I learned that because of where we hooked into the Windows kernel this new Windows driver could be installed without a reboot.&nbsp; Even better I thought\!


Two weeks after the hurricane I got more good news.&nbsp; Mike B. had completed our new Linux CDP device driver.&nbsp; Written from the ground up it had massive performance and scalability gains over and above our 2.0 CDP driver.&nbsp; We learned from all of our mistakes and did it all over again.&nbsp; Even better it delivered a virtual block device that was readable _and writable_\!&nbsp; An instant point-in-time copy of hard disk while Linux was running\!&nbsp; It was a virtual block device that looked just like the real disk and we can read and write to it.&nbsp; Not only that the new virtual hard disk was lightning fast.&nbsp; Twice as fast in some situations as our 2.0 Linux driver.

h3. What's Left?

As of October 2008 we still have some work ahead of us before we are done with incorporating file and folder excluded in our 3.0 product.&nbsp; Now that we have the special device drivers we are working on incorporating them in our 3.0 CDP product.&nbsp; Thanks to the magic of our device drivers and writable snapshots it's almost as easy as find, then delete\!


h3. &nbsp;