This is not an error. It's Akeeba Solo checking the security of your backup output directory.
If your backup output directory is open to the public for reading it is a security risk. An attacker may guess correctly where your backups are stored — especially if you are using the default backup output directory. Guessing the correct backup filename is fairly trivial because most people will use the default backup archive file naming pattern of site-hostname-date-time and take their backups around whole hours, especially between 11pm and 6am. This means that an attacker would be able to try a few hundred URLs in just under 1 minute and download your backup archives.
Akeeba Solo has two defences against that. The first defence is putting a specially constructed .htaccess and a web.config file in the backup output directory. On most Apache, Litespeed and IIS servers this will forbid direct access to the files inside that folder. However, we have no way of knowing that unless we test for access. Akeeba Solo does that by creating a small file inside that folder and trying to access it over an HTTP(S) connection back to your site. If that fails an error is recorded in your Apache error log (403 access forbidden) which is a GOOD THING.
If Akeeba Solo can access this file over the HTTP(S) connection it will instead forcibly add the -[RANDOM] suffix to your backup filenames, i.e. it will add a dash followed by 16 random alphanumeric, mixed case characters. This addresses the potential security issue by increasing the search space by a few hundreds of billions times. That is to say, an attacker would have to test hundreds of billions of URLs before they could download your backups. This would take hundreds of millions of times longer than the Earth has been around, i.e. it's practically impossible.