Sparse bundles seem increasingly popular in macOS: they’re widely used when you want to host a volume using a file system such as HFS+, particularly for Time Machine and other backups, or APFS, on a different file system, such as that on networked storage (NAS). They’re also a neat way to protect files containing sensitive data without having to encrypt an entire volume on a disk using FileVault.

In a sparse bundle, the data for your virtual volume is stored in a number of files termed bands. These enable efficient storage, as their number can rise and fall as the quantity of data stored increases and decreases. When you create a sparse bundle, there are two size settings you specify: the maximum size that the bundle’s virtual volume can reach, and the maximum size for each of its bands. Getting those right isn’t essential, as both can be changed later if you wish, but it’s good to be able to set and forget them.

Maximum sparse bundle size

The maximum size for the whole sparse bundle is the size of its virtual volume. As I’ve shown previously, it’s best to set this fairly close to the largest capacity you need in the virtual volume, as that keeps the size of the sparse bundle itself to a minimum. For a bundle containing backups, though, you know that it’s likely to continue increasing in size, and it’s often simplest to start off with its maximum size set to the largest that you want it to grow to during the life of that backup set.

For a collection of encrypted documents, you should therefore aim to make the sparse bundle size close to the total size of those documents, allowing some room for future expansion. For a backup set, you’ll probably want to set the size to the maximum those backups will reach before you archive them, which is much larger than that required for the first complete backup.

Don’t forget, though, that you can always increase the maximum size when necessary, using my free tool Spundle or hdiutil in Terminal.

Band size

The band size is the maximum size of each band file, and determines two things: the number of band files, and how efficiently the whole sparse bundle can change in size. In most cases, the default is 8.4 MB, which generally works well for all but large backups.

There’s one important limit to bear in mind when setting band size. All the bands of a sparse bundle are stored inside a single folder. If the number of bands reaches the maximum for a single folder for the host file system, then it will start to fail, and you could lose part or all of its contents. Currently, in macOS with HFS+ or APFS, that critical number is believed to be 100,000. So whatever you do, ensure that your sparse bundle will never need 100,000 or more band files, which could spell disaster.

The simplest way to approach this is with a critical band size. Calculate that by dividing the absolute maximum size that your sparse bundle might reach (even after resizing) by a number smaller than 100,000, such as 50,000. It’s best to do this in consistent units such as MB: if your sparse bundle could reach 1.1 TB, that’s 1,100 GB, or 1,100,000 MB. Divide that by 50,000 and you should get a critical band size of 22 MB. That’s the smallest band size which will keep the total number of bands below 50,000.

You can then choose any band size from the critical upwards. The smaller you make the bands, the more efficient the sparse bundle’s use of storage space will be, as it can add (or remove) bands to accommodate changes in size. For a 1.1 TB maximum size sparse bundle, you could therefore choose a band size of perhaps between 22-200 MB, as giving a good compromise without approaching the maximum number of bands in a single folder.

You can change band size later if you need. As this involves writing out a whole new sparse bundle and copying the contents across from the old one, you’ll need sufficient free space on a disk to be able to do this. The good news is that in the process of making the new sparse bundle, its contents are thoroughly cleaned up and compacted better than the separate compact command can achieve.

Finally, when entering sizes in Spundle, I recommend that you use integer values appropriate to the unit. Specify 1.1 TB as 1100 GB, and 25 MB as that rather than 0.025 GB. Not only will Spundle round some, but it’s far less confusing and less prone to error.

Happy sparse bundling!