In terms of providing a job log, you can highlight the text of the log in the viewer window and copy/paste it somewhere, or you can right-click the background, select Print, and print it to PDF. However, with the latter option be aware that your Reflect license key is included at the bottom of every job log, so if you don't have a way to edit a PDF after it's been generated, that might not be ideal. But your retention policy configuration could have been posted by capturing a screenshot of the wizard view that shows it. The Snipping Tool built into Windows is useful for this purpose because in addition to letting you draw an arbitrary rectangle, it can automatically capture a particular window.
In terms of your issue, your schedule specifies a Full every month and your retention policy specifies to retain 26 weeks of Fulls, which would be 6 Fulls. When you say your backup size total is 2TB, I'm not sure if that's the total size of the source data before compression or the size of the compressed backup file that gets generated, but either way you won't be able to store 6 Full backups of that size given your available capacity at the destination, and that's before even taking into account your weekly Diffs and daily Incs.
That said, you do have "Delete oldest backup sets when free space is less than 500 GB" enabled, which would normally prevent jobs from failing due to space issues, because that option allows Reflect to delete the oldest sets even if the free space drops below the specified threshold in the middle of a backup. So if your backups are failing, I'm thinking some of your old backups might no longer be considered "matching backups" if you recently upgraded to a newer release of Windows 10. That process can alter your partition map, which means Reflect would consider previous backups not to "match" the new jobs, and therefore by default the retention policy and disk space threshold purge would not be applied to them anymore. More info about that, including options for fixing it, is available in the first post of this thread
. The easiest fix if you have a destination folder dedicated solely to backups generated by that job (as opposed to a folder that multiple jobs are writing to) is to set the matching policy to "All backups in the destination folder" rather than the default "Matching backups in the destination folder". In any case, seeing the job log should help determine whether that's what's going on. In the retention policy section of the job log, Reflect reports the number of matching backups it see on the destination. If the number of backups Reflect reports is less than the number of backups in the destination folder, that's likely what's going on.
Anyhow, this might also be a good time to rethink your retention policy in general. First, you generally don't want to rely on the disk space threshold purge as an alternative to specifying a realistic retention policy, because the disk space threshold purge deletes entire SETS when it gets triggered, i.e. the oldest Full and all of its child backups (which would be an entire month of backups in your setup), whereas a retention policy can delete individual child backups. So again, you may want to take a look at the size of the backup files that are being generated and adjust your retention policy to something that's realistic. On that front, you might find it easier to switch your retention policy settings to be based on number of backups rather than a period of time.