• john.round - Friday, August 18, 2017 2:47 AM

    Many thanks for the replies,

    We do have good backups of the database and Full recovery mode on the DB so hourly transaction logs are generated, so is it a case of restoring the last known good 'full' database backup then restore all the transaction log files after this point up until the most recent in time? (Not had to do something like this in a very long time!) 🙂

    Yes, that's it:
    1. Restore from last known 'good' backup.
    2. Restore every transaction log backup taken since then, including taking log backups from the corrupted database before shutting it down.

    Please continue taking transaction log backups on the damaged database while you prepare your restore. It has suffered significant loss, but you can recover everything, including capturing all changes made to the database, if you keep taking log backups.

    Disk corruption on  data files (at least the kind shown in your CHECKDB output) is not written to the transaction log, unless the log file got damaged in the incident. Because the transaction log does not contain the instructions on how to cause the damage to the data files, restoring from a full backup taken before the incident and using log backups from before and after the incident won't include the damage.
    If there was damage, but it occurred to an area of the log that had already been backed up, there will be no data loss.

    If the event also wiped your backups, then you're pretty much out of options.

    Eddie Wuerch
    MCM: SQL