Time Machine backups of APFS volumes

On the face of it, Time Machine has changed little in Mojave from that in Sierra, or even before. Each hour, it seems to look in the database of file system events (FSEvents) for those files which have changed since the last backup, on each volume which it is configured to back up, and writes a new backup to the store using hard links to represent unchanged files and folders.

This article explores how Time Machine has actually changed considerably since the days of Sierra and the HFS+ file system. Now that APFS is the default file system for macOS, even though you still can’t use it to store your backups, Time Machine is starting to get the best out of it. These changes were initially introduced in High Sierra, but being limited to APFS volumes are only now becoming generally used.

tmmojavelog01

The start of the backup is announced as it always has been, making clear that it is a timed backup, and giving the destination.
37:13.324510+0100 Starting automatic backup 37:13.944141+0100 Backing up to /dev/disk3s2: /Volumes/PROMISE PEGASUS/Backups.backupdb

Time Machine then tries to remove a group of attributes from the path file:///, which is recorded as a succession of errors. I don’t think that these are significant, even though the log entries are given Error status.

Then follows a new section, which has been introduced with the snapshots feature in APFS. Not only is this backup going to copy files to the backup store, but it’s also going to make a local snapshot of the file system metadata. Before doing that, existing snapshots undergo housekeeping.
37:15.303692+0100 Starting age based thinning of Time Machine local snapshots on disk '/' 37:15.306357+0100 Age based thinning deleted Time Machine snapshot 'com.apple.TimeMachine.2018-10-12-074443' on disk '/ 37:20.814376+0100 Created Time Machine local snapshot with name 'com.apple.TimeMachine.2018-10-12-093715' on disk '/' 37:20.821185+0100 Declared stable snapshot: com.apple.TimeMachine.2018-10-12-093715 37:21.222744+0100 Mounted stable snapshot: com.apple.TimeMachine.2018-10-12-093715 at path: /Volumes/com.apple.TimeMachine.localsnapshots/Backups.backupdb/Howard’s iMac/2018-10-12-093715/Macintosh HD source: Macintosh HD 37:21.823102+0100 Mounted reference snapshot: com.apple.TimeMachine.2018-10-12-083723 at path: /Volumes/com.apple.TimeMachine.localsnapshots/Backups.backupdb/Howard’s iMac/2018-10-12-083723/Macintosh HD source: Macintosh HD
This has taken a new snapshot on the root volume, checked and mounted it, then mounted the previous snapshot (taken an hour ago) to use as a reference. It appears that, when macOS has both a current ‘stable’ and reference snapshots available, Time Machine compares those in order to determine which files to back up, rather than relying on FSEvents, as it had to when working with HFS+.

tmmojavelog02

Log entries by the backupd service making the normal backup then establish the quantity and number of files to be backed up, check the storage space available, and copy those files into the backup. The fact that this occurs over 20 seconds (here) after the production and mounting of stable and reference snapshots strongly supports their use to determine which files and folders need to be backed up, instead of using FSEvents.
37:44.916779+0100 Will copy (637.5 MB) from Macintosh HD 37:44.917419+0100 Found 1447 files (637.5 MB) needing backup 37:44.953124+0100 7.97 GB required (including padding), 4.49 TB available 41:12.017287+0100 Copied 1593 items (623.3 MB) from volume Macintosh HD. Linked 19601.
I’m not sure of the significance of the ‘move optimization’ error reported here; this may be a feature which tries to avoid making new backups of files which have simply been moved within the folder structure.

What follows next is new for APFS: a clone database file is saved in the backup folder which has just been made. Then a ‘back-up-later cache’ is saved in the same backup folder, presumably listing files which need to be backed up next time, perhaps because they were in use this time.
41:12.037146+0100 Saved clone family cache for 'Macintosh HD' at /Volumes/PROMISE PEGASUS/Backups.backupdb/Howard’s iMac/2018-10-12-093721.inProgress/14F6D6F4-4BCA-4EA1-B4F5-67A5B9623254/.BE50387F-1302-31FB-B567-68F50F8ADE7A.clonedb 41:12.688615+0100 Saved back-up-later cache at /Volumes/PROMISE PEGASUS/Backups.backupdb/Howard’s iMac/2018-10-12-093721.inProgress/14F6D6F4-4BCA-4EA1-B4F5-67A5B9623254/.reservations.plist 41:14.014047+0100 Saved back-up-later cache at /Volumes/PROMISE PEGASUS/Backups.backupdb/Howard’s iMac/2018-10-12-093721.inProgress/14F6D6F4-4BCA-4EA1-B4F5-67A5B9623254/.reservations.plist 41:14.259024+0100 Unmounted local snapshot: com.apple.TimeMachine.2018-10-12-093715 at path: /Volumes/com.apple.TimeMachine.localsnapshots/Backups.backupdb/Howard’s iMac/2018-10-12-093715/Macintosh HD source: Macintosh HD 41:14.507748+0100 Unmounted local snapshot: com.apple.TimeMachine.2018-10-12-083723 at path: /Volumes/com.apple.TimeMachine.localsnapshots/Backups.backupdb/Howard’s iMac/2018-10-12-083723/Macintosh HD source: Macintosh HD 41:15.039030+0100 Marked as reference snapshot: com.apple.TimeMachine.2018-10-12-093715 41:15.161260+0100 Completed snapshot: 2018-10-12-094114
The two local snapshots are then unmounted, the later being marked as the next reference snapshot, and their use is complete.

Log entries revert to the traditional to trace post-backup thinning, the removal of expired backups from the normal backup folder. This time, one complete backup can be removed.
41:16.127934+0100 Starting post-backup thinning 42:01.489936+0100 Deleted /Volumes/PROMISE PEGASUS/Backups.backupdb/Howard’s iMac/2018-10-11-090416 (12.2 MB) 42:01.489947+0100 Post-backup thinning complete: 1 expired backups removed 42:01.580128+0100 Backup completed successfully.
Finally, successful completion is reported.

Although T2M2 doesn’t provide this level of detail, this is simple to obtain using the default settings in Consolation 3, which are designed to make it easier to browse the Time Machine entries in the unified log.

Before the advent of APFS, making ‘Mobile Time Machine’ backups (the equivalent of local snapshots in APFS) was a slow and complex process, and wasn’t incorporated into the hourly automatic backup. APFS makes local snapshots very simple and quick, and it is excellent that these are now part of the hourly backup cycle. They also provide a quicker and more reliable way for Time Machine to determine what it needs to back up. Apple has described it briefly in this recent Support Note, but doesn’t give any technical detail.

2Comments

Add yours

1

gctwnl on October 15, 2018 at 10:16 am

The local snapshots have a drawback, though. If your disk is running full it is hard to quickly make room as the data is being kept in use by the local snapshot. TM even does that if the TM target disk is internal (which enables a continuous backup process). A combination of a disk with limited free space, a badly behaving program (CrashPlan) dumping 12GB cores regularly, actually conspired to give a me a disk full crash, which damaged some postgres databases which weeks later crashed the system again because of a runaway service start and a full process table. The idea of local snapshots on AFS is nice, but it is not a free lunch and it is also not without risk. Users should be able to turn this local snapshotting off as backing up to the same volume that you are backing up to remains always a risk, even with the smart deduplication by APFS.

LikeLike
- 2
  
  hoakley on October 15, 2018 at 10:40 am
  
  Thanks. I’m sorry that you had that crash.
  If the snapshots were only being used as an addition to TM backups, I could see sense in that. However, as they are now used to determine what to back up, and are stored in the backups folder, that would mean supporting two quite different forms of TM backup on APFS. They are a bit more than “nice” now – for APFS volumes they are an essential part of the backup process. Given the problems of FSEvents, I think that is a valuable improvement.
  It is bad that Apple doesn’t appear to have detailed any of this anywhere, even in its developer documentation.
  The other point is that APFS volumes, like HFS+ before them, must never be allowed to get too full. At least with APFS, so long as there is free space on the disk, that shouldn’t be an issue with their dynamic resizing of volumes.
  Howard.
  
  LikeLike

Share this:

Like this:

Related