Anthony,
Showing a build of 6421 does indeed indicate that SP2 is in-place. Just to make sure, I checked my own farm and VMs as well as a reliable external source (an entry from Todd Klindt's blog: http://www.toddklindt.com/blog/Lists/Posts/Post.aspx?ID=154). I didn't doubt the build number, but it never hurts to confirm :-)
At first, I thought I understood where the issue might be, so I ran some tests. First, I ran an STSADM backup in catastrophic mode to backup my entire farm. Since this isn't a site collection backup, no locking should occur:
stsadm -o backup -directory \\ss-nas3\backups\test -backupmethod full
My catastrophic backup ran without issue, and I didn't receive any message about a lock or read-only behavior. I looked at my ULS logs, as well, and confirmed that no lock was being established (searching for "sitelock" and "lock"). This was as I expected, as I was doing a catastrophic backup -- not a site collection backup.
Next, I tried a site collection backup:
stsadm -o backup -url https://www.sculpted-system.com/pictures -filename \\ss-nas3\backups\test\SiteCollectionBackupTest.bak
Strangely enough, I didn't see a locking message here, either. I took a look at the ULS logs, and I saw nothing to indicate that a lock was put in place. Finally, I performed an
stsadm -o getsitelock ...
... while the backup was running and was greeted with this:
<SiteLock Lock="none" />
ARGH! That's not what I wanted (or expected) to see! Clearly, there was a problem ... so, I tried coming at it from a different angle. I took a look at the MSDN documentation for the STSADM -o backup command, and it clearly indicated that a lock should occur by default. It also indicated that the -nositelock switch should work to override the behavior. So, I tried adding -nositelock to my site collection backup command line.
Guess what: it choked on -nositelock with a command line error (invalid parameter).
Doing an STSADM -help backup indicated that -nositelock was not a valid switch for my environment. None of the new switches I expected (e.g., -nositelock and -force) were present. It's as if my production farm was stuck in pre-SP2 with regard to backups.
I decided to check a development VM I had that was also build 6421 (but different image -- amongst other things, Win2K8 instead of Win2K3 R2), I saw that the -nositelock was a valid command line option. So I checked another development VM that was also build 6421 (but Win2K3 R2 like my "regular farm"). -nositelock was a valid option there, too.
I had applied SP2 the same across all three environments when upgrading (WSSv3 SP2 bits, following by MOSS 2007 SP2 bits, followed by a run of the configuration wizard), so I wasn't sure what was going on.
For fun, I ran a site collection backup on each of the VMs that correctly displayed that -nositelock was a valid command line switch for site collection backups, and I was met with the locking message I didn't see earlier (and that you weren't seeing, either). Clearly, the SP2 updates were operating as I expected them to everywhere except my primary (production) farm.
I concluded I must have somehow done something wrong as part of upgrading my farm, so I tried re-running the WSSv3 SP2 update (first) and MOSS 2007 SP2 update (second) on each box. With each update on each box, I was told the that the update had already been applied. So, I dropped back and punted: I re-ran the configuration wizard to see if it would do anything. I then rebooted the two (virtual) boxes in the farm.
No change.
At this point, I can only confirm that you aren't losing your mind. Two of my all-in-one development VMs with SP2 build 6421 operate as expected, but my two-server/VM farm that is build 6421 that should be locking on site collection backup is not.
I think I'll probably follow up with a friend who is a Microsoft TAM. If I learn anything, I'll post it here and probably on my blog. In the meantime, you might want to follow up with Microsoft, as well. Clearly, something isn't working as expected.
For what it's worth!