Support

Akeeba Backup 9 is a native Joomla 4 application. The CLI scripts have been removed and replaced with an integration with Joomla's native CLI application (new in Joomla 4).

Please refer to the Schedule Automatic Backups page in Akeeba Backup and our documentation for more information.

Have you published the Console – Akeeba Backup plugin? This is the Akeeba Backup integration with Joomla CLI. Without the plugin the CLI commands are not defined.

Sidebar: I know that this design is inefficient, but that is the way the Joomla project designed its CLI application. Yes, it's The One True Joomla Way to have plugins for everything — Joomla's power lies largely within its insanely flexible plugins system — but I think that it's inconvenient and inconsistent for a CLI integration. Inconvenient because it requires the user (you) to remember to check yet another thing whereas in WordPress the mere presence of enabled plugin (the equivalent of a component there) is enough to register CLI commands in WP-CLI, the equivalent to Joomla's CLI application, even through WP-CLI is not even bundled with the CMS but that's another gripe for another CMS. I digress. It's inconsistent because the integration of a component with the other three Joomla core applications namely the frontend, the backend and the API application (the latter being new in Joomla 4) is specified through the component's XML manifest, not a plugin. Unfortunately, I was not asked for feedback or I'd have said that components SHOULD have been able to register CLI commands through their service provider without the need for a plugin but having plugins also register commands is a good idea, in line with the One True Joomla Way for extending the CMS.

For us, this is not a big deal as we just need to turn on that plug-in manually. It would be great if it is turned on automatically after the installation like the "Quick Icon - Akeeba Backup Notification" plugin.

It is, but only on a new installation. It's not enabled on update. However in version 9.0.0 there was a bug preventing that which was fixed in 9.0.2. 

As a sidebar, I am not sure whether Admin Tools could offer the ability to rename the backend administrator path. In Joomla 3 it was done by another extension named adminexile. In Joomla 4, I think it is good to use Admin Tools but it seems that we could only add a password to protect it from hackers... which seems to be one extra step to login and not so convenient.

Yes and no. Yes, there is this feature. Go to Components, Admin Tools, Web Application Firewall, Configure WAF. Find “Change administrator login directory to”. No, we neither recommend nor support this feature. You cannot, in fact, rename the actual folder. What this feature does is some fine trickery. Let's say your site is www.example.com and you use the admin folder name magic. When visit www.example.com/magic this is handled by the public frontend of your site. However, the Joomla admin and site applications are isolated. What we do is catch the 404. At this point we create a token which is locked to your IP address, browser user agent and has an expiration date and time (3 minutes into the future). The token is two part: a random seed and a hash. We set a cookie with the random seed and an expiration time of 3 minutes, then redirect you to /administrator/index.php. At this point the admin application loads. We check if you have the seed cookie, use it to calculate the hash using your current IP address, browser User Agent string and Joomla's secret, then compare it with the hash we calculated in the previous step (in the public application). If everything checks out we set a session state variable. Further access to the administrator folder from that browser and IP address will check if that state variable exists.

There are many things which can go wrong. Your server may not report the correct IP address e.g. if you are behind a reverse proxy or CDN and have not configured that in Joomla's Global Configuration. Your IP address may change between consecutive requests (it happens on mobile). A third party extension in the frontend of the site may crash or output stuff making it impossible to set the necessary cookie. Your browser's extensions may reject the cookie or change the User Agent between the requests. None of these are issues with our code and cannot be addressed with code changes. That's why we offer no support.

Meanwhile, all those checks for cookies and session variables require your web server to load PHP, load the Joomla application, all system plugins and reach the execution point where these checks take place. That's a lot of CPU time and memory being wasted if you are using this feature to defend against brute force attacks (someone hammering the login page with a large number of usernames and password, in hope they get the right combination). It's inefficient.

Same goes for the admin secret URL parameter. It uses a far less complicated method (just a session flag) which means it's less sensitive to your site configuration. However, since it's implemented in PHP code it still needs Joomla to load and reach the execution point where we check for the session state variable OR the secret URL parameter. It does protect against brute force attacks BUT it would end up wasting a lot of CPU and memory doing so.

The waste is an innate characteristic of any defence measure implemented in PHP. These should not be the first or only line of defence.

The admin folder password is the BEST way to protect yourself against brute force attacks and works great as a first line of defence. Since it's implemented at the web server level it consumes barely any CPU time or memory (sub-millisecond compared to several dozens to hundreds of milliseconds and few Kilobytes of memory compared to several Megabytes). Moreover, that admin folder username and password can be stored in your password manager — if it's the one integrated to your browser you will never see that popup again, making it ZERO steps in practice.

You can still use other defences alongside it, e.g. the secret admin query parameter and Two Factor / Two Step Authentication. That's what I do for all my sites. A layered approach to defence is able to withstand far more attack modes than a Maginot line defence. 

You can use the Administrator Secret URL Parameter and Two Factor Authentication / Two Step Verification instead.

Administrator Secret URL Parameter

Let's say that your site is https://www.example.com and your admin secret URL parameter if foobar.

You will need to access your site's administrator login URL as https://www.example.com/administrator/index.php?foobar instead of https://www.example.com/administrator.

The bots trying to brute force your site's passwords will not know that. They will get kicked back to the frontpage of your site and a blocked request will be recorded. If they do that several times their IP gets temporarily blocked. If they get their IP blocked several times their IP will be banned permanently.

Your team will have no problem. You just need to tell them to update the bookmark they use to log into the site's backend.

Two Factor Authentication / Two Step Verification

You should use Two Factor Authentication (built into Joomla; I had contributed this feature 10 years ago) or Two Step Verification (with our free of charge Akeeba LoginGuard extension) for all users with backend access. Even if someone somehow got access to the login URL and a valid username and password pair they would still be unable to log into your site without fulfilling the second authentication step.

Most password managers have built-in support for TOTP (six digit codes that change every 30 seconds) which is what Joomla itself and one of the authentication options in Akeeba LoginGuard use. Therefore your team would be able to use that just fine.

Securing your site is not that hard. You just need to think it through and layer your defences. Remember that the objective is not to make your site impenetrable. This is an unachievable state, a fool's errand. At the very least, the humans logging into the site are the weakest links and can be conceivably fooled into subverting your defences. The objective is to make it so annoyingly difficult that successfully subverting your defences would cost more to the attacker than the target (your site) is worth to them. The attacker will quickly realise that and move on to the next potential victim. That's why having cameras, alarm systems and reinforced doors in residential buildings works. It's not that they can't be subverted, it's that the potential cost (in this case expressed as risk of being caught in the act or afterwards) is much higher than the potential reward of successfully breaking and entering into the residential building. That's also why businesses consider these measures as bare minimum and go for even more serious security measures if they present an appealing target, escalating to military–level security in defence contractors and other sensitive facilities.

Having that in mind you can find what is the right balance between convenience and security for your use case.

You’re welcome and thank you for your kind words, I appreciate it!