sharded_backup_restore.js runs moveChunk (here and here) as part of its setup to create the desired data layout for the tests. moveChunk itself is not particularly robust to transient errors, and also does not properly return information related to retryability to callers (see SERVER-94595). As seen in BF-40497, a particularly slow variant may cause these moveChunks to spuriously fail.

This is similar to the issue seen in SERVER-114170, and can likely be addressed in a similar way. It should also be considered if an existing sharded collection creation helper (e.g. CreateShardedCollectionUtil.shardCollectionWithChunks or shardCollectionMoveChunks) can be used instead.