CJL's comments about ORACLE reminded me of the time we were first implementing our Navy COOP solution (Continuity Of Operations Procedure) that involved nighttime backups that started about 0200 and ran until they finished, usually about 0530 to 0545.
The ORACLE gurus had indicated that for maximum stability of operation, we would do better to have our DB (back-end) files distributed on several smaller disks rather than one big file on one humongous virtual disk. Since we were using network-attached storage that was based on virtual drives anyway, it didn't matter to the NAS managers. However, this had the side effect of increasing the amount of time required to perform the backup.
So in October 2002, we had a minor hurricane come through New Orleans and we "flew the COOP" so to speak. I hadn't implemented the backup solution; we did what the NAS guys had said to do. I told them we hadn't tested restoration and that, on reflection, I didn't think it was going to work. The problem was "mixed instantiation numbers" or non-consistent ISNs, as ORACLE called it. We took a snapshot of a "moving target" and the target was moving faster than the snapshot mechanism - so the image blurred, metaphorically speaking.
I remember getting into a techie argument with Vance, the NAS rep, over whether we would be able to recover. I bet "NO" and he bet "YES" with the stakes being steaks. Winner bought the loser a steak dinner at the Ft. Worth "Cattleman's Restaurant." He bought me a really nice rib-eye, by the way, medium-well with baked sweet potato and mixed veggies. Yum!
That is as close as we ever got to a "corrupt database" with ORACLE. However, it is probably a decent analog for what happens to an Access back-end that becomes corrupt. In essence, it becomes internally de-synchronized.