A basic Mac system consists of the Mac itself and external storage for its backups, and is by far the most popular configuration. For many folk backing up the whole of its Data volume is wise, but that isn’t always the most economical. If the Data volume contains large items that don’t need to be backed up as often as its working folders, that can waste space. This article shows how you can make it more efficient without additional cost or hardware.

Backups and local snapshots

Most good backup utilities including Time Machine also make local snapshots of the volumes they back up. Let’s say your Data volume contains 100 GB of files that either change little or don’t need to be backed up as frequently as the rest. One proven strategy for minimising the time and storage required for backups is to add those to the exclusion list, and back them up separately, maybe only once a week. You can do that to another volume on external storage, provided you ensure there’s sufficient space for both that and your normal automatic backups.

What that doesn’t do is keep those 100 GB out of the frequent snapshots made of the Data volume. While you can exclude files and folders from backups, snapshots always include everything in that volume, without exclusions. The only way to save the space they add to snapshot size is to move them to another volume that doesn’t get snapshots made of it. But your Mac’s standard disk layout doesn’t provide any spare volume for that.

This could apply to all sorts of relatively static data that doesn’t need Time Machine’s automatic hourly backups, including Virtual Machines and some large media libraries, although you won’t then be able to share these in iCloud Drive, which would require them to be in your Data volume.

Boot disk layout

Standard layout of the internal SSD of an Apple silicon Mac running Sequoia or earlier is shown below.

Intel Macs have the same Apple APFS container with the Boot Volume Group in it, but the other two containers are replaced by a single small EFI partition.

Adding another partition or container is possible, but not recommended as it has a fixed size, and lacks the flexibility of a volume. It also risks disturbing the three existing partitions/containers. As they’re essential for the Mac to start up successfully, you don’t want to meddle with them.

In practice, the best place to add a new volume is inside the third container, the one already holding the System and Data volumes. Add that in Disk Utility once you’ve decided the next two steps.

Limit volume size

Your new volume is going to share space in its container with all the existing volumes, including both System and Data. It’s usually wise to impose a maximum limit on the size it can grow to, to avoid compromising any of those. When you add the new volume, put a sensible limit on its Quota Size.

Encryption

Although Apple’s documentation isn’t explicit, volumes added to the boot container aren’t protected by FileVault, unlike the Data volume. If you want your extra volume to be encrypted, you’ll have to format it in APFS (Encrypted). Whether that’s accelerated by the hardware in the Secure Enclave isn’t clear, and on Apple silicon Macs it’s hard to tell the difference, as you should get similar full speed performance from your extra volume to that of the Data volume.

Setting it up

Open Disk Utility, ensure its View options are set to Show All Devices, then select the Container holding the boot volumes. Click the + tool to add the new volume.

Give the volume a name, then click on the Size Options… button.

Enter your chosen Quota Size, as the maximum you want to allow the extra volume to use on the boot SSD, and click OK.

Then select whether you want it formatted in plain APFS, or encrypted, and click the Add button.

If you’ve opted for APFS (Encrypted) you’ll then be prompted to enter the encryption password. Unlike FileVault, there’s no option for a Recovery Key, or for iCloud Recovery.

When you first unlock the extra volume, you’ll be given the option to save its password to your keychain. That confirms this isn’t being performed by FileVault, as that protects its encryption keys in the Secure Enclave.

There are a couple of quirks:

• If you try unmounting the extra volume using the Finder’s contextual menu, macOS might try to unmount all volumes on the boot disk, and warn you that it can’t. Simply cancel those warnings, and the extra volume should unmount fine. If you’re worried by this, unmount the volume in Disk Utility, which isn’t as silly.
• You can use the Finder contextual menu to encrypt or decrypt the volume if you change your mind.

Summary

• To save space in local snapshots made for backups of your Data volume, move bulky items that you back up separately to an extra volume alongside the Data volume.
• Set a Quota Size on the extra volume to limit the maximum space it can take.
• Use plain APFS or APFS (Encrypted) as the extra volume can’t be protected by FileVault.
• If you encrypt the volume, safeguard its password as there’s no recovery option if you lose it.
• The extra volume performs as well as any other volume on the internal SSD, and is far faster than using external storage.

Time Machine and other backup utilities don’t back up absolutely everything. The list of folders and files that don’t get saved in your Mac’s backups is long, and hidden away out of sight. For Time Machine that used to be in /System/Library/CoreServices/backupd.bundle/Contents/Resources/StdExclusions.plist but now in .exclusions.plist at the top level of any backup. This article explains the more important in that list, and others that could trip you up. I’ll consider these according to the categories in that file.

TM Backup Exclusions

apiExclusionPaths

These are added by individual third-party apps, by setting the isExcludedFromBackupKey URLResourceKey for that file every time it’s saved. Otherwise this category might be empty.

standardExclusionPaths

This is a long list of standard paths that are set by macOS as not for backup, including:

• .DocumentRevisions-V100 – the version database on each volume, added to this list in Big Sur,
• .Spotlight-V100 – Spotlight metadata including indexes, which will be regenerated after restoring a volume,
• .Trashes – the contents of all Trash folders,
• .fseventsd – the File System Events database,
• /Library/Logs – traditional text log files, not those for the Unified log which are included in backups,
• /Users/Guest – any guest user files,
• /private/var (partial) – various transient files,

among many other ephemeral items.

Of those, only one results in any significant loss of data, the version database. Although this was dutifully copied by Time Machine into backups for several years, the current structure of that database makes it impossible to restore successfully, even when restoring a complete volume. By the middle of the Catalina cycle, it had become a frequent cause of Time Machine choking, so was added to the standardExclusionPaths for Big Sur. As far as I’m aware this was never fixed in Catalina.

stickyExclusionPaths

These are items with an extended attribute of type com.apple.metadata:com_apple_backup_excludeItem attached, including various database and related files inside Photos Libraries. In the event that a library is restored from a backup, they’re freshly regenerated from the library’s contents.

Another interesting exclusion here is the Siri Analytics database included in any sysdiagnose stored in the volume(s) being backed up, in the path
sysdiagnose[datestamp]/logs/SiriAnalytics/SiriAnalytics.db. Presumably that’s for privacy reasons.

systemFilesExcluded

This key is set to true to ensure the whole System volume is always excluded.

userExclusionPaths

These are exclusions the user has set using tmutil or in Time Machine settings, using the Options… button.

By default, volumes on external storage are automatically added to this exclusion list; if you want an external volume to be backed up by Time Machine then you’ll need to remove it from the exclusion list manually.

iCloud Drive

When backing up the current Data volume, by default all files in iCloud Drive that are downloaded to that Mac at the time the backup is made, will be included in that backup. However, any that have been evicted (their download has been removed) will not be backed up, as their data isn’t present locally on the Mac, and that file is dataless. To ensure that those are backed up, download them all prior to the backup starting, and ‘pin’ those you want to remain downloaded in future.

Local snapshots and backups

Any snapshots of a volume aren’t backed up, indeed they can’t be copied to another volume. The same applies to Time Machine backups.

Local snapshot exclusions

All items in the volume at the time a local snapshot is made are included in that snapshot. There are no exclusions from local snapshots, apart possibly from some obscure items internal to APFS.

Third-party backups

Mike Bombich gives a thorough and detailed account of what CCC doesn’t copy on this page. Other backup utilities should also provide full lists on their support site.

Replicated or ‘cloned’ volumes

These should also include the entire contents of the volume as if a snapshot.

In my introduction to the macOS document versioning system, I explained that a document could lose all its saved versions when moved to another volume. This sequel provides more detail about how you can preserve or lose those saved versions.

When you save the first version of a document, a record is created in the hidden database on the same volume as that containing that document. That record refers to the file not by its name or path, but by its inode, its unique file system number. Anything that preserves that inode number will thus tend to keep its saved versions; anything that creates a new file with its different inode number is guaranteed to lose all versions.

What’s safe

The following actions are version-safe:

• moving the file anywhere within the same volume;
• renaming the file, changing its permissions, adding extended attributes, adding a custom icon, or editing the file’s data;
• creating a Finder Alias or symbolic link to the file;
• rolling back a local snapshot, which will return the versions to the same state as at the moment that snapshot was made; volume snapshots include the whole version database, and preserve inode numbers;
• ‘cloning’ the whole volume to make an identical copy of everything in it;
• if the file is stored inside a disk image, then that disk image can be copied or moved safely, or backed up; that also applies to files stored inside Virtual Machines.

What loses versions

The following actions are destructive of versions:

• moving the file to a different volume; the original file on its original volume will retain its versions, but they won’t copy across to the new volume;
• duplicating the file; the duplicate, an APFS clone file, will have no versions at all;
• saving the file as a new file, with a Save As command;
• compressing or archiving the file; the copy in the archive won’t have any versions;
• saving the file to a file system like ExFAT or MS-DOS, which don’t support versions;
• backing the file up to another volume, as versions can’t even be backed up by Time Machine;
• moving or copying the file over a network.

If you try to save versions on a file system that doesn’t support them, you aren’t warned when saving those versions, as those appear to remain cached. Normally the first warning is given when you try to close the file.

If you want to keep versions, click on Cancel and save that file to a volume that does support versions.

The version database can only be created on a volume that has sufficient space to support it. This doesn’t normally affect working with regular APFS volumes, but can be a problem if you’re intending to store the file in a disk image or sparse bundle. You should find that a minimum size of 1 GB will support limited versions, but 500 MB is definitely too small for support, and will result in a warning when you try to close the file.

iCloud Drive

The behaviour of versions in iCloud Drive might appear confusing unless you remember the rule that they are saved for that file’s inode number. Here I’ll look at the example of a file that’s in a different folder from iCloud Drive (or Documents in iCloud) and is moved to iCloud Drive.

If that file is already in the current Data volume, that’s the same volume as local copies of what’s in iCloud Drive, so moving it to iCloud Drive keeps it within the same volume, and versions are preserved. If that file is evicted from local storage, that only removes the data for that file, and doesn’t change its inode number. When the file is downloaded again and opened, its versions are still there.

On another Mac connected to the same iCloud Drive, though, the versions are on a different volume on another Mac, so if that opens the file, there are no saved versions available. If that Mac adds its own versions to the file, they will be saved locally, and will be accessible to that Mac.

Saving versions to files already in iCloud Drive is more complex, as different versions of macOS, iOS and iPadOS have saved some into iCloud, so I will look at that in a separate article.

Preserving versions whatever

The only way that I know to preserve all the versions of any file is to save each of them individually in a folder, numbered so that the original versions can be recreated on another volume. While you can use my utility Revisionist to do that, a simpler drag-and-drop approach is provided by Versatility.

There’s no screenshot to show: all you do is drag a file with versions onto Versatility’s blue landing pad. You’ll then be prompted to name and locate the folder it creates containing the file’s versions. Once made, you can move them around like any other Mac folder, back them up, Zip the folder and send it to a colleague.

To reconstitute the original, simply drop the folder onto Versatility’s pad. You’ll then be prompted for the name and location of the file to be saved. That file will contain all the versions saved in the original, ready to use.

If you wish, you can edit the versions in the archive folder created by Versatility. When the file is reconstituted the individual versions will simply be reassembled in numerical order.

I’m also delighted to confirm that both Versatility and Revisionist are fully compatible with macOS Sequoia.

Key point

Versions are linked to the inode number of their file. Actions that preserve that on the same volume should retain those versions. Anything that creates a new inode number or uses a different volume won’t retain those versions.

The first file system for Macintosh computers wasn’t HFS+ or even its predecessor HFS, but Macintosh File System, MFS. This was introduced in System 1 on the 128K Mac just over 41 years ago, to support its 400 KB floppy disks. Although it was fairly primitive, it incorporated some visionary features, including forks. Each file had two sets of data: a data fork as in other file systems, and a resource fork for storing structured blobs of data or resources.

File naming was liberal compared with MS-DOS, allowing names up to 255 characters long, although that was restricted to 63 by the Finder. Names could consist of any printable character except the colon :, a limitation that persists in the Finder today. As there was no directory hierarchy, folders were an illusion and couldn’t be created directly by the user. Instead there was always an Empty Folder available, and when that was used, a fresh Empty Folder was created. As this was a single-user file system, there were no permissions.

MFS was still supported until it was finally discontinued 13 years later in System 8, in 1997.

Hierarchical File System, HFS

MFS had been designed for the low-capacity floppy disks of the time, and not for use on hard disks, where its limitations would have been only too apparent. For the release of the Macintosh Hard Disk 20 in September 1985, and in anticipation of the Macintosh SE 18 months later, a new Hierarchical File System had to be released to replace MFS in System 2.1. HFS remained fully supported until the arrival of Mac OS X 10.6 Snow Leopard in 2009, and finally dropped altogether in macOS Catalina a decade later.

Developed by Patrick Dirks and Bill Bruffey, HFS maintained many of the novel features in MFS, with resource forks, long file names up to a maximum of 31 characters, still excluding the colon, and in its standard single-user version didn’t support permissions. The latter were incorporated into AppleShare later. File and folder names were case-preserving but case-insensitive.

Larger storage capacities brought the need for a hierarchical directory structure, implemented using B-trees in a Catalog File that made the display of even large directories very quick. Although much of HFS used 32-bit integers, that didn’t apply to the number of files in a logical disk, which was limited to 65,535, which must have seemed sufficient at the time, and given the maximum volume size of 2 TB. With early hard disks being measured in tens of MB, that may have seemed in the distant future.

Mac OS Extended, HFS+

With the growth in capacity of hard disks, HFS had to be updated to address its limitations, in a project with the internal name of Sequoia, delivering HFS+ in Mac OS 8.1 in 1998. Switching to 32-bit fields to identify allocation blocks allowed more efficient use to be made of storage and a larger number of files in each volume. File names were increased in maximum length to 255 characters, and changed from MacRoman encoding to Unicode UTF-16 to accommodate a broader range of languages. Support for additional forks beyond data and resource paved the way for the switch to extended attributes, and OS startup support was improved to allow alien operating systems to boot from HFS+ volumes.

This screenshot shows a set of custom icons in a BNDL resource, in the QuarkXPress app in about 2000.

This shows file information available in HFS+ in Classic Mac OS in 2002.

HFS+ and its predecessors were prone to develop errors as a result of operating system crashes and other unexpected events, and those could be cumulative, leading to data loss. This was addressed with the introduction of journalling, designed and implemented by Dominic Giampaolo, who came to Apple from implementing the file system for BeOS. This was tentatively introduced as an option in Mac OS X 10.2.2 in late 2002, and made a standard feature in 10.3 the following October. Alongside that came an optional wrapper for case-sensitivity in what was dubbed HFSX, and a change in Unicode decomposition to Normalisation Form D (NFD).

Mac OS X 10.4 augmented Posix permissions with Access Control Lists (ACLs), although they were little-used outside server environments for some years. Prior to 10.5, as with most other file systems, HFS+ supported file but not directory hard-links. With the introduction of Time Machine in 10.5 Leopard, directory hard-links were added to support the structure and illusions of Time Machine backup stores.

File system support for encryption was a bit more troubled. The original FileVault, introduced in 2003 with Mac OS X 10.3 Panther, located user Home folders in an encrypted sparse disk image, which was improved in 10.5 by moving to sparse bundles. This suffered several shortcomings and vulnerabilities, and was replaced by whole-volume encryption in FileVault 2 in Mac OS X 10.7 Lion. That required the addition of a logical volume manager, Core Storage, which was then used for Fusion Drives introduced in 2012.

Apple File System, APFS

HFS+ had been designed for computers with hard disks. It lacks some of the features of more modern file systems such as snapshots, special files such as sparse files, and concurrent access. It’s also not well-suited to use with SSDs and storage in smaller, mobile devices, although when the first iPhone shipped with iOS 1.0 in 2007, it used HFSX, the case-sensitive variant of HFS+. That was until the release of iOS 10.3 on 27 March 2017, which silently converted its file system to APFS.

In 2014, Apple had decided to write its own file system from scratch, and Dominic Giampaolo, responsible for journalling in HFS+, and Mike Mackovitch became its lead engineers. APFS was announced two years later at WWDC in 2016, when it was expected to be released in another 18 months if development and testing went smoothly. Those who had hoped for ZFS were disappointed and many remain so today. macOS Sierra already had a pre-release version for those who wanted to preview it, but as we discovered when we upgraded to High Sierra, that was a far cry from what was to come.

After a promising period in beta, Apple discovered fundamental problems between APFS and its popular Fusion Drives. The first release of macOS 10.13 shipped with APFS version 748.1.46, but abruptly dropped support for those, so converted only those startup volumes on SSDs and hard disks. Snapshots were wobbly at first, and it quickly became clear that APFS was never going to perform well on rotating disks.

High Sierra had a stormy early release history, marred by a series of security gaffes. Vulnerabilities were fixed in the Supplemental Update released less than two weeks after 10.13, leaving snapshots to be improved in 10.13.1 on 31 October. Many expected problems with Fusion Drives would be fixed quickly, but those weren’t ready for release until the following September. Another problem that troubled the introduction of APFS to all platforms was the refusal during beta-testing to incorporate Unicode normalisation; this had to be resolved in later versions of macOS 10.13 and iOS 10, as explained here and here.

In September 2018, Apple at last released Mojave 10.14 with support for Fusion Drives, accompanied by the first version of the Apple File System Reference. Although a long and detailed document, developers soon realised how incomplete it was, in spite of the long delay in its publication. At last third-party file system developers had some hard information to work with, and users started assuming that third-party disk maintenance and repair tools were imminent.

Catalina brought major changes to APFS, with the use of expanded volume roles to form System Volume Groups, with their separate but firmlinked System and Data volumes. macOS 10.15.5 fixed a serious bug preventing the transfer of very large amounts of data to RAID volumes. At that time, Apple released an updated version of the Apple File System Reference, building expectations that third-party tools were just round the corner, at least among those who weren’t aware of how much information was still missing. Nearly five years later, it’s still that same edition dated 22 June 2020 that remains the latest information released by Apple about APFS.

Further major changes came with Big Sur 11.0.1 when it was released in November 2020, introducing the sealed and signed snapshot now used to boot macOS. This was also the first release to support making Time Machine backups to APFS volumes, and to support Apple silicon Macs.

Although Apple dropped early hints that APFS might be released as open source, unlike its predecessors, after eight years, information about its internals released by Apple still appears to be insufficient to allow third-party developers to create maintenance tools independent of those bundled in macOS. This reluctance may stem from the deep involvement between the file system and macOS security.

Summary timeline

• MFS Jan 1984 – Sep 1985, end of support 1997
• HFS Sep 1985 – Jan 1988, end of support 2019
• HFS+ Jan 1988 – present, still supported
• APFS Sep 2017 (iOS March) – present, still supported

References

Inside Macintosh: Files, Chapter 2 – File Manager, on HFS
MacCyclopedia critical account of HFS and HFS+. 25 May 2003
Apple TN1150 HFS Plus Volume Format, 5 March 2004
Apple’s APFS Reference (PDF), last revised 22 June 2020.

Wikipedia on
MFS
HFS
HFS+

APFS has two special file types designed to economise on storage space: clone and sparse files. Clone files are two or more distinct files within the same volume whose data is shared; sparse files save space by skipping empty data and only storing data containing information. This article explores how they behave in use, with particular emphasis on Time Machine backups and iCloud Drive. The latter also involves a third type of special file, dataless files.

Clone files

In contrast to hard-linked files, clone files are two or more distinct files within the same file system (volume) whose file extents are identical, so share the same data, as shown below. They’re created by variants of normal file copying, including duplicating in the Finder (and drag-copying within the same volume), and the cp -c command.

Instead of duplicating everything, only the inode and its attributes (blue and pink) are duplicated, together with their file extent information. You can verify this by inspecting the numbers of those inodes, as they’re different, and information in the attributes such as the file’s name will also be different. There’s a flag in the file’s attributes to indicate that cloning has taken place. At first, the two cloned files share the same data blocks and extended attributes, but as the two files are changed by editing, they start to drift apart and become uncloned.

Clone files are becoming more popular thanks to the Hyperspace app, which deduplicates files within the same volume by replacing copies with clones.

Because they can only exist within the same file system, clone files are fragile. Any copy or move to another file system is invariably accompanied by the copying of their full data, and their economy of storage can only remain as long as they stay within the same volume.

Backups

One notable exception to this same-volume rule is in Time Machine backups. As clone files are preserved in local snapshots, when Time Machine constructs a backup as a snapshot in the backup storage volume, shared file extents are retained, so preserving clones. This is reflected in the size of the backup snapshot, and in the report written to the log. For example, when backing up three distinct files and ten clones of one of those, that report included:
14 Total Items in Backup (l: 16 GB p: 11.02 GB)
3 Files Copied (l: 6 GB p: 1.02 GB)
1 Directories Copied (l: Zero KB p: Zero KB)
10 Files Cloned (l: 10 GB p: 10 GB)

Backups made by other utilities are unlikely to reproduce this behaviour, though, as they can’t synthesise snapshots in the way that Time Machine does. To preserve clone files in their backups, they’d have to identify clones in the source and explicitly perform cloning in their backup store. Although Carbon Copy Cloner claims that “in some cases CCC may clone a file on the destination prior to updating its contents”, it doesn’t appear to attempt to preserve clone files in the backups it makes. I’m not aware of any third-party utility that does.

Unfortunately, Time Machine appears unable to restore directly from backup snapshots in the backup store, and performs Finder copies when restoring. That saves each of those clone files as a completely separate file, without any sharing of data. As a result, the space occupied on disk for a restored volume can be substantially greater than the original or its backup. Extensive use of clone files could thus cause problems when restoring from backups.

Of course, rolling a volume back to a local snapshot, such as one made during Time Machine backups, preserves all clone files within that volume.

iCloud Drive

Clone files created within the same volume as local iCloud Drive storage on the Data volume, or cloned when within a folder in iCloud Drive, remain within the same file system and clones are therefore preserved, and when the file is moved to other folders in the same volume.

However, clone files are treated as simple copies as far as iCloud Drive’s remote storage is concerned. While a pair of cloned 5 GB files only use a total of 5 GB local storage, they require a full 10 GB of your iCloud allocation, indicating that their cloud storage is separate and not common to both. Although the effects of eviction (removing local data) and materialisation (restoring local data from cloud storage) are difficult to observe directly, they appear to lose the benefits of cloning.

When the local copy of a file also stored remotely in the cloud is evicted, its data is removed from local storage, rendering it dataless, as shown below.

When that file is to be used locally again, its data has to be downloaded from the cloud service, and the local dataless file is materialised by adding its data back. As far as I can tell, that doesn’t result in the reconstruction of the shared file extents, so changes cloned files into normal copies with different file extents. You would then need to use Hyperspace to restore them as clone files. Other Macs sharing the same iCloud Drive also see them as full copies rather than clones.

These behaviours could also catch the user by surprise.

Sparse files

Unlike clone files, the structure of sparse files in APFS is conventional, as shown below.

They achieve their economy in storage by only including file extents containing non-null data, and thus aren’t dependent on remaining within the same file system (volume), making them more robust. Their primary requirement is that they’re created and maintained using specific file system operations, and are only copied or moved to other APFS file systems.

Backups

When backed up by Time Machine to another APFS volume, sparse files are preserved reliably, and are also restored as sparse files. That isn’t likely to hold, though, if the file is transferred using a network file system such as SMB, as all network transfers currently appear to explode sparse files to full size prior to transfer. Because of the way in which they have to be created, only the app maintaining that file could restore its sparse format. In the case of disk images, this should normally occur the next time they’re mounted in the Finder and Trimmed by APFS.

iCloud Drive

Assessing what happens with sparse files in iCloud Drive is considerably simpler than with clone files. As long as they remain downloaded to local storage, they are preserved, and can be moved in and out of iCloud Drive storage without exploding in size. However, they too are stored in full when in iCloud storage, requiring their full size in your iCloud allocation, and the eviction-materialisation cycle explodes them to full size, and their sparse file flag is removed.

The only way to return a former sparse file to its original economical format is then to open and save it using the app that creates and maintains it. In the case of disk images, this should occur when they’re next mounted and Trimmed.

Conclusions

Clone files:

• are only preserved when moved within the same file system (volume);
• are preserved and restored from local snapshots;
• are preserved in Time Machine backups, but aren’t restored from them;
• aren’t preserved in other backups;
• could result in a restored volume being substantially larger than its original;
• occupy their full space in your iCloud allocation;
• are only preserved in iCloud Drive when they aren’t evicted from local storage;
• can be regenerated using Hyperspace.

Sparse files:

• are only preserved when copied or moved directly between APFS volumes;
• aren’t preserved when copied or moved over network connections, or using SMB;
• aren’t preserved when copied or moved to different file systems, including HFS+;
• are preserved in and restored from local Time Machine backups;
• should be preserved in and restored from other local backups;
• occupy their full space in your iCloud allocation;
• are only preserved in iCloud Drive when they aren’t evicted from local storage;
• can only be regenerated by the app that creates and maintains them.

Both clone and sparse files can result in substantial savings in storage space. However, because that’s fragile, their greatest value is in minimising erase-write cycles in SSDs, hence slowing their ageing.

References

Apple’s APFS Reference (PDF), last revised 22 June 2020.
Dataless files are explained here.
How sparse files work
Files and clones
Special file types, including dataless files