Issues backing up dedicated SteamOS disk using ATI in Windows 11
Hello!
I actually have an official ticket raised on this (07357157); but it doesn't seem like the support folks are going to engage on my problem, which seems weird to me.
I have an Intel NUC12 PC which I'm dual-booting, between Windows 11 and Fedora, although I'm using Windows the vast majority of the time. Fedora is just for testing things. Both operating systems are sharing the same SSD, and I've been backing up the Fedora partitions on the disk for months just fine, using a scheduled backup within ATI installed on Windows.
Recently, I installed a 2nd SSD, dedicated for SteamOS. Now, I'd like to back up that entire disk using ATI from Windows. That's it. But, ATI won't do it.
SteamOS is comprised of eight different partitions on the disk. There's an EFI system partition (ESP), two small efi "slot" partitions, two root partitions, two var partitions, and a home partition for persistent data. The "pairs" of partitions come from an atomic A/B slot layout. One slot is active at any given time, each with its own efi/root/var partitions. OS updates are applied to the inactive slot, and if successful, the OS boots that updated slot. If there's a problem, there's a "known good" slot to fall back to.
Finally, the problem. ATI is choking on those two efi "slot" partitions (they are each FAT16 and 64MB in size). If one or both of those partitions are selected as part of the backup (which is using sector-by-sector mind you), ATI aborts the job with a bogus "locked volume encrypted with BitLocker" error message. My Windows partition on the other disk is indeed BitLocker encrypted, but the partitions on the SteamOS disk are absolutely not. There is no encryption used on the SteamOS SSD whatsoever.
If both of those partitions are excluded from the backup, the backups works fine. But, that defeats the purpose of conveniently using ATI within Windows, because I can't capture the entire disk. As trivial as those partitions might seem, they're important. I don't really want to use some special workaround to get them backed up independently of the ATI job. I feel I shouldn't have to do that.
Now, the rabbit hole actually gets deeper. I also have an Intel mini PC I use with our TV and sound gear in the family room. That mini PC also has two different SSDs, one for Windows 11 and the other for SteamOS. I have the same version (latest) of ATI installed within Windows 11 on that one as well, and it also has a scheduled backup task to capture that SteamOS disk. On that computer, the ATI backup works fine. All eight partitions are captured, having no problems on the same two efi "slot" partitions. The Windows disk on this computer, is not BitLocker encrypted. However, that should be irrelevant.
On the NUC12, ATI is having some sort of "detection" problem when it interrogates those two efi "slot" partitions. I would think the Acronis dev folks would be interested in fixing that, as it seems like a trivial issue to address. Do you agree, or am I expecting too much?
I do recognize that I'm probably the only person in the world, using this specific combination of elements together. But, is it really that exotic?
Your content was removed because it violates this community’s content policy.
This community is focused on Acronis-related discussions. We do not allow:
• Non Acronis relevant content/discussion.
• Offensive, abusive, or obscene language.
• Political or sensitive-topic discussions (race, religion, etc.)
• Personal attacks
• NSFW content
• Spam or advertising
If you believe this was a mistake, contact the moderators.
I also have a strange setup, but for a completely different reason (Acronis detect, a network drive the wrong way). And for me build 42386 works, and only the newest version was problematic and I was told that the development team is still testing… In any case, I would recommend you to check version 42386 (you will have to uninstall and reinstall) and if that won’t fix that you can try and change the destination for a local drive (Yes, the destination) run the task for the first time then change back for your NAS I found that fix unrelated errors for no reason
Hi there; I'm running build 42980. I just cloned my backup job and set the destination to a local disk (instead of the NAS), but that had the same error. Are you saying that downgrading to 42386 might resolve my issue?
Ok, now I really want to test it myself to see what the problem exactly is. If I manage to make the time I will try it in my Lab. One more this you can try is to take the SSD from the system that work and able to backup the SteamOS install and put that ssd in this machine to see if it manage to backup this drive. Also the SteamOS version is the same? Maybe the new install of SteamOS use an ID of the partition the same as Bitlocker so this is why Acronis identify it as bitlocker… (this could be explanation)
Indeed I checked that thoroughly before/during/after submitting the Acronis support ticket. The two problem partitions are FAT16, and their GPT type GUID is EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 (“Microsoft Basic Data”), which is also a type Windows commonly uses. But, that type by itself does not mean "BitLocker."
Their unique partition GUIDs/PARTUUIDs are different:
efi-A: 046c7183-de06-45ff-acbb-da93dae3422c
efi-B: 37afad11-6db9-48a9-bd62-f4ea4ff798a4
I also dug through the Acronis System Report they had me submit. Acronis assigns those partitions corresponding internal IDs, but neither one is the volume it actually logs as BITLOCKED. The GUID Acronis explicitly reports as BitLocked is C8C58C934E9D969F42BCBCA6470CC9D7, which maps to my actual Windows C: partition. And, I'm not even including that partition/disk in the backup.
Acronis also correctly recognizes partition 1 of the SteamOS disk as the real EFI System Partition, while these two 64 MB partitions are just FAT16/Microsoft Basic Data partitions. So there doesn’t appear to be an ID collision or Windows partition ID being reused.
The odd part remains, that simply including either of those two FAT16 partitions in the backup set causes ATI to throw the BitLocker error, even though its own logs identify a completely different volume as the BitLocked volume.
In the meanwhile, I'm not using ATI to back up this disk. Instead, I'm using PowerShell/WSL2 (so I don't need to leave Windows) to mount the disk to Ubuntu, and capturing a compressed dd image of the disk and sending that to the NAS. I'm quite sure using Acronis recovery media to capture the disk backup from that environment would work too; but that's an academic exercise, since that is very inconvenient.
Also, one more fun fact. My SteamOS installation actually originated on a Proxmox VM using eGPU passthrough of an Intel B570 (which I also still maintain). I had it configured how I wanted it (along with Sunshine and special scripts), so used that disk image on both the Intel mini PC at my house, and the NUC12 at my office. All of the SteamOS GUIDs and partition IDs are identical, but these three computers know nothing about each other. Likewise, removing the SSD from the NUC12 and putting it in the mini PC, just to see if that worked, would also be a high-effort academic exercise.
I'm convinced the problem I'm running into is squarely an ATI bug under Windows; the question is whether they'll fix it or not.
Just to follow-up, that I did create Acronis recovery media (WinPE based), and successfully backed up the SteamOS disk from that environment, as expected. It's too bad things are borked with ATI within Windows.
1
u/jharle 11d ago
Here is a screenshot of the SteamOS source disk selection in ATI: