Weirdness with automated backup and target drive.

radorn · 16 Apr 2022

I'm trying to set up automated backup on a different disk than before and I'm facing very weird problems.

I have a 120GB SSD as system drive (100MB System Reserved, rest is C: "Boot, Page File, Crash Dump, Primary Partition) installed on the main SATA controller of the MB, a secondary 1TB HDD on the same controller as D:, and also an external USB3 3TB disk.

Until recently I had the backup set on the external disk, but I wanted to change that fo the internal 1TB. Ironically, when I try to use the internal disk, it gives me this warning:
"A system image cannot be saved on this location" and a "More information" clickable link that gives me this on a small notification window: "Scheduled backup of system image is not allowed on removable devices. You can try [...]"
So... the USB3 external drive, an actual removable device was OK, but the internal SATA disk isn't? WHAT?

I try to use it anyway, and I get to the "What do you want to back up?" dialoge, and here I get a new surprise. There's an unclickable, grayed out checkbox that says:
"Include a system image of drives: DATA (D:), System Reserved, SIS (C:)"
WHAT? my D: drive is "system"?

So I go to the disk manager to confirm that D: is not "system" or "page file" or anything, as it should be.

Now. There are two details that I think MAY have something to do with this weirdness. At some point in the several years of this current install, for reasons that I can't understand and, so far, have eluded my attempts to correct, my secondary disk began to be enumerated as Disk 0, and my system disk as Disk 1. It wasn't like this before. My system disk, the SSD, is on a lower number SATA port and the secondary disk is under it, and they used to be Disk 0 for the SSD and Disk 1 for the secondary.
I've tried to shuffle the ports and it still flips them for some reason.

Recently, after facing this problem with backing up to D:, I moved all data out of that disk, zero-filled it, created a new MBR partition table and new partition. Same results (identified as external, and as part of the system image by the backup dialog). Also changed drive letter to no avail.
Just as an experiment I tried changing to GPT and, while in that session, I could properly set automated backups on it.
But after a reboot, it started complaining again with the same nonsense about it being an external drive, and part of a system image even though there's nothing on it.

There's clearly something wrong here.
Any ideas what may be going on and how I can fix it?

Thanks for your attention.

radorn · 20 Apr 2022

Though no one seems to know what the problem is so far, I'll add a couple more details that have come to my attention.

Right after the reformatting with a change of partition table type that I mentioned in the previous message, I could set the automated system-image backup to be stored in D:\
When Windows later decided it couldn't do it anymore after a reboot, this error/warning message appeared:

"Check your backup"
"The last backup did not complete successfully"
-->
"The backup storage is invalid. You cannot use a volume that is included in the backup as a storage location"
"Error code: 0x80780040"

--------------------------------

Additionally, while doing some cleaning up, I found an old AppData folder for LBRY, which I had installed at some point.
That program kept a big cache of data chunks for their P2P distributed network and it was flooding my system disk, wich isn't that big. I don't know about newer versions, but, at that point, the program didn't allow the user to set move that to different folder in another disk, and the solution they offered on their site at the time was for the user to symlink/hardlink the data-chunk folder from the AppData subfolder so that it pointed to a folder on another disk.
I did do that at some point, but that folder was deleted and the destination disk has also been reformated more than once.
Could any of this somehow make Windows consider that destination disk as part of "system" for backup purposes? And could that erroneously persist after the deletion of the linked folder and re-formatting of the destination disk?

Another thing I remember doing at some point was mapping that disk to a subfolder of C:\, but that was also undone later.

I believe that, at some point between these things and today, chkdsk has probably run on C:\ during boot at least once. But, to make sure, I'll be doing that next reboot, to see if that helps in any way.
Not holding my breath, though.
--->> UPDATE: It didn't work... my secondary D:\ drive still gets misidentified as Disk0, for whatever reason.

radorn · 27 Apr 2022

After poking around, it seems like I've solved the backing up problem for now.

Since I've done many things at once, I'm not 100% certain which one did the trick, but the one that sounds to me to be the most likely was that I uninstalled a service that a program I wasn't even using had installed once when I ran it from a folder in that disk. I'm not sure how Windows deals with that, but it stands to reason that a service would be considered to be "part of the system".

I haven't solved the silly insistence the system has in enumerating that disk as "Disk 0" no matter where I plug it and how many other devices are avobe it in the sata ports, but that doesn't have the effect of "system-izing" the disk as I previously suspected when I didn't know what was going on.

SIW2 · 03 May 2022

Disk drive numbers may not correspond to the SATA channel numbers when you install Windows on a computer that has multiple SATA or RAID disks

radorn · 07 May 2022

SIW2 said:

Disk drive numbers may not correspond to the SATA channel numbers when you install Windows on a computer that has multiple SATA or RAID disks

Thanks. I think I already saw that before. Unless I've missed something, it seems to give a superficial explanation of why this happens, and a method to identify disk numbers, but not a method to "fix" the numbering.

In my case, what bothers me, is that at some point, the disk at sata port 0, which is where the OS is installed, was, indeed, Disk0 in Windows, but now a secondary disk, no matter where I install it, gets identified as Disk0 if present during boot.
I can make my system Disk to be #0 if I boot the PC with that uppity secondary disk disconnected, but if it's present at boot it gets numbered as 0, no matter where it is attatched at...
Apparently, it poses no technical problem at all, but it bothers me.

Well, whatever. Thanks for the link, though.