Most Valuable Professional
Group: Forum Members
It looks like your cloud storage is retaining previous versions of uploaded files rather than overwriting/deleting them. To reduce your cloud storage consumption, and for practical reasons if you want to use a Reflect strategy that will cause Incremental consolidation to occur, you'll need to find the option in your sync application that basically says, "If a file is modified on the NAS, then permanently overwrite the cloud copy with the new version rather than keeping the existing copy as a previous version." Additionally, the MRIDX file you see in the cloud is created only temporarily while Incremental consolidation occurs, and it looks like your cloud repository has 4 versions of that file? That suggests that the sync isn't even propagating standard deletions properly, as opposed to overwrites.
With respect to Reflect configuration, there's some limitation around Incrementals Forever / Synthetic Fulls and time-based retention policies; I can't remember it exactly, but there's some case where you have to use backup count-based retention policies instead. But you may want to consider doing that anyway, since that removes the risk of losing an unexpectedly high number of backups after your PC hasn't backed up for a period of time, e.g. after a vacation. But either way, if you're using Incrementals Forever, then the Full retention policy in most cases won't matter since the most recent Full is never deleted based on time unless you're capturing a newer Full -- but if you're running true "Incrementals Forever", then you wouldn't capture a new Full.
Incrementals Forever is indeed the most storage-efficient way to store a given backup history. If you're syncing to the cloud though, it's not ideal. The reason is that if you use Incrementals Forever with Synthetic Fulls enabled, then each new backup will cause the oldest Incremental to be merged into the root Full, which means your Full will need to be re-uploaded to the cloud after each backup because it will have changed -- and since the Full is quite large, that's probably not desirable, especially if your cloud storage provider charges you for bandwidth like Amazon S3. If you disable Synthetic Fulls, then you can avoid that because in that case, the second oldest Incremental will be merged into the oldest Incremental and therefore the Full will not be touched. That avoids having to upload the Full to the cloud more than once, but it also means your Full gets more and more stale over time, so eventually you might want to run a new Full manually, which technically isn't "Incrementals Forever" anymore.
One schedule and retention policy combination that may split the difference here in terms of keeping storage consumption to a minimum while minimizing hassle and manual work would be the following:
Run Full backup every week (or maybe every 2-3 weeks if you want to minimize Full backup uploads), run Incremental every other day
Retain 1 Full, retain 1 Incremental
Synthetic Fulls disabled
Run purge before backup disabled (i.e. run purge after backup)
Note that this will mean that immediately after a new Full runs, that new Full will be your only remaining backup, so make sure you're ok having periods where you have no historical copies of your data -- but given your minimal retention policy, it sounds like you are. And unchecking the "Run purge before backup" option means you avoid the risk of deleting all of your backups before a new one runs.