Burning to Blu-ray

When you want to make more permanent archives of documents and other files from your Mac, the most obvious choice of medium is Blu-ray. Depending on the drive and disk, you can store 25-100 GB on each disk, and there are variants like M-Disc which claim to be of ‘archival’ quality (however sceptical we should be of all such claims). A good BD-R burner should cost between $/€/£ 80-200, so for a modest outlay you can start archiving your documents.

Unfortunately, it’s also quick and easy to end up with archives which aren’t faithful copies of the originals. This article explains some of the problems, and how you can work around them.

Unlike copying files between regular volumes, optical disks use their own file systems, with the option of adding support for some special features from others. In practice this means that some of the information you expect to be associated with documents will be omitted when burning them to a BD-R disk. Don’t be deceived by options which look as if they’ll avoid such problems: setting your BD-R disk to be ‘Mac only’, for example, promises that some of the additional information held in HFS+ and APFS is saved to that disk, but some of it still isn’t.

This applies most significantly to extended attributes, which are becoming increasingly important and better-supported by iCloud, for example. One of the problems that I’ve identified with my new app Dintch, which checks the integrity of files, is that its custom extended attribute is one of many which isn’t written to BD-R disks even when you opt for them to be in ‘Mac only’ format.

Burning with the ‘Mac only’ option preserves a few more extended attributes than the standard ‘Mac and PC’. But all the most useful and important, particularly non-Apple custom, extended attributes are stripped in the process of burning files to a disk.

The best way to preserve those, and other file metadata, is to put those files into a disk image, and burn that to BD-R. Although you can create one huge disk image of, say, 25 GB size, if that becomes damaged or corrupted, none of files within it is likely to be recoverable. It makes better sense to burn several smaller disk images to make up each BD-R archive.

Build

Start by sorting the files you want to archive into several different folders, which total slightly less than the capacity of the BD-R disk you’ll be using. If you’re going to tag them using Dintch, now’s the time to do that, immediately before converting each of those higher-level folders into a disk image.

Creating disk images from those files is simple. To make life simpler in Mojave or Catalina, add Disk Utility (in /Applications/Utilities) to the Full Disk Access list in the Privacy tab of the Security & Privacy pane first. If you don’t do that, you may find that some attempts to create disk images fail with an error code of 1.

Then open Disk Utility, select the Image from Folder subcommand of the New Image command in the File menu. Pick the folder you want to turn into a disk image, then set its options. If the contents are sensitive, you can elect for it to be encrypted, but whatever you do, I recommend that you make each disk image read-only.

bdrstorage01

Burn

You can then burn those disk images to your BD-R disk using the Finder’s support, or with an app like Toast Burn from the App Store which provides all the options that you could get from the command tool hdiutil.

bdrstorage02

bdrstorage03

bdrstorage04

bdrstorage05

Either way, on completion of burning your disk, it will be verified automatically.

Access

Accessing your archived files on the disk is straightforward too. Once it has mounted, double-click on the disk image you want to open. By default, the Finder will verify the disk image before mounting it. If you’ve already tagged all the files it contains using Dintch, you can skip that step, which should save significant time. Running Dintch’s check on the contents of the disk image, or folders within it, is significantly slower than checking on media such as an SSD or even hard disk: on my test image of just under 20 GB, it took around 25 minutes. That’s another good reason to opt for a number of smaller disk images.

When stored in a disk image, all but the most ephemeral of extended attributes and other metadata are retained. When you copy a file from your archive, you can not only use it completely normally, but Dintch can verify that it remains just as you stored it.