Patching: Using a RAID 1 configuration to test patches?

I came across an interesting post about patch testing that I thought deserved more attention. The question seemed reasonable enough… effectively, “Does it make sense to use a RAID1 configuration for patch testing and roll-back?” (Or, in other words, pull a hard drive out of the RAID 1 configuration and use it as a roll-back option if something blows-up).

Well, the short answer is that microsoft.public.windows.server.sbs seems to say “No”.

Skim the thread… there were some reasonable alternative suggestions in there about third-party solutions; cloning, livestate backups, and the like. And some good observations about the potential risks of reverting back to an older DC image (that might be worth further discussion). But when it comes down to it, no one liked the idea. And what concerns me is that I’m not sure why.

Can it be tedious?
Sure.

Is it high-risk?
Maybe. Certainly if you haven’t tested it, and created a procedure it’s high-risk.

But is it a bad idea?
I don’t know.

This is just the thing I think an SMB customer would go for. They’ve already paid for the RAID controller and SCSI hard drives, why not leverage them? Why not develop a procedure, and use it when testing things like SP1, Exchange SP2, and the like.

I want to say that it seems like a viable solution.

What do you think? What would be a good patch-testing methodology that allowed for a reproducible roll-back scenario that an SMB-sized customer could get behind?