Restoring a SQL Server database from a .bak file is a core SQL Server administration task performed after data loss, system migration, or a disaster recovery event. This guide covers the full process through both SQL Server Management Studio (SSMS) and T-SQL, including fixes for the most common errors.
Part 1. Prerequisites Before Restoring
Before starting the restore process, verify these conditions:
| Requirement | Why It Matters |
|---|---|
| SQL Server version compatibility | Cannot restore from a newer SQL Server version to an older one |
| .bak file accessibility | File must be accessible from the SQL Server instance's local path or a UNC share |
| Sufficient disk space | The restored database requires space equal to or greater than the original |
| Target database does not exist (or you intend to overwrite) | Restore to an existing database requires WITH REPLACE |
| SQL Server service account permissions | The service account needs read access to the .bak file location |
💡 Tip: Check your SQL Server version before restoring: run
SELECT @@VERSIONin SSMS. A .bak file from SQL Server 2019 cannot be restored to SQL Server 2016 — the version compatibility only goes in one direction.
If restoring to a different server, copy the .bak file to a local path on the target server first. Network paths work but add latency and potential access errors.
Part 2. Method 1 — Restore Using SSMS (GUI)
SQL Server Management Studio provides a graphical restore wizard that handles most common scenarios without writing T-SQL.
Steps:
- Open SSMS and connect to your SQL Server instance.
- In Object Explorer, right-click Databases and select Restore Database.
- In the Restore Database dialog, select Device and click the ... button.
- Click Add, navigate to your
.bakfile, and click OK. - SSMS populates the database name automatically from the backup header. Verify it.
- Go to the Options page (left panel).
- If restoring over an existing database, check Overwrite the existing database (WITH REPLACE).
- Review the Restore the database files as section — confirm the file paths for
.mdfand.ldfexist on the target server. - Set recovery state to RESTORE WITH RECOVERY (for a fully usable database after restore).
- Click OK to start the restore.
🗣️ r/SQLServer user: "The GUI is fine for one-off restores. Just make sure you check the file paths on the Options page — that's where 90% of restore errors come from. The default paths in the .bak often don't match the new server's directory structure."
A progress bar displays during the restore. For large databases (100 GB+), this can take 30+ minutes.
Part 3. Method 2 — Restore Using T-SQL RESTORE Command
The T-SQL RESTORE command provides more control and is essential for scripted or automated restore workflows.
Basic restore command:
RESTORE DATABASE [YourDatabaseName]
FROM DISK = 'C:\Backups\YourDatabase.bak'
WITH REPLACE,
RECOVERY,
STATS = 10;
Restore to a different file location (common when migrating servers):
RESTORE DATABASE [YourDatabaseName]
FROM DISK = 'C:\Backups\YourDatabase.bak'
WITH MOVE 'YourDatabase_Data' TO 'D:\SQLData\YourDatabase.mdf',
MOVE 'YourDatabase_Log' TO 'D:\SQLLogs\YourDatabase_log.ldf',
REPLACE,
RECOVERY,
STATS = 10;
💡 Tip: To find the logical file names inside a .bak file (needed for the MOVE clause), run this first:
RESTORE FILELISTONLY FROM DISK = 'C:\Backups\YourDatabase.bak'
| T-SQL Option | Effect |
|---|---|
| WITH RECOVERY | Database comes online after restore (default for final restore) |
| WITH NORECOVERY | Database stays in restoring state (use when applying more logs) |
| WITH REPLACE | Overwrites an existing database with the same name |
| WITH STATS = 10 | Reports progress every 10% |
| WITH MOVE | Redirects data/log files to new paths |
Part 4. Fix Common Restore Errors
Error: "The file is in use by another process"
This occurs when the target database is open or has active connections.
Fix:
USE master;
ALTER DATABASE [YourDatabaseName] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
-- Then run your RESTORE command
Error: "Cannot open backup device — Operating system error 5 (Access is denied)"
Fix: The SQL Server service account lacks read permission on the .bak file location.
- Right-click the .bak file → Properties → Security → Add the SQL Server service account with Read permission.
- Or move the .bak to
C:\Program Files\Microsoft SQL Server\MSSQL\Backup\which the service account can typically access by default.
Error: "The database cannot be opened because it is version X. This server supports version Y"
⚠️ Important: SQL Server databases cannot be restored to an older version of SQL Server. A .bak from SQL Server 2022 cannot be restored to 2019. Your only option is to restore to an equal or newer version, or use the Export/Import Wizard to transfer data schema and contents instead.
Error: "Restore of database failed — directory lookup failed"
The restore is trying to create database files in a path that does not exist. Use the WITH MOVE clause to redirect files to a path that exists on the target server.
🗣️ r/sysadmin user: "Every time I move a database to a new server, the restore fails because the original D:\Data path doesn't exist. The MOVE clause fixes it every time. I keep a script template ready for this exact scenario."
Part 5. Restore Specific Backup Types
SQL Server supports several backup types that may be combined:
| Backup Type | Description | Restore Order |
|---|---|---|
| Full backup (.bak) | Complete database snapshot | Restore first, WITH NORECOVERY if applying more |
| Differential backup (.bak) | Changes since last full backup | Restore after full, WITH NORECOVERY |
| Transaction log backup (.trn) | Log records since last backup | Restore in sequence after full/differential |
For a full restore chain:
- Restore full backup
WITH NORECOVERY - Restore differential backup
WITH NORECOVERY - Restore each transaction log in order
WITH NORECOVERY - Apply final recovery:
RESTORE DATABASE [Name] WITH RECOVERY
Part 6. Recover a Deleted .bak File
If the .bak file itself was accidentally deleted before you could restore it, standard file recovery tools can retrieve it from the disk sectors — as long as the drive has not been heavily written since the deletion.
Ritridata can recover deleted .bak files from NTFS and exFAT volumes. Scan the drive immediately after discovering the deletion, before any further writes, to maximize recovery success.
FAQ
Q: Can I restore a .bak file to a different database name? A: Yes. In the SSMS dialog, change the Database field to a new name. In T-SQL, use RESTORE DATABASE [NewName] FROM DISK = '...'.
Q: Can I restore a SQL Server .bak file without SQL Server installed? A: No. A .bak file is a proprietary SQL Server backup format. You need an equal or newer version of SQL Server Express (free) or Standard to restore it.
Q: How long does a SQL Server restore take? A: Restore speed is roughly 100–300 GB per hour on typical hardware. A 500 GB database might take 2–5 hours. SSDs and fast NVMe storage significantly speed up the process.
Q: Can I restore a .bak file on SQL Server Express? A: Yes, SQL Server Express can restore .bak files. The 10 GB database size limit of Express applies to the database after restore — you cannot restore a database larger than 10 GB to Express.
Q: What is the difference between RESTORE WITH RECOVERY and WITH NORECOVERY? A: WITH RECOVERY makes the database fully accessible after the restore completes. WITH NORECOVERY leaves the database in a "Restoring" state so you can apply additional differential or log backups before bringing it online.
