Inability to see files (hinted at in the original post, but more clearly visible in this message) could be the infamous Microsoft restriction of 5000 files (at their default) in a single list. Although two experimenters have seemingly avoided the limit by changng to Duplicati’s OneDrive v2 storage (which uses a newer Microsoft API), there don’t seem to be any claims that I can find that this is supposed to avoid the limit.
From a math point of view, 300 GB at 50 MB per file means 6000 dblock files of source file data, but a dblock also has a dindex file to index its contents, so you might be at 12000 files on SharePoint. It may refuse to list 12000, so makes Duplicati believe there are none. Do you have another way to check it?
Switching to OneDrive v2 and allowing backend verification can test whether it helps any in your case.
Manage large lists and libraries in SharePoint describes workarounds which an administrator may do.
How to resolve the 5000 item limit on a list. discusses limit rationale, and mentions using multiple lists.
Logic and usecase for remote subfolders is a Duplicati discussion of how someday that may be done.
This post within it references seeming successes where switching to OneDrive v2 fixed the file listing. Another workaround mentioned in the topic is to use a larger --dblock-size to stay below 5000 files, but another workaround might be to split your 300 GB backup into several smaller sections. This may also improve performance, especially for local database Recreate in the event of loss. Smaller goes faster.
Choosing sizes in Duplicati gets into –dblock-size and –blocksize selection. --dblock-size can change whenever you like. This applies to future dblock creation, so won’t easily resolve current small dblocks. Restarting would be easiest, but if not possible there’s a chance the current can be repackaged blindly.