Auto-Remediating macOS Time Machine Backup Silent Failures

#The Old Way vs the New Way

The old way of handling Time Machine on a managed Mac fleet involves waiting for a laptop to die, a drive to fail, or a user to accidentally delete a folder before anyone discovers that backups

The new way treats backup health as a fleet telemetry signal, not a support ticket trigger. A scheduled local script checks tmutil status daily, reports the last successful backup timestamp as an inventory extension attribute, and a proactive remediation policy in Jamf Pro (or a remediation script in Intune) re-triggers backups, clears stuck destinations, and alerts a human only when a device has gone dark for a defined threshold. Nobody notices this working. That is the point.

#Why This Matters at Scale

Time Machine failures are quiet. Unlike a printer jam or an MFA lockout, a broken backup produces zero symptoms until the exact moment a user needs a restore. On a fleet of a few thousand Macs, industry-observed patterns show a meaningful percentage of devices silently stop backing up within any given quarter, usually due to APFS snapshot thinning issues, a full or disconnected network destination, a stale keychain credential for a network share, or a machine that has simply been asleep every night the backup was scheduled to run. None of this generates a ticket. It generates a data-loss incident weeks later, which is a far more expensive support event than the five-minute fix would have been.

#Prerequisites and Permissions

• Jamf Pro 10.44 or later (or Microsoft Intune with a shell script proactive remediation configured for macOS), with an existing scripted extension attribute capability.
• Devices supervised via Apple Business Manager and enrolled through Automated Device Enrolment, so configuration profiles and scripts can be pushed without user interaction.
• A Full Disk Access, Privacy Preferences Policy Control (PPPC) profile scoped to /usr/bin/tmutil and your deployment tool’s script execution binary, since tmutil queries require Full Disk Access on modern macOS to return complete data.
• Jamf Pro role or Intune role with permission to create Extension Attributes or custom compliance scripts, deploy Scripts/Policies (Jamf) or Remediation Scripts (Intune), and edit Smart Groups or Device Groups.
• A destination that supports scripted health checks: Time Machine to APFS-formatted local disk, Time Capsule, or a network share (SMB) with backupd support.
• Read access to the Apple Deployment Reference for MDM profiles and the Apple Device Management documentation for PPPC payload structure.

#Implementation Steps

#

Step 1: Build the backup health extension attribute script

Action: create a script that queries tmutil latestbackup and tmutil status, calculates days since the last successful backup, and outputs a single integer for inventory reporting.

1#!/bin/bash
2# tm_health_check.sh
3# Reports days since last successful Time Machine backup as an EA value.
4
5LATEST_BACKUP=$(tmutil latestbackup 2>/dev/null)
6
7if [ -z "$LATEST_BACKUP" ]; then
8  echo "<result>9999</result>"
9  exit 0
10fi
11
12BACKUP_EPOCH=$(date -j -f "%Y-%m-%d-%H%M%S" "$(basename "$LATEST_BACKUP")" "+%s" 2>/dev/null)
13NOW_EPOCH=$(date "+%s")
14
15if [ -z "$BACKUP_EPOCH" ]; then
16  echo "<result>9999</result>"
17  exit 0
18fi
19
20DAYS_SINCE=$(( (NOW_EPOCH - BACKUP_EPOCH) / 86400 ))
21
22echo "<result>${DAYS_SINCE}</result>"
23exit 0

Expected result: the script returns an XML-style result tag with an integer representing days since the last backup. A healthy machine returns a low number such as 0 or 1. A machine with no backup history returns 9999.

Evidence to capture: run the script locally with sudo bash tm_health_check.sh on a test Mac and confirm the output matches tmutil latestbackup run independently.

1sudo bash tm_health_check.sh
2# Expected output example:
3# <result>1</result>

#

Step 2: Deploy the PPPC profile granting Full Disk Access

Action: push a configuration profile granting Full Disk Access to the deployment tool’s script runner (Jamf Pro’s binary or Intune’s management agent) so tmutil returns full data rather than a permission-denied empty response.

1<?xml version="1.0" encoding="UTF-8"?>
2<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
3<plist version="1.0">
4<dict>
5  <key>PayloadType</key>
6  <string>com.apple.TCC.configuration-profile-policy</string>
7  <key>PayloadIdentifier</key>
8  <string>com.kbytech.pppc.tmutil.fda</string>
9  <key>PayloadUUID</key>
10  <string>9c2e4d10-2b6a-4a3f-9b1a-0f8a7c6d5e44</string>
11  <key>PayloadVersion</key>
12  <integer>1</integer>
13  <key>Services</key>
14  <dict>
15    <key>SystemPolicyAllFiles</key>
16    <array>
17      <dict>
18        <key>Identifier</key>
19        <string>com.jamfsoftware.jamf</string>
20        <key>IdentifierType</key>
21        <string>bundleID</string>
22        <key>CodeRequirement</key>
23        <string>anchor apple generic and identifier "com.jamfsoftware.jamf"</string>
24        <key>Allowed</key>
25        <true/>
26      </dict>
27    </array>
28  </dict>
29</dict>
30</plist>

Expected result: the profile installs silently on supervised devices with no user prompt, because PPPC payloads bypass the TCC consent dialog only when deployed via MDM to a supervised Mac.

Evidence to capture: on a test device, open System Settings > Privacy & Security > Full Disk Access and confirm the deployment agent is listed and enabled without manual toggling.

#

Step 3: Create the Extension Attribute in Jamf Pro

Action: in Jamf Pro, navigate to Settings > Computer Management > Extension Attributes, create a new attribute named TimeMachine_DaysSinceBackup, set the input type to Script, and paste the script from Step 1.

Expected result: after the next inventory update (recon), every enrolled Mac reports a numeric value visible under the device’s Extension Attributes tab.

Evidence to capture: pull an Advanced Computer Search filtered on this attribute and confirm a spread of values across the fleet rather than every device returning zero, which would indicate the script is not actually executing.

#

Step 4: Build the Smart Group for at-risk devices

Action: create a Smart Group with the criterion TimeMachine_DaysSinceBackup greater than 7, scoped to all managed laptops.

1{
2  "smart_group": {
3    "name": "TimeMachine - Backup Overdue (7+ Days)",
4    "criteria": [
5      {
6        "name": "TimeMachine_DaysSinceBackup",
7        "priority": 0,
8        "and_or": "and",
9        "search_type": "greater than",
10        "value": "7"
11      },
12      {
13        "name": "Operating System Build",
14        "priority": 1,
15        "and_or": "and",
16        "search_type": "like",
17        "value": ""
18      }
19    ]
20  }
21}

Expected result: the Smart Group populates dynamically as devices cross the 7-day threshold and clears members automatically once a successful backup is detected on the next inventory cycle.

Evidence to capture: screenshot the Smart Group membership count before and after deploying the remediation policy in Step 5.

#

Step 5: Deploy the remediation policy

Action: create a Jamf Pro Policy scoped to the Smart Group from Step 4, triggered on a recurring check-in (every 60 minutes or daily), that runs a remediation script attempting to nudge Time Machine and clear common stuck states.

1#!/bin/bash
2# tm_remediate.sh
3# Attempts to clear common Time Machine stall conditions and force a backup.
4
5STATUS=$(tmutil status)
6
7if echo "$STATUS" | grep -q '"Running" = 1'; then
8  echo "Backup already running, no action taken."
9  exit 0
10fi
11
12# Clear a stale lock if backupd reports a stuck destination
13DEST_INFO=$(tmutil destinationinfo 2>/dev/null)
14
15if [ -z "$DEST_INFO" ]; then
16  echo "No destination configured, escalating."
17  exit 1
18fi
19
20# Kick off an immediate backup attempt
21tmutil startbackup --auto
22
23sleep 30
24
25STATUS_AFTER=$(tmutil status)
26echo "Post-remediation status: $STATUS_AFTER"
27exit 0

Expected result: devices with a valid but idle destination begin backing up within the next scheduled window. Devices with no destination configured or a disconnected network share exit with status 1, which is the escalation signal.

Evidence to capture: policy log in Jamf Pro showing exit code 0 for remediated devices and exit code 1 for devices requiring human follow-up; cross-reference against the Smart Group membership drop 24 hours later.

#

Step 6: Intune equivalent using Proactive Remediation

Action: for Intune-managed fleets, create a Device Compliance Script pair (detection + remediation) under Reports > Endpoint analytics > Proactive remediations.

1#!/bin/bash
2# detect_tm_backup.sh
3LATEST_BACKUP=$(tmutil latestbackup 2>/dev/null)
4if [ -z "$LATEST_BACKUP" ]; then
5  echo "No backup found"
6  exit 1
7fi
8BACKUP_EPOCH=$(date -j -f "%Y-%m-%d-%H%M%S" "$(basename "$LATEST_BACKUP")" "+%s")
9NOW_EPOCH=$(date "+%s")
10DAYS_SINCE=$(( (NOW_EPOCH - BACKUP_EPOCH) / 86400 ))
11if [ "$DAYS_SINCE" -gt 7 ]; then
12  echo "Backup overdue: ${DAYS_SINCE} days"
13  exit 1
14fi
15echo "Backup healthy: ${DAYS_SINCE} days"
16exit 0

Expected result: detection script exit code 1 triggers the paired remediation script (identical logic to Step 5) automatically on the defined schedule, with no manual policy scoping required beyond the target device group assignment.

Evidence to capture: Intune’s Proactive remediations dashboard reporting detection/remediation success rates per device, exportable as a CSV for the deflection metric in the final section.

#Verification and Expected Evidence

1. Confirm the Extension Attribute (Jamf) or detection script (Intune) returns accurate values by comparing against a manually run tmutil latestbackup on three sample devices of different backup destination types (local disk, network share, no destination configured).
2. Confirm the PPPC profile is applied fleet-wide by querying Jamf Pro’s API for devices missing the profile.
3. Confirm the Smart Group or dynamic group correctly adds and removes devices as their backup state changes over a 48-hour observation window.
4. Confirm the remediation script’s exit codes are logged and searchable, so escalations can be filtered without manually reading every log.

1/usr/local/jamf/bin/jamf policy -id 145 -verbose
2# Expected output excerpt:
3# Script exit code: 0
4# Post-remediation status: { Running = 1; Percent = 0.02; }

#Rollback

If the remediation script causes unexpected battery drain, disk thrashing, or interferes with a user’s active work session on laptops running from battery, disable the Jamf Policy or Intune remediation assignment immediately, which halts new executions without needing to reverse anything already run since tmutil startbackup is a non-destructive, idempotent request. Remove the PPPC profile only if a documented conflict with another security tool’s Full Disk Access grant is confirmed; removing it will cause the Extension Attribute script to silently degrade to empty output rather than fail outright, so monitor for a spike in 9999 values as the rollback signal that FDA was actually required.

#Failure and Escalation Conditions

• A device returns exit code 1 from the remediation script three consecutive scheduled runs, indicating the destination is genuinely unreachable, not just temporarily busy: escalate to L2 for manual destination verification.
• More than 5 percent of the fleet Smart Group population fails to clear after 72 hours post-remediation: escalate to L3 to check for a shared network destination outage or a certificate/authentication failure on the SMB share.
• Any device reporting 9999 for more than 14 days after initial enrolment, indicating Time Machine has never successfully run: this is the exact condition that should wake a human technician, since it likely means no backup destination was ever configured for that user.
• PPPC profile fails to install on any device: escalate immediately, since all downstream reporting depends on Full Disk Access being granted.

#Minimum Role, Blast Radius, and Monitoring Signal

Minimum required role is a Jamf Pro custom role with Extension Attribute create/edit, Policy create/edit, and Smart Group create/edit permissions, or the Intune equivalent of Endpoint analytics contributor. Test scope should begin with a pilot Smart Group of no more than 25 devices from a single department before fleet-wide scoping. Blast radius is limited strictly to backup-triggering commands; no destructive file operations occur in either script. Monitoring signal is the Smart Group membership trend line in Jamf Pro or the Proactive remediation success rate in Intune, both of which should trend toward zero non-compliant devices within one week of deployment.

#Measuring Ticket Deflection

Baseline the current volume of restore-related and backup-related tickets over the prior quarter before deployment. After rollout, track three numbers monthly: the count of devices ever reaching the 9999 unhealthy state, the average days-since-backup fleet-wide, and the count of manual restore-failure tickets logged where the root cause was cited as “no recent backup available”. A successful deployment should show the third number trending toward zero within two months, since the entire purpose of this automation is to guarantee a recent, valid backup exists before a user ever needs to ask for one.