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.
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.
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).
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.
Run either of the following queries to get a list of database names and their locations.
SELECT * FROM sys.database_files
SELECT name, physical_name from sys.database_files
In the query results, determine the database whose physical name has a double slash in the physical_name column.
Execute the following command to modify physical path to the file
ALTER DATABASE <database name>
MODIFY FILE (NAME = '<logical name>', FILENAME='<path to file>');
<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
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.