Hopefully you’ve successfully finished your first backup by now?!
One other bottleneck you might have experienced is due to the SMR drives used in many USB enclosures today. Given you’ve got a nice beefy machine, this may be slowing you down far more than @fd0’s suggestions above.
Restic’s small default filesize means that a repo often comprises many more files than the source data. And all of those small files are a speed-killer for SMR drives once their internal cache is full.
The above problem isn’t limited to Restic’s backup operation: try to rsync a restic repo to an SMR drive and you’ll see it slow to a crawl.
Other than avoiding SMR USB drives (which is increasingly impractical), or switching to a backup, such as Borg, that uses bigger datafiles (but then you miss out on other Restic goodness!), the solution is to increase the repo’s datafile (“pack”) size, but that’s still only possible by applying a PR, for example this. Fingers-crossed for the next release: after the epic pruning speed-improvements of 0.12, I can’t think of another in-the-works change that will make as big an improvement for as many of Restic’s (potential) users, particularly as small pack files also impact performance on some cloud-backup targets.
I’m guessing by the slow pace of implementation of this feature, none of Restic’s primary devs suffer from the bottleneck 
(not a criticism, that’s their prerogative, and their work on Restic is greatly appreciated!).