Will migration assistant work with a non-Apple filesystem?

[m4rkw]

Scenario: currently use CCC with locally attached disks. Would like to back up over the network but I don't want to buy another mac, so I'm using an rpi4 with usb disks attached to expose a network share.

This works, but CCC creates a sparsebundle on the network share in order to have an APFS volume. This is somewhat inefficient.

So if I were to just rsync the macOS filesystem over ssh to a mounted volume on the rpi, which would be ext4, could I then use the same volume with Migration Assistant using the Paragon ext4 filesystem driver for macOS? I'm not sure if there are any weird artefacts of mac filesystems that would stop migration assistant from working if the data was synced over to an ext4 volume.

Thanks

 

[appltech]

So far, apple's official page mentions macOS and WindowsOS (Windows 7+) when working with Migration Assistant. That would give us macOS file systems and some information from NTFS, exfat, fat32 volumes. Since ext4 is mostly used with Linux (if i'm not mistaken), Migration Assistant may not recognise the data in the sparsebundle or it can say that the drive is not valid as a backup source

 

[NoBoMac]

Have not tried something like this, but guessing will not work. Think the big hint is that CCC is creating sparse bundles to handle APFS and the data and OS volumes in the drive container.

Add in that MacOS is using firmlinks to do the melding of these volumes. Add in possible hard links buried in things, access control lists, meta data files (eg. the . and _ files you see when copying to a NTFS, exFAT drive), etc that might not translate well, if at all, over to alien file systems, rsync is ok for creating a backup of data files, but it with this setup just seems like trouble.

 

[chown33]

In the phrase "somewhat inefficient", please quantify "somewhat". Is it a 5% speed loss, or 75%? I assume you referring to speed when you say "inefficient", but are you actually referring to some other quality?

The overhead of a sparse bundle on another filesystem should be minimal. The components of a sparse bundle are just 8MB files ("band" files), which are effectively treated as blocks with seekable sub-addressing. So if the underlying filesystem can deal adequately with 8MB files doing read/write/seek, then the speed cost should be negligible.

As an experiment, you could use a FAT filesystem underlying the sparsebundle and see if there's a difference in speed. My guess is it won't make much difference, and other factors such as the Pi's USB driver, or even the network transfer limitations, may be at least as large a factor. It might even be the USB disks, which you haven't identified or characterized.

I'd also be careful to separate latency from throughput in the measurements. The hit may be due to latency, which would likely need different solutions than attempts to improve data throughput (bandwidth).


Finally, since you give a specific use case (Migration Assitant on a TimeMachine backup), you could try something like using 'rsync' to copy files to the ext4 storage, then try Migration Assistant on a new disposable account you create on the Mac. If MA is unable to make sense of the rsync backup, then it seems like a definitive answer, regardless of any perceived inefficiencies of a sparse bundle.