Support

It's not a bug. This feature does exactly what it is meant to do: it checks if you are using the default backup output directory (administrator/components/com_akeeba/backup). You are, so it displays this message, as it should.

Remember that the backup output directory also holds your log files. Moreover, while the backup is in progress, it holds the temporary memory file (the backup engine state) used to step through the backup between multiple page loads, temporary SQL files with your database contents and your backup archives before they are transferred to remote storage. If the backup fails all of that is left behind. If the upload fails then the backup archive will also be left behind.

The point is that an attacker only needs to get lucky once. As a defender you'd need to get lucky every single time. The best defence is, therefore, not giving away anything the attacker can use. Using a predictable location for your sensitive files is bad defence. You are playing into an attacker's hand.

The point of having a default backup output directory is to let you quickly run the software when you install it, without having to go through a long configuration process. This is important when you are a new user or when you just want to use Akeeba Backup to quickly transfer a site, or take a copy of a site for technical support / web development purposes (in these use cases it's likely to be just a transient installation). For long term use you should really take the time to configure it with a backup output directory outside your web root or at the very least with an unpredictable name. This will mitigate entire classes of attacks and the reason why we recommend it and show this warning message.

None of this should come as a surprise if you actually click the message and read the information on the page it links you to :)

 I've wondered why you don't have it create a randomly named folder during install.

This is an excellent question :) I've thought about it but there were practical issues.

First, we'd need to make sure we can create a backup output folder which is writeable by PHP, readable by (S)FTP and inaccessible over the web without having any insight on the configuration of the server or the ability to test any of that.

Ideally, we want to create a backup output folder above the web root. However, it might not be possible because of a chroot() jail, open_basedir restrictions or permissions. We'd have to ask you, the user, if this is the case. This is confusing. If we don't, we are rolling the dice about whether this would work.

If we can't create a backup output directory above the web root, where do we put it? In the root? Inside our software's folder? Somewhere else? The only "safe" place so that we don't run afoul of the user's subjective preferences (or leave behind files after uninstallation) is inside our software's folder. This means that we've got a very specific location where that folder would be.

Then there's the problem of having a fully randomised name. Does the folder administrator/components/com_akeeba/JsPJwXsT belong to our software or is it a folder created by an attacker to muddy the waters? It's impossible for us to tell if someone asks that question. It also makes it impossible to create any kind of sensible documentation or video tutorials for beginner users.

One way to deal with all of this uncertainty is that we ask you which directory the backup output directory should be placed in, what do you want it to be called and please give us your FTP or SFTP connection information and make sure PHP can do loopback FTP or SFTP connections to your site. This is actively user-hostile. Especially the FTP / (S)FTP configuration is very complicated and we already know that from the Site Transfer Wizard. 

Therefore the best approach is to have a default backup output directory, use your Joomla FTP layer configuration to change its permissions if necessary and give you instructions for creating a different output directory manually. We've found that it's MUCH easier for people to create a folder by FTP / SFTP / hosting control panel's file manager and choose it with the directory picker than anything else we can implement within the confines of what is possible in PHP and without having privileged access in the way the hosting control panel software does. Moreover, having a default output directory makes it possible to write documentation and create video tutorials which make sense for newcomers.

Our approach to this problem — and many more problems — is the Windows and macOS one: automate detection when possible, provide sensible defaults when automation would be iffy, give options so that advanced and expert users can customise it the way they need it to be, give reminders when something needs to be optimised manually. This works better than the Linux model of "you have to be an expert on the software before you can use it for the first time" or the alternative model of some Linux distros and packages of "we'll try to automate everything but when we inevitably fail you will find yourself in the middle of the ocean, chased by sharks without even knowing how to swim".