That was my first comment too: you’ll have to test your backups otherwise you don’t know if you have backups 
It’s a Schrödinger’s cat type of problem −> you have to open the box.
And it leads me to a second aspect: automation. good backup processes (the one that brings piece of mind) are automated. And of course the backup check can be automated too.
It’s piece of cake for a backup solution that you can script (borg, restic, kopia, rsync, etc.) but frankly I don’t know about Yunohost, may be you can’t do better.
On the side, I’ll share one of my sysadmin fails: I had a finely tuned backup process with scripts/config/etc. that was running daily for years flawlessly. Someday I leveraged that backup as a source of data to do a server migration (shutdown old system, start new one, restore data from backup). That worked great. Then I tested some web apps: epic failure (missing MySQL tables). What could have gone wrong?
Answer: I had setup my backup script to ignore files named */mysql/*log* because I don’t want to backup MySQL log files. Not so much of a surprise: this element of config instructed my backup process to exclude database files named like dc_log.MYD or oc_login_address.ibd (and many others).
Of course I had another way to retrieve the missing data. But, hell, I was not comfortable.