Running Windows Server Backup, Disk X has the same disk identifiers as one or more disks connected to the system.

Rick Hogan 0

We have been having an occasional problem on Windows Server 2019 VM running under Hyper-V 2019, during backups. From what I have been able to determine, the backup, running from Hyper-V, triggers the VM to create Shadow Copies of the disks to be backed up. This process always causes a series of messages to appear in the Event Logs, such as: Disk 6 has the same disk identifiers as one or more disks connected to the system. Go to Microsoft's support website (http://support.microsoft.com) and search for KB2983588 to resolve the issue. and The disk signature of disk 6 is equal to the disk signature of disk 0. The VM has 6 disks (VHD files) attached, which are Disk 0 through 5. So disk numbers > 5 are, I believe, related to the shadow copies of the disks. And, from what I've read, it is expected that these messages will appear, because the shadow copies have the same disk signatures as the original disks.
Where we have a problem is that sometimes, we see a message like this: The disk signature of disk 5 is equal to the disk signature of disk 10. In this case, the "real" disk appears first in the message, before the shadow copy disk. After that, the real disk is forced offline, which in turn causes all sorts of other problems, since it is effectively pulling the disk out of the VM and crashing whatever programs (i.e. SQL Server) depend on that disk. Has anyone else seen anything like this? Any ideas how we can prevent this from happening? Thanks in advance. Rick

Kenneth Løken / Intility AS 0 Reputation points

2024-07-30T12:53:56.3466667+00:00

Hi, Rick! Were you able to solve this somehow? Seeing the same errors here and experiencing disks going offline.
Rick Hogan 0 Reputation points

2024-07-30T19:34:23.8166667+00:00

Hi Kenneth,

No, I have not found a solution to this problem yet. I opened two separate paid support incidents with Microsoft, but they refuse to do anything beyond asking me if I'm still having the problem and asking if they can close the tickets. I have tried to get them to escalate the issue to someone at Microsoft who actually understands how Windows works, but they won't do that.

Perhaps we can share details of what we are each seeing and figure out a solution?
Kenneth Løken / Intility AS 0 Reputation points

2024-08-01T11:16:49.43+00:00

Yes that would be nice, perhaps we could find a solution. This happens seemingly very random so it is difficult to troubleshoot and provoke. Which backup provider or solution are you running?
Kenneth Løken / Intility AS 0 Reputation points

2024-08-01T11:18:16.1+00:00

Double
Rick Hogan 0 Reputation points

2024-08-02T19:18:28.2133333+00:00

We are primarily using Acronis Virtual Host as our backup solution. However, we had also been using Windows Server Backup on the Hyper-V server as a "secondary" backup. Initially, the problem was happening frequently with both Acronis and WSB. However, we got Acronis support to look at our backup settings and they made a few adjustments, which drastically reduced the frequency of the error happening when Acronis backed up the entire Hyper-V server. Since then, the problem has been mostly only happening with WSB, so we finally stopped running the WSB backup. Since then, we've only had one occurrence under Acronis.

The problem only happens during backups at the Hyper-V level. We have Acronis Agents in some of our VMs, which backup things at the VM level. That never causes a problem.

Most of our VMs only have one or two VHDX files attached to them. Those VMs never have trouble. This error only occurs on the two VMs which each have 5 VHDX files attached to them. So I believe having more than one or two VHDX files contributes to the issue.

What are you using for backups? Do you have multiple VHDX files attached to the VMs where you see this problem? What other details can you share?
Kenneth Løken / Intility AS 0 Reputation points

2024-08-08T07:35:57.5233333+00:00

We are using Cohesity as our backup solution but we have VMWare as hypervisor.

From what I read it seems like our problem is very similiar. It happens on servers which has at least two drives. I have the same observations as you have:

When backing up the drives it goes to VSS to take a snapshot.

We see the following events when a backup/Snapshot operation takes place:
"The disk signature of disk 2 is equal to the disk signature of disk 0."

"The disk signature of disk 3 is equal to the disk signature of disk 1."

Where Disk 2 and Disk 3 is the copied disks.

The problems occur when the following events happen:

"The disk signature of disk 2 is equal to the disk signature of disk 0."

"The disk signature of disk 1 is equal to the disk signature of disk 3."

Where the "real" disk (disk 1) is equal to the disk signature of disk 3 (copy)

I believe it then tries to mount this copied disk, it has a signature conflict and the real one goes offline. In c:\windows\inf\setupapi.dev.log I can see that there is a device install at that time (Hardware initiated) where it seems to want to install drivers for this "new" drive.

I believe this to be a Windows or VSS bug, as we have different hypervisors and storage, as well as different backup solutions. This seems like the one thing we have in common at least
Rick Hogan 0 Reputation points

2024-08-09T19:53:52.67+00:00

Thanks for sharing the details. I too am convinced that is a bug in Windows. Now the question is, how do we get Microsoft to pay attention to this and do something about it?
Kenneth Løken / Intility AS 0 Reputation points

2024-08-12T13:56:45.18+00:00

We have a case opened now with MS so we will see if it will get some traction.
Regarding the Acronis adjustments they did, do you know what specifically they did to reduce the frequency of it happening?
Rick Hogan 0 Reputation points

2024-08-13T21:14:46.0766667+00:00

Let me know if you have any success with Microsoft. We've had two different cases with MS for this. The first one, the guy just told me he was too busy to help, and that was pretty much the end of it. The second one, the guy keeps complaining about being too busy, but once every few weeks he sends an email to ask if he can close the case. He did offer a couple of suggestions along the way, but they were all things I had already found using Google on my own. Nothing particularly helpful. I have asked many times to escalate the issue to someone in Microsoft who knows something about how Windows works, but he never directly responds to that question.

As for Acronis, they mostly looked at settings to verify that I had set it up properly, but didn't change much. At one point, they changed it from "Automatically select snapshot provider" to "Use Microsoft Software Shadow Copy provider." That seemed like it might have made a difference. Although, the problem is so rare and unpredictable, it's hard to say for sure.
Rick Hogan 0 Reputation points

2024-08-27T19:00:19.0633333+00:00

Hi @Kenneth Løken,

Just wondering if you had gotten anywhere with Microsoft regarding this issue? The latest update I have is that they want to refund my paid support incident because they are supposedly too busy to work on this problem.
Kenneth Løken / Intility AS 0 Reputation points

2024-10-02T07:54:15.29+00:00

Hi Rick, sorry for the late reply. I cant seem to have gotten a notification about this.

In short, no progress on the case although it is still open.

Do you have any ideas on how one could provoke this or does it happen very randomly on your environment as well? You mentioned that it is also happening while running Windows Server backup, have you been able to trigger a error this way?
Rick Hogan 0 Reputation points

2024-10-04T19:03:06.7066667+00:00

Microsoft has been no help at all. They should say that a "paid support incident" doesn't get you anything beyond a person who can use Google (or maybe Bing) to find if there is already a solution to your problem. We actually have two incidents open, but all we get are monthly emails asking if I still want to keep the tickets open. They have not actually done anything for us.

Anyway, the problem is very random. I haven't been able to find a way to trigger it. We backup our Hyper-V servers daily, but the error only occurs maybe once every 2 or 3 months. It can happen running Windows Server Backup, or Acronis Virtual Host backup. It can happen hours after rebooting the entire server and all of the VMs, or it can happen weeks after the last reboot. There is nothing consistent or predictable about it.

One thing we did notice is that the problem only ever occurred in VMs that had more than 3 VHDX files attached. So, we consolidated the data on those VMs so that they now have 3 or fewer VHDX files. Since then, we have not seen the problem. However, there is no way to know for sure until we've gone several months without any issues.
Rick Hogan 0 Reputation points

2024-10-04T19:09:14.6966667+00:00

I have not found any way to provoke this error. It happens very randomly. It can happen a few hours after rebooting the entire server, or it can happen weeks after rebooting. It can happen running Windows Server Backup or running Acronis Virtual Host backup.

And Microsoft has been no help at all. We have two paid support incidents open, but all we get from Microsoft are monthly emails asking if we still want to keep the tickets open.

2 answers

Net Runner 615 Reputation points

2024-02-10T17:41:47.2833333+00:00

I have seen similar issues with virtual machines with multiple VHDX files that may have been attached/transferred from other virtual machines before or copied and re-used. The easiest fix to that problem would be creating a similar virtual machine from scratch (including all the virtual disks) and migrating the data. A quicker option would be trivial cloning using Windows Admin Center or free V2V Converter https://www.starwindsoftware.com/starwind-v2v-converter.
Please sign in to rate this answer.
Rick Hogan 0 Reputation points

2024-02-13T20:44:53.23+00:00

Thanks for your response and the information about Starwind V2V Converter. I will have to look at what it does. To the best of my recollection, everything for this VM was created from scratch. This was all set up when we migrated from SBS 2011 to Server 2019 VMs running on Hyper-V. This was a few years ago now, so it's possible I'm forgetting something, but I just can't imagine how any of these VHDX files really would have ever been attached to other VMs, besides the one they are attached to now.
The server has both an SSD RAID and an HDD RAID. I know we had a few iterations of putting some VHDXs on the HDD RAID and then later deciding it would be better to have them on the SSD RAID, or vice versa. So it is possible that the VM may have been shutdown, VHDXs copied from one RAID to the other, and then the VM reconfigured to point to the new location, etc. But it would still be the same VHDXs attached to the same VM.
The actual problem of the disk being forced offline due to duplicate disk IDs only happens 2 or 3 times a year. So it doesn't seem like the VHDX files could really be broken in some way, but I suppose anything is possible. Do you think I really need to create a new VM? Or could I just create new VHDXs, attach them to the existing VM and then copy the data from one VHDX to the other?
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.
Ian Xue 38,731 Reputation points Microsoft Vendor

2024-03-21T08:00:53.8733333+00:00
Hi Rick,

Hope you're doing well.

Ensure that your VM's disk configuration is set up correctly. Verify that there are no conflicts in disk numbering or configuration within Hyper-V.

Make sure that your Windows Server 2019 VM and Hyper-V 2019 host are fully updated with the latest patches and updates from Microsoft. Sometimes, issues like this are addressed in software updates.

If the problem persists, you may need to intervene manually when such conflicts occur. This could involve temporarily detaching and reattaching disks to force Windows to assign new disk signatures. However, this should be done cautiously and preferably during maintenance windows to avoid disruptions.

In addition, you can use "diskpart" to check all disks' Uniqueid.

Best Regards,

Ian Xue

If the Answer is helpful, please click "Accept Answer" and upvote it.
Please sign in to rate this answer.
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

Share via

Running Windows Server Backup, Disk X has the same disk identifiers as one or more disks connected to the system.

2 answers

Your answer