The APFS Dilemma

Preface: This is my first blog so this may be a bit of an odd read!

Some background: I needed to backup 1.4TB of data from a read-only corrupted HFS+ LaCie, wipe it, format it as APFS, and write it back.

What I then chose to do was to back the data to a 1TB 3.5-inch HDD formatted as Btrfs. I would use Restic backup to backup the data so that it would fit, then when I format the original drive as APFS I can just copy it back. Simple!

It was not simple.

Backing up with Restic was fine (albeit very slow with the amount of data).
I used apfsprogs to format the drive as APFS, and then proceeded to restore from the Restic backup to the APFS volume with linux-apfs-rw.

I saw the disclaimer: "If you make use of the write support, there is a real risk of data corruption"
Yeah, it'll be fine... If it fails, there won't be any data loss as I have a backup so I might as well try.

Write speeds were about 5MB/s - we are gonna be here for a while...

Time passes...

Suddenly I see a stream of errors: "No such path or directory"
What?
I check the Restic repo and the files are still there and accessible.
Hmm.
I try touching a file on the LaCie: "Read-only file system"
Right... Well it's not like I wasn't warned!

At this point I felt like trying again wasn't worth it so I thought of other solutions. The obvious thing would be to just let the Mac write the data but then you remember:

  1. macOS doesn't support Btrfs
  2. None of the Macs in my possession have SATA and power cables for a 3.5-inch HDD.

What if I run a macOS VM on my extra PC and use that to restore to a fresh APFS volume on the LaCie?
Then I can connect the SATA HDD to my the PC, pass it through to the VM and macOS can access it!
What about Btrfs? I know! I can host a samba share and the VM can mount it locally.

Although quite convoluted, this may be the solution.

After fixing my bricked Ubuntu Server install, I got to work...

Around two hours later I had successfully started the transfer.
Here's how I set it up:

I ran the macOS VM with QEMU using osx-kvm. I had to tweak a few QEMU args in OpenCore-Boot.sh:

-  -monitor stdio
+  -daemonize
+  -drive file=/dev/sda,format=raw,if=virtio
+  -vnc 0.0.0.0:0

This does the following:

  1. Alters the configuration so that instead of opening a GUI window, it starts a passwordless VNC session that I can connect to, to control the VM
  2. Adds my LaCie drive (I had to temporarily give my user access with sudo chown leo /dev/sda) as an available disk
  3. Forks the process to the background so I can disconnect from the SSH session
  4. Disables the QEMU monitor

I then:

  1. Started the VM, connected via VNC with Remmina from my main PC and booted to recovery
  2. Formatted the drive as APFS with Disk Utility
  3. Opened a terminal window to prepare for the restore
  4. Edited the Samba config on the PC to expose the backup drive, mounted the extremely secure share on /tmp/mnt via the terminal in macOS recovery with:
    mount -t smbfs //root:123@192.168.0.116/sambashare /tmp/mnt/
  5. Downloaded the macOS Restic binary and tried to extract oh wait... turns out there is no bzip support.
  6. Downloaded the binary to my main pc, extracted it, and uploaded to my personal file share
  7. Downloaded the binary from my file share to macOS recovery... And it runs! Awesome!

Now for the moment of truth. Will Restic successfully start restoring the backup?
Let's see if we can access some files first:

-bash-3.2# ./restic_0.18.1_darwin_amd64 -r mnt/lacie/ ls latest / --insecure-no-password
repository 8e437lea opened (version 2, compression level auto)
created new cache in /var/root/Library/Caches/restic
Load(<index/ea8643d9c5>, 0, 0) returned error, retrying after 611.813889ms: Copy: write /var/root/Library/Caches/restic/8e4371eab6279eb2412fa9e38eeb7e63c304
948a516dd51cabc8358de67410ff/index/ea/tmp-4266986855: no space left on device
Load(<index/916e15952b>, 0, 0) returned error, retrying after 627.814743ms: Copy: write /var/root/Library/Caches/restic/8e4371eab6279eb2412fa9e38eeb7e63c304
948a516dd51cabc8358de67410Ff/index/91/tmp-2715735516: no space left on device
Load(<index/4b3e4dfdbd>, 0, 0) returned error, retrying after 510.926124ms: Copy: write /var/root/Library/Caches/restic/8e4371eab6279eb2412fa9e38eeb7e63c304
940a516dd51cabc8358dc67410f f/index/4b/tmp-4002421735: no space left on device

Ok, the default cache location was read-only, (how convenient!) let's try setting RESTIC_CACHE_DIR to somewhere writeable:

-bash-3.2# export RESTIC_CACHE_DIR=/tmp/restic
-bash-3.2# ./restic_0.18.1_darwin_amd64 -r mnt/lacie/ ls latest / --insecure-no-password
repository 8e4371ea opened (version 2, compression level auto)
[0:01] 100.00% 40 / 40 index files loaded
snapshot cd8e0@1d of [/run/media/leo/LaCie] at 2026-05-16 14:17:06.115395518 +0100 +0100 by root@gentoo filtered by [/]:
/run

Yay!

Now, let's try restoring:

-bash-3.2# ./restic_0.18.1_darwin_amd64 -r mnt/lacie/ --insecure-no-password restore --target /Volumes/LaCie/ latest:/run/media/leo/LaCie --include-file include
repository 8e4371ea opened (version 2, compression level auto)
[0:01] 100.00% 48 / 40 index files loaded
restoring snapshot cd8e001d of [/run/media/leo/LaCie] at 2026-05-16 14:17:06.115395518 +0100 +2102 by root@gentoo to /Volumes/LaCie/
[3:10:06] 54.10% 474485 files/dirs 730.484 GiB, total 1156238 files/dirs 1.319 TiB

(this was taken a while after)

Success! And it's much faster for some reason - even with Samba and QEMU!
Wow. What a journey!

After all that we ended up with this chain:

Backup drive -> Server PC -> Samba share -> TCP -> mounted share macOS VM -> Restic repo -> APFS volume on LaCie -> QEMU passthrough -> Server PC -> LaCie over USB

Phew! That was quite a mouthful!