I have a suspicion that this problem is related to the libresolv security patches applied in https://support.apple.com/en-us/HT213257 and https://support.apple.com/en-us/HT213256.

@mikeyh Thank you so much for this. I have just tried your patched code and it is working in my build process. I'll refrain from marking your solution as accepted for now, just in case there are more comments/improvements from others, but it seems to be working fine.

I am pretty sure the limiting factor here is not the RAM allocated to the copy/move process but instead the speed of your devices. What is the transfer rate of your source device? What is the transfer rate of the target? Are you using USB? Are these SSD devices? Is it a network connecton? All of these have for more impact than the amount of memry allocated to the process.

By default CCC will only do a clone of the Big Sur data volume. I suspect that you have not made a bootable backup, i.e. also including the system volume. The CCC web-site has details on how to make a bootable backup with CCC running on Big Sur.

I think the only way to recover this is to reinstall macOS and then restore your data from your most recent backup. You are not alone in having done this - I made a similar mistake 30+ years ago on a Solaris machine, but fortunately had a full (and recent) backup to recover with. Consider it as a 'rite of passage' to being a Unix system admin and don't do it again :)

On 11.0.1 Beta (20B5022a) bryan@nvbigsur mapfail % cc -m64  -g -Wall -Werror -o mapfail mapfail.c bryan@nvbigsur mapfail % codesign -vvvv mapfail mapfail: code object is not signed at all In architecture: x86_64 bryan@nvbigsur mapfail % ./mapfail 10000000 10000 maping from 0x10000000 to 0x10010000 is OK Unable to reserve 0x10000000 for the test1 heap,  using 0x10ad37000 instead test1 heap mapped from 0x10ad37000 to 0x10ad48000 bryan@nvbigsur mapfail % 

This crash is caused by a bug in VirtualBox. A possible workaround is to disable Audio in the settings for that virtual machine.