Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Choose the restore chain before running any command: restore a full backup only when it is the final required backup; restore a full backup followed by its differential when that is the latest data backup; or restore the full, compatible differential, and every required transaction-log backup when using full or bulk-logged recovery. Use NORECOVERY until the last backup, then finish with RECOVERY to bring the database online.
Choose the correct restore sequence
| Situation | Sequence | Final state |
|---|---|---|
| Simple recovery, full backup only | Restore the full backup | RECOVERY |
| Simple recovery, full plus differential | Full with NORECOVERY, then its differential |
RECOVERY after the differential |
| Full or bulk-logged recovery | Full, optional latest compatible differential, then every required log in order | RECOVERY after the last required log |
| New data or log locations | Inspect logical files, add MOVE clauses, then apply the applicable chain |
RECOVERY after the last required backup |
NORECOVERY leaves the database in a restoring state so another backup can be applied. RECOVERY rolls back uncommitted work, makes the database operational, and ends that restore sequence; further backups cannot be restored into it.
Prepare before executing RESTORE
- Confirm the destination database name and the backup device path.
- Identify the intended backup set. A
.bakfile or other media can contain multiple sets; use backup history or media inspection and specifyFILE = nwhen needed. Do not assume the first set is correct. - Check the recovery model and establish the desired recovery point.
- Confirm that the backup was made on the same or an older SQL Server version than the destination. A backup from a newer release cannot be restored to an older release.
- Ensure the caller has the required permissions. Creating a new database requires
CREATE DATABASE; restoring an existing database generally requires a documented RESTORE-capable role such as sysadmin, dbcreator, or the database owner. - Plan for exclusive access to the target database and make sure the RESTORE command is not inside an explicit or implicit transaction.
Restore a full backup only
Use this path when no differential or transaction-log backups remain to apply. RECOVERY is shown explicitly, although it is the default.
RESTORE DATABASE [TargetDb]
FROM DISK = N'X:BackupsTargetDb_full.bak'
WITH RECOVERY;
Replace the database name and device path with values from your environment.
#1 Best Overall
Restore a full backup and differential
The differential must be based on the full backup you restore. Leave the full restore unfinished, then apply the compatible differential and recover.
RESTORE DATABASE [TargetDb]
FROM DISK = N'X:BackupsTargetDb_full.bak'
WITH NORECOVERY;
RESTORE DATABASE [TargetDb]
FROM DISK = N'X:BackupsTargetDb_diff.bak'
WITH RECOVERY;
If transaction-log backups must follow the differential, use NORECOVERY on the differential instead and continue with the log chain.
Rank #2
Restore a full, differential, and transaction-log chain
Under full or bulk-logged recovery, restore the data backups first, then every required log backup in sequence. Begin with the first log created after the last data backup being restored; skipping a required log breaks the chain.
RESTORE DATABASE [TargetDb]
FROM DISK = N'X:BackupsTargetDb_full.bak'
WITH NORECOVERY;
RESTORE DATABASE [TargetDb]
FROM DISK = N'X:BackupsTargetDb_diff.bak'
WITH NORECOVERY;
RESTORE LOG [TargetDb]
FROM DISK = N'X:BackupsTargetDb_log_001.trn'
WITH NORECOVERY;
-- Repeat RESTORE LOG in backup-chain order for each required log.
RESTORE LOG [TargetDb]
FROM DISK = N'X:BackupsTargetDb_log_last.trn'
WITH RECOVERY;
Alternatively, leave the final log in NORECOVERY and finish explicitly:
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minuteRank #3
RESTORE LOG [TargetDb]
FROM DISK = N'X:BackupsTargetDb_log_last.trn'
WITH NORECOVERY;
RESTORE DATABASE [TargetDb] WITH RECOVERY;
Preserve the tail of the active log
When the source uses full or bulk-logged recovery, take a tail-log backup before restoring whenever the active log is accessible and the latest transactions matter. Without it, transactions not present in earlier backups can be lost. Options such as WITH REPLACE or STOPAT can alter this behavior and should be used only when their consequences are understood.
Restore files to a different location
First retrieve the logical file names from the backup:
Rank #4
RESTORE FILELISTONLY
FROM DISK = N'X:BackupsTargetDb_full.bak';
Use those logical names in a MOVE clause for every file that needs a new path:
RESTORE DATABASE [TargetDb_Copy]
FROM DISK = N'X:BackupsTargetDb_full.bak'
WITH NORECOVERY,
MOVE N'TargetDb_Data' TO N'D:SQLDataTargetDb_Copy.mdf',
MOVE N'TargetDb_Log' TO N'E:SQLLogsTargetDb_Copy.ldf';
The names in this example are placeholders; use the values returned by RESTORE FILELISTONLY. Add a separate MOVE for each data, log, or other database file being relocated. Continue with the appropriate differential and log restores, then recover. The SQL Server service account must be able to access the destination directories, and the volumes must have sufficient capacity.
Free tools Windows power users keep installed
One-click scans. No signup required.
Best Value
Validate the backup and the completed restore
Use VERIFYONLY for a media check
RESTORE VERIFYONLY
FROM DISK = N'X:BackupsTargetDb_full.bak';
A successful VERIFYONLY checks backup-set completeness and readability. It does not perform a restore or verify the data structures on the backup volumes, so it is not a substitute for a test recovery.
Run an actual recovery test
Periodically restore the complete chain to a nonproduction destination, confirm that the database opens, and test application-level usability. This is the practical way to detect an incomplete chain, incorrect file mapping, permission problem, or unusable application state.
Common failures and their causes
- “The database is still being restored” or new backups cannot be applied: an earlier step used
RECOVERY. Restart the sequence and useNORECOVERYuntil the final backup. - Differential cannot be applied: the full backup is not the differential’s base, or the wrong backup set was selected.
- Log restore fails because a log is missing: locate and restore every required log in backup-chain order; do not skip ahead.
- File already exists or path errors occur: inspect logical names with
RESTORE FILELISTONLY, map every relocated file withMOVE, and check directory permissions. - Version or permission errors: verify the destination SQL Server release, required database permissions, and whether another session is using the target database.
- Restore command is rejected in a transaction: run
RESTOREoutside explicit and implicit transactions.
Version and documentation note
The restore concepts described here are consistent across the Microsoft Learn material reviewed for SQL Server 2019 (15.x) and SQL Server 2025 (17.x). Select the documentation version matching your server and validate paths, permissions, and syntax in that environment before a production recovery.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.

