In my experience it's good to have a few different restore attempts running in parallel, so long as they won't conflict with one another. For example, the resto

In my experience it's good to have a few different restore attempts running in parallel, so long as they won't conflict with one another. For example, the restores may be to different hardware, from a different point-in-time, in a different datacenter, or from a unique backup system (image-based, file-based, transaction logs only, etc). One of their "restore" attempts could even be a scan of the original disk for recoverable data, though that seems unlikely. In a critical outage like the one Gliffy is experiencing, I take the same approach. Outline all your restore options, estimate time for each restore, drawbacks of each approach, etc and take every available angle. If you want to know how the database was deleted, read through some of the horror stories posted in the comments here and assume it was probably one of those!