OPBS — Open Pickle Backup System

BKnight · Oct 24, 2026

bobeeire said:
Long time user/supporter of reflect but not happy with how things are so I started to write a FOSS program some months ago.

If you are still holding onto reflect images, this will help:

OPBS — Open Pickle Backup System
The ultimate FOSS imaging solution

A FOSS disk imaging backup solution for Windows, inspired by Macrium Reflect.

Website: https://opbs.rhitcs.com
Github: GitHub - bobeire/opbs: Open Pickle Backup System brings block-level imaging, differential chains, AES-256-GCM encryption and read-only WinFsp mounts to Windows — with a headless CLI for scripted environments.

Mount a partition from a .opbs or Macrium image as a virtual drive letter with zero extra disk usage — file reads are served lazily by decompressing only the covering blocks.

Restore from Macrium Reflect images: restore also accepts Macrium .mrimgx (Reflect X) and .mrimg (Reflect 7/8) containers. Works from the CLI, the restore wizard and a Config Builder.

Know this is an old thread but worth being resurrected if this helps.

Many thanks for this!

I checked out the portable version and was easily able to grab files off my Macrium Reflect (version 8.0.7783) images without having to jump through hoops!

Simple as running OPBS --> Selecting "Browse Files" --> Browse Backup Image

bobeeire · Oct 25, 2026

BKnight said:
Many thanks for this!

I checked out the portable version and was easily able to grab files off my Macrium Reflect (version 8.0.7783) images without having to jump through hoops!

Simple as running OPBS --> Selecting "Browse Files" --> Browse Backup Image

Thanks for trying it — and for taking the time to report back! Glad the portable build got your files out of those Reflect 8 images without hoops; that "Browse → open → extract" path is exactly what it's for.

The project keeps moving (0.6.90 shipped this week — window-state memory and a quieter startup among other things), and the issue tracker is the best place for any quirks or wishes you hit along the way. Thanks again for the kind words — they keep the late-night commits coming.

altae · Oct 25, 2026

Nice one, too bad it does not support encrypted (password protected) images yet. All my images are encrypted. Is support for this planned?

kelper · Oct 25, 2026

@bobeeire

Very promising. I installed it, eventually. Whenever I got an error, I rebooted and it progressed. After successfull installation, I backed up all my system partitions but deselected two data partitions. When I tried a restore, there was no option to restore to the four original partitions, it warned that it would overwrite the entire disk. Is that correct?

kelper · Oct 25, 2026

@@bobeeire

I tried it anyway and got this error.

bobeeire · Monday at 10:53 AM

altae said:
Nice one, too bad it does not support encrypted (password protected) images yet. All my images are encrypted. Is support for this planned?

Hi, thanks for giving OPBS a shot, yes in the roadmap

bobeeire · Monday at 11:12 AM

kelper said:
@bobeeire

Very promising. I installed it, eventually. Whenever I got an error, I rebooted and it progressed. After successfull installation, I backed up all my system partitions but deselected two data partitions. When I tried a restore, there was no option to restore to the four original partitions, it warned that it would overwrite the entire disk. Is that correct?

Thanks for the detailed report and the log — this one's on me, and there are two separate things here.

Why the restore failed: you restored onto the disk Windows was currently running from. Disk 0 in your log is the boot disk (EFI + MSR + C: + WinRE), and OPBS dismounts target volumes before writing so ntfs.sys isn't serving data underneath the write. The system volume can't be dismounted while Windows is live — AUTOCHK holds it — so the write to the EFI partition came back "Access is denied." Restoring the live OS disk has to be done from bootable recovery media (WinPE), not from inside Windows. I can see the ADK install failed a few times in your log (exit 2001 — a partial-install/pending-reboot state, which is why rebooting made things progress), so the recovery media never got built. That's the correct path for this restore, and I'm sorry the app didn't stop you before you got that far.

Your question about the warning — you were right to question it. The "this will overwrite all data on the target disk" message is too broad for your case. When you restore to the same disk with the same layout, OPBS writes only the partitions you selected, at their original offsets — it does not rewrite the partition table, and your two deselected data partitions would not have been touched. So even setting the access-denied issue aside, that warning overstated what would actually happen. I'm fixing both: a clear pre-restore warning (or hard stop) when the target is the running system disk, and accurate wording for same-disk restores.

In the meantime: build the recovery media once the ADK installs cleanly (reboot between attempts if it returns 2001), boot from it, and restore there. That's the safe path for a system disk.

kelper · Monday at 11:15 AM

The restore was going to restore the four selected partitions to the whole disk! This needs to be addressed.

altae · Monday at 12:46 PM

bobeeire said:
Hi, thanks for giving OPBS a shot, yes in the roadmap

Great to hear. And thanks for your work

kelper · Monday at 1:05 PM

bobeeire said:
Thanks for the detailed report and the log — this one's on me, and there are two separate things here.

Why the restore failed: you restored onto the disk Windows was currently running from. Disk 0 in your log is the boot disk (EFI + MSR + C: + WinRE), and OPBS dismounts target volumes before writing so ntfs.sys isn't serving data underneath the write. The system volume can't be dismounted while Windows is live — AUTOCHK holds it — so the write to the EFI partition came back "Access is denied." Restoring the live OS disk has to be done from bootable recovery media (WinPE), not from inside Windows. I can see the ADK install failed a few times in your log (exit 2001 — a partial-install/pending-reboot state, which is why rebooting made things progress), so the recovery media never got built. That's the correct path for this restore, and I'm sorry the app didn't stop you before you got that far.

Your question about the warning — you were right to question it. The "this will overwrite all data on the target disk" message is too broad for your case. When you restore to the same disk with the same layout, OPBS writes only the partitions you selected, at their original offsets — it does not rewrite the partition table, and your two deselected data partitions would not have been touched. So even setting the access-denied issue aside, that warning overstated what would actually happen. I'm fixing both: a clear pre-restore warning (or hard stop) when the target is the running system disk, and accurate wording for same-disk restores.

In the meantime: build the recovery media once the ADK installs cleanly (reboot between attempts if it returns 2001), boot from it, and restore there. That's the safe path for a system disk.

Other disk-imaging programs will reboot into a PE/RE if to try to restore into live partitions.

kelper · Tuesday at 6:05 AM

I tried to create a recovery media but got this error

bobeeire · Tuesday at 1:20 PM

kelper said:
I tried to create a recovery media but got this error
View attachment 187908

Your log shows the build itself got well past the hard parts: the working directory was staged, boot.wim was mounted, the WinPE packages (WMI, SecureStartup) were added at 100%, and the customized image saved and unmounted cleanly. Everything that failed is one step — formatting the USB stick:

ERROR: Failed to format "F:"; DiskPart errorlevel -2147024809.

That number is 0x80070057 — "The parameter is incorrect", and the single most common cause with boot media is stick capacity: MakeWinPEMedia formats the USB as FAT32, and Windows refuses to FAT32-format anything larger than 32 GB. A 64 GB or 128 GB stick fails exactly like this. So first: what capacity is the F: stick?

If it's 32 GB or smaller, work down this list:

Try formatting F: from Explorer (right-click → Format → FAT32). If Explorer also errors, it's the stick, not OPBS.
Check the physical write-protect switch — some sticks have one on the connector.
Try a different USB port — a rear/port USB2 port is the most compatible; some sticks misreport their geometry on certain controllers.
Wipe the stick's partition layout once with diskpart (clean, then re-plug) — a stale or odd layout makes the format step fail with this same parameter error.
If none of that helps, try another stick — flash drives fail quietly and format errors are often the first sign.

Send me the capacity and which step changed things and I'll take it from there.

bobeeire · Tuesday at 1:26 PM

kelper said:
The restore was going to restore the four selected partitions to the whole disk! This needs to be addressed.

Fair — that's exactly what the warning made it sound like, and the wording was wrong. Let me state the actual mechanics: a restore writes only the partitions you selected, each into its slot at its original offset on the target disk. The partition table isn't rewritten, and anything you didn't select isn't touched. "Four selected partitions" can never write "the whole disk" — there is no whole-disk write path in a restore.

What did need addressing is that one of the warning texts claimed the whole disk would be erased — over-broad, and in your situation needlessly alarming. That's fixed: the warning, the partition-count message and the acknowledgment now all scope to exactly the partitions being written. The fix went in yesterday and ships in 0.6.92.

While I was in there, I also added the guard you'd want after reading such a warning: attempting to restore a partition that belongs to the live system disk (the one Windows is running from) is now hard-blocked before anything starts, with a message pointing you at bootable recovery media instead. Data partitions on the system disk still restore normally — the block is matched per-partition, not per-disk.

kelper · Tuesday at 1:30 PM

I tried a few USBs but they were all larger than 32Gb. Why does your program not check this? Or even mention it?

bobeeire · Tuesday at 1:36 PM

kelper said:
Other disk-imaging programs will reboot into a PE/RE if to try to restore into live partitions.

You're right — that's the established pattern. Macrium stages the restore and drops you into WinRE to apply it, and it exists for exactly the reason from my earlier reply: the live system volume can't be dismounted while Windows is holding it, so the write has to happen from a boot environment.

OPBS's path to the same place is the bootable WinPE recovery USB — same class of environment, but you boot it yourself rather than having the app stage a reboot. What's missing is the up-front redirect: until now, trying this from inside Windows got you a cryptic access-denied partway through. From 0.6.92 that attempt is blocked before it starts, with an explicit message that this restore belongs on recovery media — so you find out at step one instead of after the write fails.

To be straight about scope: OPBS doesn't have an automatic reboot-into-WinRE flow like Macrium's, and I'm not promising one — the supported route for restoring the system disk is the recovery USB, booted from the firmware menu.

SIW2 · Tuesday at 3:02 PM

the supported route for restoring the system disk is the recovery USB, booted from the firmware menu.

could add the .wim to the windows boot menu if desired.

Your log shows the build itself got well past the hard parts: the working directory was staged, boot.wim was mounted, the WinPE packages (WMI, SecureStartup) were added

Is there a reason it does not use winre.wim as the base ? winre.wim can be copied then the program and winpeshl.ini shoved in using something like wimlib

I have made simple boot media that way without bothering to mount the copied winre.wim.

I usually put a little menu in so the one wim can accomodate several programs

kelper · Tuesday at 3:09 PM

bobeeire

OK, that's your choice. But I think you need to trap there missteps or you will alienate potential users. I am creating recovery media on a smaller USB. Then, I will do a system backup and then a restore.

kelper · Tuesday at 4:46 PM

I booted from the new usb and tried to restore. More errors.

Validating the plan (preflight — nothing is written)...
[2026-10-28T04:56:46.872Z] [INFO] Restore chain resolved: E:\opbs-disk0-2026-10-27T17-58-12.opbs

Image: E:\opbs-disk0-2026-10-27T17-58-12.opbs
Verify before write: no
Target partitions: disk 0 part 0 @1.0 MB, disk 0 part 1 @301.0 MB, disk 0 part 2 @317.0 MB, disk 0 part 3 @130.4 GB
Partition table: keep existing (no layout change)

Type RESTORE to start the restore, anything else to cancel.
Confirm > RESTORE

Starting restore — do not power off this machine.
[2026-10-28T04:56:53.654Z] [INFO] Restore chain resolved: E:\opbs-disk0-2026-10-27T17-58-12.opbs
[writing] 0% 316 MB/132 GB 124 MB/s Partition 2 clearing free space
Restore FAILED: Write failed for Partition 2 block 0 at 332398592: WriteFile failed on \\.\PhysicalDrive0 at offset 332398592 (1048576 bytes): Access is denied. (error 5 / 0x5)

The wizard ended with code 1.
Press any key to continue . . .

bobeeire · Tuesday at 5:40 PM

kelper said:
bobeeire
OK, that's your choice. But I think you need to trap there missteps or you will alienate potential users. I am creating recovery media on a smaller USB. Then, I will do a system backup and then a restore.

You're right — it should have checked, and it didn't. That's a straight miss: the builder spent twenty minutes assembling the boot image and then failed on something knowable in the first second.

Fixed. The drive picker will now mark any stick over 32 GB ("TOO LARGE FOR FAT32") and refuse it before the build starts, with the reason spelled out — the media is formatted FAT32 and Windows can't FAT32-format anything above 32 GB. The check will also exist server-side (CLI included), and if a format failure like yours does slip through, the error now explains the size limit instead of just quoting a DiskPart code. For bigger sticks the suggestion is: build the ISO and write it with Rufus, which can format larger FAT32 volumes. This ships in the next release (0.6.93).

And fair on the wider point too — "trap the missteps before users hit them" is the right standard, and I'd rather hear it than lose you as a tester. restoring the system disk from inside Windows is now blocked up front (that's the fix from 0.6.92), and I've also just implemented the nicer version of that story — OPBS can now stage the restore and run it automatically after a one-shot reboot into a recovery environment built from your own Windows RE image, then come back to Windows and report the result. It's in testing now; I'll say more when it's shipped.

OPBS — Open Pickle Backup System