Search

GUI restore fails when restore point falls in between differential backup by EugeneChen

Closed
as Won't Fix Help for as Won't Fix

3
0
Sign in
to vote
Type: Bug
ID: 776292
Opened: 1/10/2013 2:21:02 PM
Access Restriction: Public
0
Workaround(s)
0
User(s) can reproduce this bug
Recently we discovered a problem with the GUI when trying to restore a database to a point in time. The time happens to fall in between the start and end time of a differential backup. To make it clear, say the differential started at 5PM and take 10 minutes to complete. Our requested restore point is 5:01 PM. The GUI generated script suggest we do Full restore, Differential that started at 5PM then the first Log after the Diff backup. However, most of the time we encounter this error

Msg 4335, Level 16, State 1, Line 2
The specified STOPAT time is too early. All or part of the database is already rolled forward beyond that point.
Msg 3013, Level 16, State 1, Line 2
RESTORE LOG is terminating abnormally.

if we restore the log file without the STOPAT, then the restore can recovery the database.

We can work around it by forcing the restore to start from the previous differential backup and then all the Logs in between until the last one that contains the restore point.

This problem happens for both SQL 2005 and 2008R2 servers we tested, however, interestingly, we find the GUI generated script differ slightly in that a "STOPAT" is used in both the Differential and Log restore commands for SQL 2008 version.

I am wondering if this is a long term standing bug with SQL Server.
Details (expand)

Product Language

English

Version

SQL Server 2008 SP2

Category

SQL Engine

Operating System

Not Applicable

Operating System Language

Not Applicable

Steps to Reproduce

described in "description" section

Actual Results

Restore fails

Expected Results

correct sequences of backup files should have been picked.

Platform

 

Virtualization

 
File Attachments
0 attachments
Sign in to post a comment.
Posted by Microsoft on 2/19/2013 at 3:30 PM
Thanks for your suggestion, Unfortunately this cannot be implemented at this time.
Sign in to post a workaround.