A junior dev dropped a table. Now the junior DBA has to fix it.

Scenario 1: Restore the full chain

The “everything is gone” case. You want the database back as of the latest backup.

1. Click Connect… and choose your instance.
2. Pick the Database. The app suggests a target name with a timestamp, so you restore next to the original instead of over it. That is exactly what you want when only one table is lost: production keeps running while you work.
3. Enter the backup root, for example \\fileserver\SQLBackup\SERVER\MyDb. If you use Ola Hallengren’s backup solution, the FULL, DIFF and LOG folders are filled in for you.
4. Leave Point in time at Latest available.
5. Click Run Restore. The button is pinned at the bottom of the window, so it is always where you expect it.

That is the whole job. The generated call looks like this:

-- sp_DatabaseRestore (C) Brent Ozar Unlimited / FirstResponderKit.org - MIT License
EXEC [dbo].[sp_DatabaseRestore]
    @Database = N'StackOverflow2010',
    @RestoreDatabaseName = N'StackOverflow2010_20261013_111138',
    @BackupPathFull = N'\\fileserver\SQLBackup\WIN10\StackOverFlow2010\FULL\',
    @BackupPathDiff = N'\\fileserver\SQLBackup\WIN10\StackOverFlow2010\DIFF\',
    @BackupPathLog  = N'\\fileserver\SQLBackup\WIN10\StackOverFlow2010\LOG\',
    @RestoreDiff = 1,
    @ContinueLogs = 0,
    @RunRecovery = 1,
    @ExistingDBAction = 0,
    @Execute = 'Y';

The procedure picks the newest full, the newest matching differential, and every log after that, and finishes with WITH RECOVERY.

Look before you leap: Dry Run

That call is short, but the procedure expands it into many statements. Click Dry Run (-WhatIf) and the app asks the procedure to list the real RESTORE commands without running them. Here the chain is one full, one differential and several logs, each with a plain-language comment.

Prefer SSMS? Copy it there

You do not have to run anything from the app. Copy puts the resolved script on the clipboard. Paste it into SSMS, read it, and run it there if that is how your team works. Every statement ends in a semicolon, and the last one brings the database online.

Run it

Click Run Restore and watch the Restore log. It streams what the server reports, statement by statement, and ends with Restore completed.

Scenario 2: Stop at an exact time (easy, easy!)

This is the one that saves careers. The table was dropped at about 09:44, so you want the database as it was a moment earlier. Ask the developer for the time and then go a little before it. A restore to “latest” would contain the drop, and you would be back where you started.

Under Point in time, click Choose on timeline…. The app scans your backup folders and opens a large dialog with every backup in the order it was made.

Each row tells you what you need to know:

✓

The backup header is readable and it links into a continuous chain. This is an LSN check, not RESTORE VERIFYONLY, so it will not catch a corrupt backup body.

✗

A link is missing: a gap in the log chain, or a differential whose full backup is gone.

–

Readable, but older than the earliest full, so it is not part of any chain.

STOPAT from / to

For each log backup, the window a point in time can fall into when that log is the last one applied.

Now drag the slider, or type the time in the exact time box. As you move it, the files that will be used are numbered 1, 2, 3… in the order they are applied, and the rest are dimmed. At 09:43:48 the plan is the full, the differential and three logs:

Click Use this point in time and the generated call gains one line:

The resolved statements show the same time on each log restore, and SQL Server confirms where it stopped:

The slider cannot start too early. Its left end is one second after the earliest full backup finished. A STOPAT before that is what makes SQL Server answer “The specified STOPAT time is too early” (Msg 4335) after you have already waited for the full to restore. The dialog shows a red message instead.

New backups arrive while you are thinking? Refresh (new backups) rescans the folders and keeps your chosen time.

Now get the table back

Click Run Restore. When it finishes you have a second database next to production, for example StackOverflow2010_20261013_111138, containing the table as it was at the chosen time. Production was never touched.

The last step is a normal piece of T-SQL. The quickest way is to copy the table across:

-- Recreates the table with its data (no indexes, keys or defaults)
SELECT *
INTO   [StackOverflow2010].[dbo].[Badges]
FROM   [StackOverflow2010_20261013_111138].[dbo].[Badges];

If the table has a primary key, indexes or constraints, script the table from the restored copy first (in SSMS: right-click the table, Script Table as, CREATE To), run that on production, and then fill it:

INSERT INTO [StackOverflow2010].[dbo].[Badges] (Id, Name, UserId, Date)
SELECT Id, Name, UserId, Date
FROM   [StackOverflow2010_20261013_111138].[dbo].[Badges];

Check the row count, tell the developer, and drop the restored copy when you are done. If rows were added to that table between the chosen time and the drop, those few are lost. That is the price of a point in time, and it is the reason to pick the time carefully.

Resist the urge to restore over production. It is the most dangerous option in the list, it takes everything else that happened since that moment with it, and the app makes you tick a confirmation box before it will do it.

Scenario 3: Log shipping, without the scripts

Sometimes you do not want the database online yet. You want a copy that stays in NORECOVERY and keeps catching up as new log backups land: a warm standby, or a migration where you cut over at a planned moment.

1. Switch on log shipping mode

Tick Log shipping mode. Look at the generated call: @RunRecovery = 0. The restore will stay in NORECOVERY so more logs can be applied later.

2. Run the initial restore

Click Run Restore as in scenario 1. When it finishes, the database is not online. In SSMS it shows (Restoring…), which is exactly what you want.

3. Let it watch, and say yes or no

Tick Auto-check every [N] seconds (10 to 3600). The app watches the log folder. When a new log backup shows up you get a dialog with its name and time. Apply restores it and stays in NORECOVERY. Skip pauses the checking, because a later log cannot be applied without the one you skipped.

I deliberately did not make it apply logs automatically. For a junior DBA, a confirmation per log is a feature: you always know the state of the database. The status line under the buttons says when it last checked and what it applied.

4. Finalize on cutover day

When it is time, click Finalize (bring online). That is the single RESTORE DATABASE ... WITH RECOVERY that opens the database.

Behind this, the app uses exactly the pattern from sp_DatabaseRestore’s own help: first @ContinueLogs = 0, @RunRecovery = 0, then @ContinueLogs = 1, @RunRecovery = 0 for each log, and @RunRecovery = 1 at the end. You do not have to remember which is which.

Advanced options

The simple tab covers most incidents. When you need the rest of the procedure, the Advanced tab exposes its parameters, grouped by what they do. Change a value and the generated T-SQL updates immediately.

Dry Run (-WhatIf)

The Dry Run button connects to the server and asks the procedure to resolve the real statements without executing them. You see the actual RESTORE DATABASE and RESTORE LOG commands, one per file, each with a short comment:

-- Restore FULL backup, NORECOVERY (more backups can still be applied)
RESTORE DATABASE [StackOverflow2010_20261013_111138]
FROM DISK = '\\fileserver\...\FULL\WIN10_StackOverflow2010_FULL_20261013_082727.bak'
WITH NORECOVERY, REPLACE,
    MOVE 'StackOverflow2010' TO 'D:\databases\StackOverflow2010_20261013_111138.mdf',
    MOVE 'StackOverflow2010_log' TO 'D:\databases\StackOverflow2010_20261013_111138_log.ldf';

-- Apply transaction log backup, NORECOVERY (more backups can still be applied)
RESTORE LOG [StackOverflow2010_20261013_111138]
FROM DISK = '\\fileserver\...\LOG\WIN10_StackOverflow2010_LOG_20261013_090622.trn'
WITH NORECOVERY;

-- Bring the database online (RECOVERY) - restore chain complete
RESTORE DATABASE [StackOverflow2010_20261013_111138]
WITH RECOVERY;

A good habit for juniors: run the dry run, read it top to bottom, and only then click Run Restore.

Overwriting an existing database

The default is the safe one: fail if the database exists. Kill connections, take offline and drop are all available, and every one of them stops at a confirmation dialog that you must tick before the button becomes clickable.

Everything is resizable

Generated T-SQL, the resolved statements and the restore log each have a splitter, so you can make the pane you are reading as large as you like.