Open shasheene opened 4 years ago
I borrowed a 2014 Mac Mini and tested the above commit.
As I have noted in the commit message:
In testing, partclone v0.3.13 as available on Ubuntu 20.04 Focal has immature APFS support exiting with "bitmap error" when using a real APFS filesystem. Until there is a focal-backports (or focal-proposed) version of partclone (perhaps v0.3.14 [2]), this commit should not be merged. [1] https://launchpad.net/ubuntu/+source/partclone [2] https://github.com/Thomas-Tsai/partclone
From the rescuezilla log:
*** Processing sda2 (apfs) using partclone.apfs...
umount: /dev/sda2: not mounted.
*** Executing: ( partclone.apfs -c -F -L //mnt/backup/mac.mini/rescuezilla.backup/20200519_part2_partclone.log -s '/dev/sda2' | pigz -c --fast | split -d -a 3 -b 2048m - //mnt/backup/mac.mini/rescuezilla.backup/20200519_part2. ) 2>&1 |
Partclone v0.3.13 http://partclone.org
>>> Starting to clone sda2
>>> List of partitions:
* sda1
* sda2 (Processing)
>>> Reading super block
>>> Calculating bitmap
>>> Warning: bitmap error
Hardware information in the log (via print_drive_list() function):
*** sda ***
desc = Drive 2 (223.57GB): KINGSTON SA400S3 (EFI, 200.00MB VFAT) (223.38GB APFS)
device = sda
enduser_drive_number = 2
model = KINGSTON SA400S3
parts = HASH(0x55e8a8c52e20)
Part 1:
bytes = 209715200
fstype = VFAT
label = EFI
os =
partition = sda1
partition_number = 1
size = 200.00MB
Part 2:
bytes = 239847653376
fstype = APFS
label =
os =
partition = sda2
partition_number = 2
size = 223.38GB
size = 223.57GB
type = scsi
It might be worth building partclone 0.3.14 from source and evaluating if APFS support has improved. If partclone.apfs 0.3.14 works, it either has to be built from source as part of the build scripts (perhaps for both i386 and amd64?), or backported as part of Ubuntu's bionic-backports and focal-backports repositories.
But it doesn't make sense to delay the Rescuezilla v1.0.6 release for filesystem-aware APFS support.
I'm backing up a HFS+ disk right now, and currently it's chugging along at 5 MB/s. Am using 2.1.3. Any update on this?
Update: I was running it in a virtual machine with 1 core allocated. htop reported 100% of that core, so I gave it another core, which increased the speed to 12 MB/s. The host has an i3-5015U.
If it's HFS+ I would have expected things to go pretty smoothly.
I bet it's your compression settings that's killing you on CPU usage. Please try using Rescuezilla v2.2 and try making an uncompressed backup!
The partclone package available on Ubuntu 20.04 contains an APFS partclone binary, which should provide the ability to only copy used space from Apple File System (APFS) filesystems which are used on macOS High Sierra (10.13) and later.
For those unfamiliar with macOS filesystem history, between 1985-1998 the default filesystem was HFS, and between 1998-2017 the default macOS filesystem was HFS+. partclone supports filesystem-aware cloning of HFS+, but not HFS. This applies to Rescuezilla too.
It's unclear how mature partclone APFS functionality is, so this needs to be examined.
Rescuezilla 32-bit note: Because there is no 32-bit Ubuntu 20.04 build, Rescuezilla 32-bit remains on Ubuntu 18.04 does not have access to this binary. A more recent version of partclone with APFS support may be available through the backports repository, but right now there is no need to do this -- no reason why any user interested in APFS support couldn't use the 64-bit Rescuezilla release.