Eric Li DevOps & Network Architecture

Imaging the Sim Rig for a Smaller Drive

Homelab · 2026-10-17 · Saturday · 11:53 PM · 5 min read · Eric Li

Most of today went on moving the sim rig's Windows install from a 2 TB NVMe to a 1 TB one without reinstalling anything.

Getting into the sim rig

I started in the afternoon by setting up SSH on the sim rig. I made a key on my workstation VM and wrapped the Windows setup commands in a double-click .cmd file, so I didn't have to paste anything into an admin PowerShell. The first login attempt failed because I had the Windows username wrong. Once I corrected it, ssh simrig worked. I also wrote a second .cmd file that maps the four network drives (H, P, S and V) with the same letters I use on my main PC.

The backup and the size problem

With a Samsung T7 plugged in, I took a full system image of the sim rig using Windows' built-in backup. It wrote 262 GB in about 13 minutes. I opened it read-only to confirm the system files and my Desktop were inside.

Then I hit a problem. Windows' image restore recreates the original 2 TB layout, and as far as I could verify it won't accept a smaller disk, even though only about 280 GB is used. I read through Microsoft's documentation to see what else was possible. The sim rig has only one M.2 slot, so a direct clone with Hasleo Disk Clone, which I used on my main PC on the 14th, would have needed a USB enclosure.

So I converted the existing backup. First I mounted it read-only and captured C: as a single compressed Windows image file on the T7. Then I would restore that image onto a 1 TB target with DISM and fix the boot files.

The first capture failed at 78% with "The handle is invalid". The cause was a OneDrive cloud-only file. I changed how the capture treats those, and the second run finished with a 281 GB image holding 382,153 files. The verify option makes it read everything twice, which is why my time estimates kept being wrong.

The rehearsal

Before touching the real drive I restored the image onto a virtual 1 TB disk on the T7, using the layout the real drive would get: a 300 MB boot partition, 929 GB for Windows and 1.5 GB for recovery. I compared the result with the original backup:

I then paused BitLocker, booted the sim rig from a Windows 11 install USB and ran a short script that checked the USB could read the image. It changed nothing. I also tested the restore script's safety checks. It refused the live 2 TB drive, the T7, the USB stick and bad disk numbers, and it stopped on a lowercase "erase".

A drive from the gateway

Mid-evening I needed an actual 1 TB drive. The NVMe in my UCG Fiber turned out to be an MSI M480 PRO, exactly 1,000,204,886,016 bytes, which is the same size as my virtual test disk. Windows saw four Linux partitions on it. I decided to reuse it, wiped it, and restored onto it while Windows was running instead of from the USB. DISM finished around 23:43. The boot-file step failed, so I used the sim rig's built-in tool instead.

The check against the image found a stale entry in the restored Windows that still reserved the old 2 TB as C:. That could have made the new drive come up as D:, so I removed it and kept a backup. The final comparison matched the dry run. The swap steps are written down on the T7.

Switching off the gateway to pull the drive at about 21:00 took the Meross plugs offline. About 19 of them lost their cloud connection and were slow to come back, and I spent a few minutes checking the network before I connected it to that. Pulling the drive also wiped the Protect recordings stored on it.

Protect and the NAS

Earlier I had also looked at why UniFi Protect stopped archiving to the NAS. The newest archive folder is from 28 August. The pool it writes to went read-only two minutes later in the btrfs corruption incident, and Protect never reconnected. The NAS has been healthy for weeks, with SMB reachable and the share writable. The fault is in Protect's archive target settings, which I couldn't read from my account.

Hotel job audit

In the evening I compared what the hotel's IT provider had done against what we asked for. They created the IPTV VLAN and turned on IGMP for it, but did not add it to any core switch port. The pilot isn't ready, and I wrote up a list of blockers for Monday.

Still open