Post reply

Unable to restore from backup

  • December 28, 2009 at 2:14 pm

    #141385

    Hi

    I had a corrupt disk which had to be replace, I copied the backup files from my backup source and tried to restore the database but got this message

    File '<Path>.mdf' appears to have been truncated by

    the operating system. Expected size is 38387840 KB but actual size is 38386816

    KB.

    Anyone got an answer to fix this, you would quite literally be saving my life!!!

    Thanks

    Matt

  • December 28, 2009 at 2:38 pm

    #1096833

    are you doing full restore?

  • December 28, 2009 at 2:43 pm

    #1096835

    yes

  • December 29, 2009 at 12:07 am

    #1096917

    Looks like you're trying to restore over the existing database. Don't. Drop the corrupt database and restore the new one from scratch.

    Post the restore command that you're using.

    Do you have an older backup, just in case this one is damaged? Did you test the backup when you made it?

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass

  • December 30, 2009 at 2:27 am

    #1097356

    GilaMonster (12/29/2009)

    Looks like you're trying to restore over the existing database. Don't. Drop the corrupt database and restore the new one from scratch.

    Post the restore command that you're using.

    Do you have an older backup, just in case this one is damaged? Did you test the backup when you made it?

    Hi Gail

    Thanks for your suggestion, I tried restoring a new one from scratch, it got about half way and then came up with an error message to say something along the lines of the mdf file was corrupt.

    I have now managed to restore from a backup wich is unfortuantely about a week old, but I guess it's better than nothing

  • December 30, 2009 at 8:19 am

    #1097469

    Matt-1034261 (12/30/2009)

    GilaMonster (12/29/2009)

    Looks like you're trying to restore over the existing database. Don't. Drop the corrupt database and restore the new one from scratch.

    Post the restore command that you're using.

    Do you have an older backup, just in case this one is damaged? Did you test the backup when you made it?

    Hi Gail

    Thanks for your suggestion, I tried restoring a new one from scratch, it got about half way and then came up with an error message to say something along the lines of the mdf file was corrupt.

    I have now managed to restore from a backup wich is unfortuantely about a week old, but I guess it's better than nothing

    .... which only proves the point that backups are only as good as you are able to restore them... I guess a more regular testing to restore can avoid these types of problems..... or at least minimize the impact.

    Good for you that a week old backup is "good enough". In our environment, a few hours "lost" would be very bad......

    _______________________________________________________________________
    For better assistance in answering your questions, click here[/url]

  • December 30, 2009 at 9:11 am

    #1097508

    Yup. We do constant logshipping and DB restores to local warm standby servers and also to a DR site. Any failure to restore a log or a database sets off an alert so we can fix it right away.

    Restoring the db and/or logs as soon as they are created is the only way to 100% insure that they are usable.

    The probability of survival is inversely proportional to the angle of arrival.

  • December 31, 2009 at 12:28 pm

    #1097997

    Matt-1034261 (12/30/2009)

    Hi Gail

    Thanks for your suggestion, I tried restoring a new one from scratch, it got about half way and then came up with an error message to say something along the lines of the mdf file was corrupt.

    I have now managed to restore from a backup wich is unfortuantely about a week old, but I guess it's better than nothing

    Do you not have transaction log backups that could be applied to your week-old full backup ?

  • December 31, 2009 at 2:34 pm

    #1098019

    hmmm

    Some times in these cases Continue_After_Error option will be work.

    Basically database restore process will continue when we use Continue_After_Restore it instucts backup to continue despite of encountering the error such as invalid checksums.It is commonly used when database is damaged.

    pls let me know if it works

  • December 31, 2009 at 2:36 pm

    #1098020

    hey needs to be performed by using T-SQL method.

  • January 4, 2010 at 1:52 am

    #1098304

    homebrew01 (12/31/2009)

    Do you not have transaction log backups that could be applied to your week-old full backup ?

    One of the problems was that the log files were changed to a different drive some time ago, umnfortuantely the back up was not updated with this new location so it was in effect backing up an old log file

  • January 4, 2010 at 1:54 am

    #1098305

    Rajesh M S (12/31/2009)

    hmmm

    Some times in these cases Continue_After_Error option will be work.

    Basically database restore process will continue when we use Continue_After_Restore it instucts backup to continue despite of encountering the error such as invalid checksums.It is commonly used when database is damaged.

    pls let me know if it works

    I had some guys helping me out on this and I believe that this is what they did to eventually get it to work

Viewing 12 posts - 1 through 11 (of 11 total)

You must be logged in to reply to this topic. Login to reply