SQL Server Error 3156

Error number

3156

Severity

16 (user-correctable error)

State

4 (see the state table below)

Product

Microsoft SQL Server Database Engine

Versions

All supported SQL Server versions (2016 to 2025), Azure SQL Managed Instance

Category

Backup & Restore

Last reviewed

24 October 2026

What it means

Error 3156 means RESTORE cannot create one of the database files at the path recorded in the backup, so you must give that file a usable path with WITH MOVE.

A backup remembers every file of the source database: its logical name and the physical path it had on the original server. Unless you say otherwise, RESTORE creates each file at that same path. While planning the restore, SQL Server checks every path; for each one it cannot use, it prints a specific reason followed by 3156 naming the logical file (first) and the path (second). After all files are checked it adds Msg 3119 ... Previous messages provide details and Msg 3013. Nothing has been written yet.

So read the message that comes before each 3156. Error 1834 means another database on this instance already uses that file, which is what happens when you restore a copy of a database next to the original. Error 5133 with operating system error 3 means the folder does not exist on this server, typical when the backup comes from a server with different drive letters. Operating system error 5 means the SQL Server service account has no access to the folder. In every case the cure is the same: WITH MOVE 'logical name' TO 'new path' for each listed file.

Common causes

• Restoring a copy of a database on the same instance under a new name, without MOVE: the original database still owns the files.
• Restoring a backup from another server whose drive letters or folders (for example E:\SQLData) do not exist on this one.
• The SQL Server service account has no write permission on the folder recorded in the backup or given in MOVE.
• A typing mistake in the MOVE path, or a MOVE clause missing for one of the files (often the log file or an extra .ndf file).

Diagnose it

Read-only These queries only read metadata and dynamic management views. They do not change data, permissions or configuration, so they are safe to run first.

SELECT bs.database_name, bs.backup_finish_date, bf.logical_name, bf.physical_name, bf.file_type
FROM msdb.dbo.backupset AS bs
JOIN msdb.dbo.backupfile AS bf ON bf.backup_set_id = bs.backup_set_id
WHERE bs.database_name = N'AppDb'
  AND bs.backup_set_id = (SELECT MAX(backup_set_id) FROM msdb.dbo.backupset WHERE database_name = N'AppDb' AND type = 'D');

SELECT DB_NAME(database_id) AS database_name, name AS logical_name, physical_name
FROM sys.master_files
WHERE physical_name LIKE N'%AppDb%'
ORDER BY database_name;

SELECT SERVERPROPERTY('InstanceDefaultDataPath') AS default_data_path,
       SERVERPROPERTY('InstanceDefaultLogPath')  AS default_log_path;

How to fix it

Each fix is labelled with what it changes. Try read-only checks and the least invasive fix first, and test changes outside production.

RESTORE DATABASE AppDb_Copy
FROM DISK = N'D:\Backups\AppDb.bak'
WITH MOVE N'AppDb'     TO N'D:\SQLData\AppDb_Copy.mdf',
     MOVE N'AppDb_log' TO N'D:\SQLLogs\AppDb_Copy_log.ldf',
     CHECKSUM;

Examples

Restoring a copy next to the original without MOVE

Throwaway database; the backup goes to the instance default backup folder. The copy is called cws_errlab_copy here; the restore fails, so it is never created. Each file produces its own pair of messages (paths shortened).

USE master;
DECLARE @bak nvarchar(260) = CAST(SERVERPROPERTY('InstanceDefaultBackupPath') AS nvarchar(200)) + N'\cws_errlab_3156.bak';
BACKUP DATABASE AppDb TO DISK = @bak WITH INIT;

-- Restore a copy under a new name on the same instance, without MOVE
RESTORE DATABASE cws_errlab_copy FROM DISK = @bak;

Msg 1834, Level 16, State 1, Line 6
The file 'D:\SQLData\AppDb.mdf' cannot be overwritten.  It is being used by database 'AppDb'.
Msg 3156, Level 16, State 4, Line 6
File 'AppDb' cannot be restored to 'D:\SQLData\AppDb.mdf'. Use WITH MOVE to identify a valid location for the file.
Msg 1834, Level 16, State 1, Line 6
The file 'D:\SQLData\AppDb_log.ldf' cannot be overwritten.  It is being used by database 'AppDb'.
Msg 3156, Level 16, State 4, Line 6
File 'AppDb_log' cannot be restored to 'D:\SQLData\AppDb_log.ldf'. Use WITH MOVE to identify a valid location for the file.
Msg 3119, Level 16, State 1, Line 6
Problems were identified while planning for the RESTORE statement. Previous messages provide details.
Msg 3013, Level 16, State 1, Line 6
RESTORE DATABASE is terminating abnormally.

MOVE to a folder that does not exist on this server

Throwaway database; the backup goes to the instance default backup folder. Drive Z: does not exist on the test server, standing in for a backup from a server with another disk layout. This time 5133 comes before each 3156, and the state is 3.

USE master;
DECLARE @bak nvarchar(260) = CAST(SERVERPROPERTY('InstanceDefaultBackupPath') AS nvarchar(200)) + N'\cws_errlab_3156.bak';
BACKUP DATABASE AppDb TO DISK = @bak WITH INIT;

RESTORE DATABASE cws_errlab_copy FROM DISK = @bak
WITH MOVE N'AppDb'     TO N'Z:\SQLData\AppDb_Copy.mdf',
     MOVE N'AppDb_log' TO N'Z:\SQLData\AppDb_Copy_log.ldf';

Msg 5133, Level 16, State 1, Line 5
Directory lookup for the file "Z:\SQLData\AppDb_Copy.mdf" failed with the operating system error 3(The system cannot find the path specified.).
Msg 3156, Level 16, State 3, Line 5
File 'AppDb' cannot be restored to 'Z:\SQLData\AppDb_Copy.mdf'. Use WITH MOVE to identify a valid location for the file.
Msg 5133, Level 16, State 1, Line 5
Directory lookup for the file "Z:\SQLData\AppDb_Copy_log.ldf" failed with the operating system error 3(The system cannot find the path specified.).
Msg 3156, Level 16, State 3, Line 5
File 'AppDb_log' cannot be restored to 'Z:\SQLData\AppDb_Copy_log.ldf'. Use WITH MOVE to identify a valid location for the file.
Msg 3119, Level 16, State 1, Line 5
Problems were identified while planning for the RESTORE statement. Previous messages provide details.
Msg 3013, Level 16, State 1, Line 5
RESTORE DATABASE is terminating abnormally.

How to prevent it

Keep a restore script per database with explicit MOVE clauses for every file, generated from RESTORE FILELISTONLY, rather than relying on the paths stored in the backup. Use the same folder layout on servers that exchange backups where you can, and include the database name in every physical file name so copies never collide.

When you add a file to a database, update the restore scripts at the same time: a missing MOVE for a new .ndf file is a common reason a tested script suddenly fails.

Common questions

Learn more on CodeWithSQL

• Working with large databases

Official documentation

• MSSQLSERVER_3156 (Microsoft Learn)
• Restore a database to a new location (SQL Server)
• RESTORE statements: FILELISTONLY (Transact-SQL)

Last technically reviewed 24 October 2026; examples and diagnostics run on SQL Server 2025 (17.0.1145.4). Message text checked against the engine's sys.messages catalogue.