To restore a SQL Server backup under another database name, inspect its logical file names and use WITH MOVE to choose new physical paths. The database name, logical file names, and operating-system filenames are separate values.
Last updated: September 26, 2026.
RESTORE FILELISTONLY
FROM DISK = N'D:BackupsSales.bak';
GO
RESTORE DATABASE Sales_Test
FROM DISK = N'D:BackupsSales.bak'
WITH
MOVE N'Sales_Data' TO N'D:SQLDataSales_Test.mdf',
MOVE N'Sales_Log' TO N'D:SQLLogsSales_Test_log.ldf',
RECOVERY,
STATS = 5;Replace the logical names with the exact values returned by RESTORE FILELISTONLY. The SQL Server service account—not the interactive administrator—must be able to read the backup and write the target folders.
Check before restoring
- Run RESTORE VERIFYONLY for a basic backup check.
- Confirm the target name does not already identify a database you must keep.
- Choose file paths that do not collide with attached files.
- Check free space for both data growth and log recovery.
A backup can contain several data files, so include one MOVE clause for every row in the file list. Do not use REPLACE merely to bypass a safety check; it permits overwriting an existing database.
Treat the restored copy as a new environment
Disable jobs, email, integrations, and scheduled imports that should not run from a test copy. Change environment-specific settings and protect sensitive production data. If the copy is on another SQL Server instance, inspect login mappings after restore.
Microsoft’s RESTORE argument reference documents MOVE, RECOVERY, and the safety implications of REPLACE.
Verify the copy
Run DBCC CHECKDB (N'Sales_Test') WITH NO_INFOMSGS;, verify compatibility level, and compare expected row counts. If you are relocating an already attached database rather than restoring a copy, follow the database-file relocation procedure.
