Thanks for explaining ... now we can discuss/cuss options ...
RAM ... 45G/96G ... I take it means 45G for web server and 96G for DB server?
What you didn't supply is free space specs on web server. Am assuming the NFS you mentioned has no space issues and plenty of free space remains.
Trying to setup your own task in a cron job separate from moodle's cron job to clean out moodledata/temp/backup/ is almost impossible to get the timing right. Your clean up cron will probably romp on a auto backup in progress.
So let's talk about space ... the largest directory in moodledata is filedir. That's where moodle stores files for the most part - and where moodle will store .mbz files if not told otherwise.
Other directories in moodledata ... like caches ... are best served quickly if they remain on the same server as code .... faster responses.
One could do this ... all of moodledata remains where it is and only filedir is on NFS via a mount point on web server. moodledata/filedir/ looks to be local drive but it's actually a mount point that goes to /nfs/moodledata/filedir/ Yes, that will be a bottleneck (slower) but ....
Factors ... preferences for backups and preferences for auto backups ... the first I would imagine are set to backup everything in a course. Any thing one could really do without? Ditto autobackups .... surely you are not keeping all - keep 2?
Think I might have used a term (dups) that was mis-communicated.
In moodledata/temp/backup/xxxxxxxxxxxxx/ when backup completes successfully, there is an .mbz file named 'backup.mbz' (that's the dup). But if you left backup file naming to defaults, the backup.mbz file when it is copied to destination, will also have it's filename changed ... something like: backup-moodle2-course-139-testuno-20200925-1800.mbz. So there will not be any dups ... the numbers at end of filename are a date/timestamp.
'SoS', Ken