I’m using restic 0.17.2 compiled with go1.23.2 on darwin/arm64. I’m using Mac OS Sonoma 14.7.1 on ARM. I am backing up to a 1.5TB ExFat partition on a USB3 external drive (SanDisk Extreme).
Occasionally (about 10% of the time), the restic backup -v command freezes after printing the scan finished in 11.138s: 235877 files, 6.442 GiB line. When that happens, killing restic results in it printing something about “cleaning up”, but it never quits. At that point, any access to the ExFat partition from e.g. Finder or Disk Utility causes that program to freeze. Ejecting the drive does not work, unplugging it does not help. I haven’t found a solution short of rebooting.
It seems that restic is triggering some MacOS bug. Still, I wonder if there’s anything I could do differently to avoid or recover from the bug. I also wonder if restic could do anything differently. More generally, I was wondering if others have experience with this.
You can send restic SIGABRT signal when it seems to be just sitting there, to get a stack trace. Please paste it in here. If you have no other restic process, pkill -ABRT restic should do it.
Another option is to prepend DEBUG_LOG=logfile.txt to your restic command, e.g. DEBUG_LOG=logfile.txt restic backup -v, to get a debug logfile.
I did format it on Mac OS. I suppose I could reformat it just in case. Update: I did try reformatting (on my Mac), let’s see if it helps. BTW, browsing the interwebs, I saw both your theory (that formatting on Mac OS is better) and the opposite theory (that formatting on Mac OS is bad, and reformatting on
Windows helps).
Thanks for the hints @rawtaz, I will try to post the debug info next time it happens.
Have you observed any change in the behavior?
Otherwise, have you considered any other drive format to use? Perhaps, like me, you chose ExFAT because it seems to be the only option if you must access the drive from macOS, Windows, and Linux…
I upgraded to restic 0.17.3, and haven’t seen the issue since. However, I’m not sure whether I just got lucky or it is gone (perhaps the FUSE-T fixes helped; their symptoms were a bit similar, though this issue shouldn’t have much to do with FUSE).
Yes, you got my reason for using ExFAT right. I wish MacOS could support NTFS properly (read-write), now that it seems Linux has a pretty stable driver. I think (free) APFS drivers for Linux/Windows are still in nascent stages.
Those fixes are only relevant for the mount command.
We’ve seen quite a few cases in the forum with damaged backups on NTFS disks, when backing up from Linux. NTFS on Linux seems to be somewhat unreliable when the host crashes or the disk is disconnected unexpectedly.
I also noticed that after the problem occured, UVFSService was running at 100% CPU. I put its stactrace sample (from Activity Monitor) in the above gist, note that it mentions ExFat operations. I think that’s a part of Mac OS that’s related to mounting exFAT. See e.g. UVFSService randomly hanging and hogging CPU for a (possibly) similar problem.
Update: This is definitely related to UVFSService, and force-quitting that service from Mac’s Activity Monitor is sort-of-a-workaround. I sent a “feedback report” about this to Apple (feedback id FB16135013); no idea whether anybody looks at those.
As I said before, when the problem occurs, restic freezes so badly that ^C does not kill it. Other programs that try to access the ExFAT drive also freeze. However, force-stopping UVFSService solves this issue (and unmounts the ExFat drive). The only problem with this “workaround” is that I found no way to remount the ExFat drive and repeat the backup short of rebooting the computer first.
Do you have a Bootcamp partition? I hear excluding it from Spotlight might help with the UVFSService. I guess you could also try excluding your repository from Spotlight as well. No sense in indexing that anyway.
I know I had a 18TB exFAT volume with a repository on it, and once it got a decent chunk of data in it, folder listings took forever. Like minutes to list one folder. And Restic operations were greatly impacted too.
I have since turned that drive into a 20TB external Fusion drive (2TB SSD + 18TB HDD) using APFS in this enclosure, and now it’s quite fast.
No, it’s a 1.5TB external drive and I’m on ARM Mac OS. I’ve excluded it from Spotlight since a month ago. This may have helped some (my issues are less frequent) but hasn’t solved the problem entirely.
IMO ExFat is ancient filesystem ok for memory stick to copy some files from one OS to another when no network is available - but not for anything more serious. Especially when using with macOS and its AppleDouble files. It tripped multiple programs I use when by mistake I used ExFat disk. Very few are macOS quirks aware.
I think the best is to use OS native filesystem. Format it as APFS and forget all issues.
There is no single filesystem working perfectly across various systems. It is mistake to design some solution to make it requirement.
Not to mention there’s no journal, so filesystem corruption is much more likely in a power outage, accidental disconnect, or system crash. Only reason to use exFAT is when you really need to use a drive on both Mac and Windows. Otherwise it should be HFS+/APFS, or NTFS, respectively.
But yes I’ve definitely had ExFAT choke even on SSDs on MacOS using Restic repositories. ExFAT just doesn’t handle thousands and thousands of files in a single directory as well as modern filesystems.
That said I have not specifically seen UVFSService act up due to exFAT. Might be worth looking into further.