Support

I believe that the message you received reads that the default backup directory is in use. This is not an error, it's a warning, and presented as such — with the explicit note that you can backup your site. The message itself links to a page which explains that this is only a minor, potential security issue on a minority of live web hosts where all other mitigations we have in place have failed. Since you are on a local server you can of course use the default output directory.

Moreover, you said that “I could have created another directory per Akeeba docs but that doesn't solve the problem” which, as phrased, is wrong for two reasons. First, you imply you didn't try it. Second, creating a different folder is not enough; you have to tell Akeeba Backup to use it as per the documentation. But wait, there's more.

Since you are on Windows and using XAMPP, you need to remember that XAMPP does not run under the same user account as you are logged in. Therefore, any folder or file that you create (e.g. through Windows Explorer) will not be writeable by the web server. You will have to give it the right permissions. This is not something new. That's how XAMPP has been working for well over a decade*. Since your server is not exposed to the Internet, the easiest way is to give all permissions to Windows' Everyone user. Right click on the folder in Windows Explorer, select Properties and click on the Security tab. Click on the Edit... button. If you can't see a user named Everyone, you will have to click on the Add... button, type Everyone in the big text box and click OK. Now click on the Everyone user and then take a look at the list of checkboxes below. Click the Accept checkbox on the Full Control row (the topmost one). Click on OK, then again on OK.

If you do not believe me, there is a very simple method to be convinced. Uninstall Akeeba Backup from your site. Download the previous version (9.6.1, released a month ago). Install it. You will have the same problem. I think it's fairly obvious that it's impossible to have a broken version out there for a month, with tens of thousands of sites unable to take a backup, for we had stopped existing as a company to put it plainly. Ergo, the root cause is misunderstanding the information on your screen and not taking Windows permissions into account.

* Side note about XAMPP. Back in the late 00s / early 10s (around the time Windows Vista and 7 which introduced permissions checks even in the Home versions) it would still install in C:\XAMPP (just like it did when Windows XP was around) and its directories would be owned by your Windows user. As a result, you never had to deal with permissions. Starting in the early 2010s (late Windows 7 era, early Windows 8 era) XAMPP gave an option to be installed in C:\Program Files (x86), and its services (Apache and MySQL) would no longer run under your Windows user, nor its folders be owned by your Windows user. This led to issues with permissions. It became a problem restoring sites which is why I wrote this page: https://www.akeeba.com/documentation/akeeba-kickstart-documentation/kscantextract.html#kstslocal. Sometime in the mid-2010s (I think it was around 2015, if memory serves) it started defaulting to be installed in the Program Files directory. This has confused people to no end ever since.

I do not appreciate your tone in your first reply to me. I am trying to help you despite the fact that as a non-subscriber you're not entitled to support and the fact that it's past 1am in my time zone. Instead of thanking me for helping you despite the fact I don't even have to, you insult me. Address me in the same professional tone I address you.

You also seem to make a number of false assumptions about how I came to my reply. Here are the data points I have when replying to you, which will help you understand my deductive reasoning:

• The backup engine itself has not changed at all between versions 9.6.0 and 9.6.2. This is something you could have easily proven had you followed my instructions for a downgrade.
• Akeeba Backup 9.6.2 has been ready for release since June 7th, 2023. In the three weeks between it being ready and being publicly released it's been installed on over a dozen development, testing, and live sites across a number of local and live servers. We have taken and restored hundreds of backups with it. This includes this very site here.
• 9.6.2 has been used by a number of paying clients who sought help for one of the issues addressed in this release. All of these users have been able to take multiple backups successfully, further proving the fact that 9.6.2 works fine.
• This software is used by several hundred thousand sites at any given time. As it has consistently been the case these past 17 years I have been releasing this software, any issue affecting backup or restoration —even if it only affects a fringe minority of server configurations— is reported by at least three separate paying clients within an hour of the release introducing the issue. It's been more than 15 hours since 9.6.2 was released and we have received no such reports.
• The message about the default backup directory being in use has been around since JoomlaPack 2 released in 2009 (JoomlaPack was what Akeeba Backup was called between 2006 and February 2010, versions 1.x and 2.x). Therefore you can't possibly claim this message didn't exist before. The last time the code which displays this message, and the wording in the message itself, had been changed was March 12th, 2021 — when Akeeba Backup 9.0 was rewritten from scratch for Joomla 4.0.
• The fact that you have a problem after installing the update does not mean that the root cause is the code in the update. It only means that the root cause was something that happened between the last backup and you installing the update. Note that since XAMPP's Apache service runs as a different user than your Windows user it's possible that installing an update changes the permissions of your default backup output directory (since it's inside the folders being re-written by Joomla during an update).

Based on these facts, it does not look like a bug in the software.

So, of course I will tell you about the most likely issue being XAMPP since it has a pretty major caveat with ownership and permissions which can indeed cause the problem you originally described and even a backup failure. This is the reason that, back when I had a Windows computer (2016 to 2018) I was not using XAMPP, instead setting up IIS the right way and with some pretty nifty PHP optimisations (read the latter to understand some of the points I make below). Far from being a "smarmy" reply, my reply was the most likely to be helpful in this context.

Sure, your problem can have a different root cause. Off the top of my head:

• Joomla may have messed up and not copied all files during the update — see https://github.com/joomla/joomla-cms/issues/41087 for the technical details.
• XAMPP runs —or at least used to, last time I tried it— a PHP 32-bit thread safe binary even though it uses a 64-bit Apache and PHP is used over CGI, therefore causing backups to randomly fail if they run "long enough" (where "long enough", in my experience, was anywhere from 5 to 30 steps). This can be worked around.
• A database table is corrupt and causes the backup to fail. MySQL on Windows is notorious for this.
• You may even be running out of disk space.
• Many, many more things which can go wrong that only the backup log file can help us determine.

The first thing I want you to try is change the Windows file permissions as it's both the most likely issue and by far the easiest to address. Find the root folder of your site. Right click on the folder in Windows Explorer, select Properties and click on the Security tab. Click on the Edit... button. If you can't see a user named Everyone, you will have to click on the Add... button, type Everyone in the big text box and click OK. Now click on the Everyone user and then take a look at the list of checkboxes below. Click the Accept checkbox on the Full Control row (the topmost one). Click on OK, then again on OK. Now try taking a new backup.

If the backup worked, the problem is what I said: XAMPP and the way its permissions work. That's the end of it.

If the backup still fails I want you to do two things:

1. Tell me what is the exact error message which appears in the page appearing after the backup terminates after the third automatic retry fails.
2. Download the backup log file, put it in a ZIP file, upload it to OneDrive (or Dropbox, or Google Drive) and paste a pubic share URL here. The log file tells me what is going on. If there is no log file generated, do tell me.

Please note that it's very late where I live and I have other engagements over the weekend. Most likely you'll see a reply from me sometime late Sunday to early Monday your time.

The database table kowq1_akeebabackup_backups is corrupt. MySQL has “forgotten” its id column is an auto number column. 

This can only happen if someone exports the database and imports it without keeping the database structure, eg using phpMyAdmin’s export to CSV. Neither our code (GOD FORBID!), nor Joomla (which handles extension installation and updates, including updating the database) do that kind of stupid crap exactly because it’s stupid crap. So, as I said from the beginning, our update is not to blame. You seem to have done something, most likely inadvertently and thus without you actually noticing, or you were bitten by the infamous instability of MySQL on Windows when shoddily configured (XAMPP’s signature feature: shoddy configuration of everything under the sun).

Ironically, the best way to fix that is to restore the backup from the day before you installed the update, make sure you can take a new backup (for obvious reasons), then install any extension updates. 

So. Not our monkey, not our circus, I’m closing this ticket with prejudice.