There are several behavior patterns that inevitably boil down to a problem with a hardware component between your Mac and the storage. Any time you see random errors, stalls, crashes, the destination volume "disappearing" in the middle of a backup task, reports from the Finder that a disk was ejected improperly, Finder lockups and other unruly behavior, we have to turn to old-fashioned troubleshooting to rule out the problematic component. Everything is on the table – USB ports, cables, plugs, adapters, hubs, hard drive enclosures, storage devices – a problem with any of these components can lead to mayhem.
Many times that hardware problems occur, CCC will get meaningful errors from the filesystem that plainly indicate some sort of hardware problem, and CCC will report these at the end of the backup task. In some cases, however, macOS or CCC will detect a hung filesystem and you will see one of the following messages from CCC:
"The task was aborted because the [source or destination] disappeared."
If you see this message, macOS's kernel recognized that the affected filesystem was not responding and terminated it. While this is obviously an abrupt end to your backup task, it beats the alternative macOS behavior described next.
"The task was aborted because the [source or destination] filesystem is not responding."
CCC will present this message when the source or destination volume hasn't accepted read or write activity in at least ten minutes, and a deliberate followup test verifies that a simple read or write request fails. In these cases, macOS's kernel has failed to take action on the misbehaving filesystem and you can expect to see stalls in any application that attempts to read from or write to the affected volume. To break the stall, the affected disk must be forcibly detached from your Mac or you must reboot by holding down the power button if the disk is internal.
In other cases, you'll see a report from the Finder:
Disk Not Ejected Properly
"Eject 'Your Backup Disk' before disconnecting or turning it off."
Even if this event occurred when a CCC task was running, please note that CCC can never be responsible for a device's apparent detachment from the system – CCC never interacts with hardware at that level. CCC is simply copying files from one volume to another. If simple file copying leads to volume disappearance, the most common explanation is that a communication failure occurred due to a crash of the storage device's firmware, or due to the (typically transient) failure of a component between the Mac and the storage (most often it's a USB hub or adapter). These events also may coincide with sleep/wake cycles, e.g. if a device does not handle the power state transition well. Many times these messages will be perplexing because the storage device reboots and then immediately reappears, possibly before you see the message from the Finder. Other times the device may not reappear until it is physically detached and reconnected to your Mac.
When you see these messages – there is a hardware problem or a negative hardware:macOS interaction afoot. We cannot solve these problems with a change to CCC, but the steps below can help you identify the problematic component.
macOS Monterey ejects the source snapshot on logout
In nearly every case where a task is aborted due to the source or destination disappearing, it's the result of a hardware issue. We have found one exception to this though. When you log out of a macOS Monterey system while a backup task is running, macOS will errantly unmount the source volume snapshot, and will do so despite CCC's dissent of the volume unmount request. This behavior did not occur on macOS Big Sur, and appears to be resolved for macOS Ventura. Note that this only affects a task that is running during a logout event. Tasks run fine when they are started when no user is logged in.
Workaround: On Monterey, avoid logging out while a backup task is running. Go to System Preferences > Security & Privacy > {click the padlock and authenticate} > {click Advanced...} and verify that you do not have the system configured to log you out after a period of inactivity if that may overlap with a scheduled backup of the startup disk.
Solution: Upgrade to macOS Ventura.
Troubleshooting steps
When CCC suggests that you might have a hardware problem, here are the steps that we recommend you take to isolate the problem. Repeat the backup task between each step, and stop if something has resolved the problem:
- If the affected volume resides on an external hard drive, detach that disk from your Mac, then reattach it. Otherwise, restart your Mac before proceeding. Note that this generally only resolves the acute problem of a filesystem stalling. While the disk may appear to function fine once it is reattached, it's not unlikely for problems to recur.
- Run Disk Utility's First Aid tool on the source and destination volumes. Note that Disk Utility's First Aid will rarely fix filesystem corruption. If filesystem corruption is detected, we recommend that you erase the volume to resolve the corruption.
- If you have any other hardware devices attached to your Mac (e.g. USB webcams, printers, iPhones — anything other than a display, keyboard, mouse, and the source/destination disks), detach them.
- If your source or destination volume is plugged into a USB hub, keyboard, or display, reconnect it to one of your Mac's built-in ports. USB hubs are the most common cause of "disk not ejected properly" errors.
- Replace the cable that you're using to connect the external hard drive enclosure to your Mac (if applicable). Do not use an adapter to connect the device to your Mac, use a cable that has the correct plugs on each end for the device and your Mac. USB adapters are another common cause of "disk not ejected properly" errors.
- If you have any third-party storage drivers, uninstall them. Especially since macOS Catalina, we have seen numerous reports of problems caused by third-party storage drivers.
- Try connecting the external hard drive enclosure to your Mac via a different interface (if applicable)
- Try the same hard drive in a different external hard drive enclosure (we offer some recommendations here).
- Reformat the hard drive in Disk Utility.
- If none of the previous steps has resolved the problem, then the hard drive is failing or defective. Replace the hard drive.
"Why does CCC eject the destination?" or "Why is CCC making my whole computer stall?"
We hear this one a lot, and we generally reply, "don't shoot the messenger." In most cases, CCC is either the only application copying files to the affected volume, or it is at least the application doing most of the access, so it only seems like the problem is specific to CCC. A typical backup task will make millions of filesystem requests, so it comes as no surprise to us when CCC uncovers hardware problems in a disk. CCC is merely copying files from one disk to another, and this is not the kind of task that should cause a system-wide stall. Whenever multiple applications are stalling while trying to access a volume, the fault lies entirely within the macOS kernel, which is mishandling hardware that is either failing or defective. If you're uncertain of this assessment, please send us a report from CCC's Help window. When CCC detects a stalled filesystem, it collects diagnostic information to determine where the stall is occurring. We're happy to review the diagnostics and confirm or deny the presence of a hardware problem.
"But Disk Utility says that there is nothing wrong with the disk…"
Disk Utility is competent at detecting structural problems with the filesystem, but it can't necessarily detect hardware failures that can cause a filesystem to stop responding to read and write requests. Additionally, even if your disk is SMART capable and "Verified", the attributes that SMART status reports on are weighted, and may not yet indicate that the hardware is in a pre-fail condition. Disk Utility does not scan for bad sectors, it only checks the health of the filesystem. Bad sectors will not be reported by Disk Utility. Don't take a "Verified" status to indicate that your disk has no hardware problems whatsoever.
"But Disk Warrior/Tech Tool/[other third-party utility] says the hardware is fine, I'm sure the hardware is fine!"
There are no hardware diagnostic utilities on the market that will inform you of a problem with a cable, port, or enclosure, or report a bug in the firmware of a hard drive or SSD. The tools currently available on the Mac platform will inform you of software-based filesystem problems, media failure, and the results of SMART diagnostics which are specific to the hard drive device inside of an enclosure. While these tools are great at identifying the problems within that scope, the inability to detect problems with a cable, port, or enclosure, or a firmware bug on a hard drive, leaves a gaping hole that can only be filled with old-fashioned troubleshooting — isolate components, rule out variables, run multiple tests.
Other factors that can lead to stalls
Hardware is often the culprit when a backup task stalls, but sometimes other software can interfere with a backup task and even cause the whole system to stall. If you are using an external hard drive enclosure that came with custom software, try disabling or uninstalling that software before trying your next backup task. Otherwise, reboot your Mac while holding down the Shift key to boot into Safe Boot mode. Third-party software is disabled in Safe Boot mode, so if the backup task runs successfully in Safe Boot, there is likely a third-party application causing some interference.
Related
- Uninstalling Seagate diagnostic utilities alleviates hangs
- Some third-party storage drivers may cause hardware misbehavior
- We have received several reports that ProSoft's Drive Pulse software can cause the backup task to stall. Disabling scanning of the CCC destination volume should effectively resolve the problem, however we have received one report in which that was not effective. Uninstalling Drive Pulse did resolve the stall in that case.
Additionally, some hard drive enclosures respond poorly to sleep/wake events. If the problems that you are encountering tend to occur only after your system has slept and woken, you should try a different hard drive enclosure or interface to rule out enclosure-specific sleep problems.
Troubleshooting Media errors
Read errors are typically a result of media damage — some of the sectors on the hard drive have failed and macOS can no longer read data from them. Read errors can occur on the source or destination volume, and they can affect old disks as well as brand-new disks – even SSDs and NVMe storage. When read errors occur, the file or files that are using the bad sector must be deleted. Bad sectors are spared out — permanently marked as unusable — only when the files on those sectors are deleted.
If CCC has reported dozens or hundreds of files that are unreadable due to media errors, we recommend replacing the affected hard drive because it is likely failing. Small numbers of unreadable files, however, are not necessarily an indication that a hard drive is failing. The steps below indicate how to resolve media errors.
- Click on the affected item in the Task History window, then click on the Reveal in Finder button.
- Move the affected files and/or folders to the Trash.
- Empty the Trash.
- If you had to delete items from your source volume, locate those items on your backup volume and copy them back to the source (if desired).†
- If CCC reported problems with more than a few files or folders, we strongly recommend that you reformat the affected disk in Disk Utility.
† If you're looking for an item that is hidden in the Finder, press Command+Shift+Period to toggle the Finder's display of hidden items.
Once you have deleted the affected files, you should be able to re-run your backup task with success.
Note: If you do not have a backup of the affected files, please scroll to the top of this document and exhaust the hardware-based troubleshooting techniques first. As indicated above, read errors are typically a result of media damage. In some rare cases, though, media errors can be errantly reported when a hardware-based problem exists (e.g. a bad port, cable, or enclosure). If deleting your only copy of a file is the suggested resolution, then it's prudent to rule out everything else as the cause of an issue before deleting that file.
Errors on read or write that are caused by physical drive malfunction
If your source or destination hard drive is experiencing a significant physical malfunction (errors that go beyond "input/output" read errors described above), you may have a narrow window of opportunity to back up the data from that disk to another hard drive. Time is precious; components could fail at any moment rendering the drive completely unmountable. Read activity is stressful on a dying volume, especially a full-volume backup. We recommend that you immediately back up the files that are most important to you. When you have backed up the most important data, next try to do a full-volume backup. When you have recovered as much data as possible, we recommend that you replace the affected hard drive.
What if the dying drive's volume won't mount?
More often than not, you're completely out of luck. You may be able to revive a hard drive for small amounts of time by letting the drive cool down (somewhere cool and dry, not cold) and then powering it up attached to a service workstation (i.e. don't attempt to boot from it, you may not have enough time).