Fix ERROR_FILE_IDENTITY_NOT_PERSISTENT (0X00001AA7)

You hit ERROR_FILE_IDENTITY_NOT_PERSISTENT (0X00001AA7)

I know this error is infuriating — it usually pops up after a VM snapshot restore or a file-level backup where SQL Server can't verify the file’s unique identity. The file itself is fine, but the metadata is corrupted. Here’s the straightforward fix.

Quick Fix: Rename and Restore

This error doesn't mean your database is gone. It means SQL Server can't trust the file’s identity because the NTFS file system lost the persistent identity record. The fix is to manually rename the database files and restore from a known good backup.

Open SQL Server Management Studio (SSMS) as an administrator.
Run this query to put the database in single-user mode and detach it:

USE master;
GO
ALTER DATABASE [YourDatabaseName] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
GO
EXEC sp_detach_db 'YourDatabaseName';
GO

In Windows Explorer, locate the .mdf and .ldf files. Right-click and rename them — add _old to the end. For example, YourDatabase.mdf becomes YourDatabase_old.mdf.
Restore your last good full backup using SSMS or T-SQL:

RESTORE DATABASE [YourDatabaseName]
FROM DISK = 'C:\Backups\YourDatabase_Full.bak'
WITH RECOVERY;
GO

If you have log backups or differential backups, restore them in order after the full backup.

That's it. The error disappears because you gave SQL Server a fresh version of the file with a clean identity. The old, corrupted files are still on disk if you need them for forensic recovery.

Why This Happens

SQL Server relies on the NTFS file identity — a hidden metadata stamp that links a file to its creation on a specific volume. When you restore from a snapshot (like Hyper-V checkpoints or VMware snapshots), the hypervisor may not preserve this identity. The error code 0X00001AA7 tells you the identity check failed. It's not a data integrity error. It's a metadata mismatch.

This happens most often with:

Virtual machine snapshots taken while the database is active
File-level backup tools that copy SQL files without using VSS writers
Storage replication that doesn't honor NTFS persistent reservations

I've seen this in SQL Server 2019 and 2022 on Windows Server 2022. It's more common with iSCSI or SAN-based storage where the file system layer gets confused.

Less Common Variations

Variation 1: Error on Attach

You might see a similar error when attaching a database directly with CREATE DATABASE ... FOR ATTACH. The fix is the same — rename the files, attach fresh. But there's a shortcut:

CREATE DATABASE [YourDatabaseName]
ON (FILENAME = 'C:\Data\YourDatabase.mdf')
FOR ATTACH_REBUILD_LOG;
GO

This rebuilds the log file and forces a new identity. Use this only if you're okay with losing the log tail.

Variation 2: Error During Backup Restore

If the error appears during a RESTORE command, the backup file itself is fine but the target database path is corrupted. Drop the existing database (after confirming you have a good backup) and restore with WITH MOVE:

RESTORE DATABASE [YourDatabaseName]
FROM DISK = 'C:\Backups\YourDatabase_Full.bak'
WITH MOVE 'YourDatabase_Data' TO 'D:\NewPath\YourDatabase.mdf',
MOVE 'YourDatabase_Log' TO 'D:\NewPath\YourDatabase_log.ldf',
REPLACE;
GO

By moving the files to a new path, you skip the identity check entirely.

Variation 3: Error on Read-Only Database

Read-only databases held on network shares can trigger this. The SQL Server service account doesn't have the necessary file identity privileges. Grant the service account SeManageVolumePrivilege via local security policy, or move the database to a local drive.

Prevention

Use VSS-aware backup tools (like SQL Server's native backup, not file-level copies).
Avoid snapshot-based restores of active SQL Server VMs. Shut down the VM before taking the snapshot.
If you must use snapshots, test a restore in a separate environment first.
Monitor Event ID 4135 in the Windows System log — it flags NTFS identity problems.

That's the whole thing. The error looks scary, but it's easy to kill. Rename, restore, move on.