![]() ![]() The sparse bundle was then mounted, and a routine automatic backup occurred. TMA then checked for “runtime corruption” of the backup sparse bundle, which took 90 seconds to complete successfully. ![]() TMA then started a countdown to the next backup, for which there was a long period of “preparing backup” which started at 17:22. The solution was to disable automatic backups altogether in the TM pane, wait a while, then turn them back on again. After I did that, the TM pane switched from cleaning up to “preparing” a backup which never came. I wondered if it might help to add Xcode to the TM exclusion list, in the hope that before the day was done I might complete at least one backup. I restarted the MBP in a bid to end those and restore normal backups, but that failed to achieve anything either, the TM pane still claiming that it was cleaning up. The log showed no sign of purposeful activity, and further scheduled backups were all cancelled, apparently because TMA was still backing up. TMA then spent the afternoon trying to recover from the failure, according to the TM pane “cleaning up”. But with less than 400 items to go, the router decided to reset itself, and the backup failed at 12:39. From then until 12:35 it plodded through copying Xcode as I’ve seen before. Looking at the T2M2 speed records, this backup started hopefully at a little before 07:52, reached a peak transfer rate of 9.38 MB/s just after 08:00, then hit Xcode at 08:17. That was at 08:23, 09:06, 10:19, even 12:08, at which time it had still only completed copying 80% of the data. I knew that with Xcode to back up this was going to take several hours, despite the TM pane insisting that there was only about an hour remaining. The day started well, with TMA getting stuck into its backup of 25.53 GB at around 07:50. Since then there hasn’t been a great deal of change on the MBP apart from updates to macOS 11.3.1 and Xcode 12.5. NETATALK TIME MACHINE BACKUP FAILED MACAs it’s unusual for both M1 Macs to be running at the same time, with the shared disk attached to the Mac mini, the last such backup was a couple of weeks ago (please don’t tut me). NETATALK TIME MACHINE BACKUP FAILED PROMy M1 MacBook Pro (MBP) doesn’t normally have external storage attached, so I’ve configured it to make backups to a shared backup volume on my M1 Mac mini, using Time Machine to APFS (TMA) running over Wi-Fi through my adjacent router. As I’ve spent much of the day sorting one such failure out, I thought it might be useful to discuss what went wrong and what went wronger. Being more complex and dependent on other systems, making Time Machine backups to shared storage on your network is more prone to fail. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |