Obviously, having ready-to-use, easy-to-identify recovery points simplifies rebuilding a corrupted database.

"In case of corruption, a DBA can go back not to just any point in time before the corruption occurred, but can roll back to the exact point in time where there is a consistent image of the database," Walsworth says.

"We support also other databases," Walsworth points out. "But we have this tight integration only with Oracle, SQL Server, and Exchange."

What if disaster strikes just after a major business deadline -- say, the end of the month or the end of the quarter? How can you make sure that multiple databases are not only individually consistent but also synched at the same cutoff date?

Version R2.3 has that covered: With a single command, Walsworth says, users can tag multiple databases, essentially creating a virtual fence that identifies a specific date or business event. That fence helps during recovery but is useful in other situations, too, such as creating a separate environment to respond to auditors or legal queries.