Here's a tidbit for those who might have SQL server in their environments, maybe without knowing all the nitty gritty low-down: if you try to use file system replication (robocopy, xcopy, repli-whatever) to maintain a DR server from your production SQL Server, you might be in for a nasty surprise.
I recently had to troubleshoot a scenario like this: the app owner came to me and said, "the DB on our disaster recovery system is in suspect mode, what should we do? (and what happened?)" I immediately went to disk corruption, etc., but it turns out the issue was really simpler: it turns out there was nothing wrong with the machine other than copying files onto it.
Huh?
Yes, copying files had corrupted the database. Here's how:
The (well meaning) group involved had established replication of files from a production server to this failover server, thinking about disaster recovery. For almost all "vanilla" files, this works great. In practically all other cases outside SQL Server, each file is a separate entity, working alone. If the file is unlocked at any point in time, then it's pretty safe to copy it off to another server.
SQL Server databases, however, are always composed of at least two separate files that work together: the data file and the log file. In addition, those two files are typically locked whenever the SQL Server service is running and has them open. Two issues with file replication, then: the database files are always locked, so they probably won't get replicated very often, but more importantly, you have to copy both of them at the same time to end up with a working database at the other end of the process. If the log and data files log sequence numbers (LSN's) don't line up, the recovery process doesn't work, and the database will not function.
What I think happened with my app owner is this: the source system and destination went offline for a brief period (probably patching), so the original MDF and LDF files were unlocked. The replication thingamagig managed to pick up and copy the small log file but not the big data file to the its target server. When the target server's SQL Server service fired up, it found a mismatched log and data file, and so, of course, failed recovery and would not bring the DB online.
The takeaway - SQL Server has great technology for disaster recovery, including the simple/basic log shipping method. Copying raw files from disk, however, won't give you DR!