Skip to main content
druva_logo.pngDruva
|
Documentation

How can we help you?

 

Trending articles:
Druva Documentation

SQL backups fail with snapshot error PHOENIX54

  1. Last updated
  2. Save as PDF

 

Problem description

SQL backups fail with snapshot error PHOENIX54 if the path to the SQL database contains a double slash or an extra space at the end.

Cause

Phoenix checks the database paths before backup to ensure snapshot consistency. If the database path has a double slash or an extra space at the end, the snapshot creation fails. Databases created with the CREATE DATABASE command generally exhibit this behavior. The path to the data files and log files includes an extra backslash before the filename. For example, M:\MSSQL\Data\\testbb.mdf.  The file names with the extra backslash are written to the system databases. The extra backslash is visible in the database properties screen.
 

Traceback

Phoenix log location: PhoenixLogs-Job<jobid>\<backupset>\PhoenixJob<jobid>\Phoenix.<timestamp>

[ERROR] <_MainThread(MainThread)> Error <class 'inSyncLib.inSyncError.SyncError'>:Error occurred while getting file size for file: 'VishalSarode.mdf' from snapshot (#100040007) (Error Code : VSS7).
_
[ERROR] <_MainThread(MainThread)> Error <class 'inSyncLib.inSyncError.SyncError'>:Failed to take snapshot. (#100000036) (Error Code : PHOENIX54).

Resolution

  1. Open SQL Server Management Studio.  Ensure that the version of the SQL Server Management Studio matches the version of the SQL instance running on the machine. 

  2. Run either of the following queries to get a list of database names and their locations. 
    USE <database_name>
    SELECT * FROM sys.database_files     
    OR
    USE <database_name>
    SELECT name, physical_name from sys.database_files

  3. In the query results, determine the database whose physical name has a double slash in the physical_name column. 

  4. Execute the following command to modify physical path to the file
    ALTER DATABASE <database name>

    MODIFY FILE (NAME = '<logical name>', FILENAME='<path to file>');

    where

    <database name> is the name of the database that is mentioned in the error, no changes needed

    <logical name> is the logical name of the file mentioned in the error, no changes needed

    <path to file> is the full path to the file that is mentioned in the error, without double slashes or extra spaces at the end

Workaround

If the steps given in the Solution, to fix the issue will take time then meanwhile workaround can be followed. Uncheck the affected database from the SQL content rule which has issues and save the backupset, so that backups of the rest of the DB’s are successfully protected.