This new major release introduces extensive internal rewrites, primarily in the Windows imaging area, as well as in the a (add) function.

Disk image creation and restore

The main changes concern disk image creation, for example as follows,
with the corresponding restore commands.

The -ntfs switch implies saving only the data actually present
in NTFS partitions.

zpaqfranz a d:\test\partf f: -image -ntfs
zpaqfranz image d:\test\partf.zpaq f: -to f: -ntfs

Using -raw, instead, every cluster of the partition is copied,
both free and allocated.

zpaqfranz a d:\test\partf_raw.zpaq f: -image
zpaqfranz image d:\test\partf_raw.zpaq f: -to f: -raw

This behavior also applies to the restore function (image command).

In short:

• if you use -ntfs for backup, you must use -ntfs for restore
• the same applies to -raw

There is also the -all switch, which copies the entire disk
containing a given partition.

zpaqfranz a disk.zpaq f: -image -all

This will not copy only partition F:, but the entire hard disk
on which F: resides.

Finally, there is the -vss switch, which is extremely useful for
copying the C: drive:

zpaqfranz a d:\backup.zpaq c: -image -vss -ntfs

Main difference

The most striking difference is that previous versions required the use of temporary files for recovery.
You had to

1. create the .zpaq file
2. extract them to “somewhere,” essentially doubling the space
3. write back to the final partition in an additional pass

Now

1. you create the .zpaq file
2. you write directly to the partition, perhaps at a reduced speed (depending on how much RAM your PC has, how fast it is, etc.), but without temporary files. The best performance is achieved with .zpaq archives on solid state drives (now very common) and a large amount of RAM (32GB or more) and many cores (even 8/16 and more). For magnetic risks with less powerful PCs, performance is logically lower.
   Probably (we'll see) for PCs with very large amounts of RAM (128GB+), I could do even better. But in 2026, the price is rising significantly, so I don't think it will be a priority in the short term.

Important considerations

There is a lot to say.

This is almost entirely experimental code, with a concrete
(and in fact almost certain) possibility of bugs, including severe ones.

Pay maximum attention when using version 64.1, both for normal
operations (archiving), for Windows imaging, and especially for restore.

Let me be very clear: sector-level restore can (and generally does)
cause irreversible data loss if used incorrectly.

Therefore, first become familiar with restore operations in safe environments,
such as virtual machines, where potential issues do not cause damage.

I am performing extensive testing to improve reliability; however,
large internal changes necessarily require extensive validation.

For production use, or on non-Windows systems (where differences are minimal),
do not rush adoption.

At the moment, only the fastest archiving algorithm (turbo) is available,
and it is itself not well tested in complex scenarios.

My recommendation is therefore: use this version in safe environments and report any issues you encounter, so they can be fixed.

As a final encouraging note, I have successfully restored an entire
Windows C: disk, which is the ultimate goal 😄

Summary

1. The -vhd mode no longer exists
2. The (older) -ntfs mode no longer exists
3. The -frugal mode no longer exists in imaging
4. It is no longer necessary to extract archives to disk and then write them (direct .zpaq=>disk)
5. During extraction (using the x command) of an archive containing an image
   (e.g. created with -image -ntfs), a .vhd file is created directly.
   This file can be mounted (e.g. with OSFMount or FTK Imager) or opened with 7-Zip
   to obtain a GUI.

The generated VHD is thin-provisioned, meaning it occupies only the
space actually in use.

Future developments will include:

• a disk partition “browser” (currently you must use the drive command)
• improved support for restoring to partitions of different sizes

Final important note

At present, restoring partitions is supported only onto the same partitions.

That is, you back up F: from a USB hard disk and restore F: onto the same disk.

Restore onto larger partitions is partially (very partially) supported,
while restore onto smaller partitions is not supported at all.

Therefore, I do NOT recommend restoring, for example, F: onto G: (yet).

DO NOT mix different images on the same archive (yet), do not

zpaqfranz a d:\backup.zpaq f: -image -ntfs
zpaqfranz a d:\backup.zpaq g: -image -ntfs

This is good

zpaqfranz a d:\backup.zpaq f: -image -ntfs

(... do something...)
zpaqfranz a d:\backup.zpaq f: -image -ntfs

Tech note

Inside the .zpaq you'll get 4 different files (for example for F, with -ntfs)

• image_F.fhd The cluster data (interleaved with vhd bitmaps)
• image_F.footer The VHD footer
• image_F.header The VHD header
• image_F.meta The franz's header

or

• image_F.raw Just about everything (-raw)

Scenario

The scenario that interests me most is not creating a disk imaging program (there are many, much better ones out there) but rather creating an additional mechanism for copying C: that can be easily encrypted and uploaded to the cloud.
In this scenario, recovery is very rare, while copies are made daily.
So the emphasis is on having versioned copies that take up as little space as possible.
This is something that virtually all other programs, including those with incremental copying, are not very efficient at.
Another scenario is a homemade anti-ransomware copy, on a large USB stick or (better) an external USB SSD hard disk, spending as little as possible while maintaining the ability to restore far back in time (months and months).

Remember

The more feedback, the better the software will become
Be free to report anything wrong