Support

That documentation text needs to be updated. Since we are using the new Joomla 4+ UI we have moved ordering from clicking on headers to the drop-down above the list of backups, as is its modern (post Joomla 3.6) UI convention. The default selected option is “ID ascending” as per standard Joomla! conventions (this is the same thing Joomla! does with articles, for example). You could also sort by name (description) and backup start (i.e. chronologically) in either ascending or descending.

Moreover, you can filter the backup display, which I believe is what you actually want. Again, we now use Joomla's UI conventions. Click on that Filter Options button to expand the filter form. You can enter any combination of from / to date and time (this is applied against the backup start time), the backup origin (backend, JSON API, CLI, …), the backup profile, and the frozen status. You can also use the search box to filter by partial description.

You cannot sort or filter by Status. This is a computed, display-only column. Filtering or sorting against that would require loading all backup records. On sites with a lot of historic backup records –there are sites with a 15+ year history of daily backups– it would cause a memory outage.

I guess one sees what one is looking for and I definitely was not look for that.

Absolutely. Neuroscience says this is a very real thing. The solution is fairly ridiculous. Point at the screen as you're navigating its elements. Surprise yourself at how fast you will spot which area of the screen you were literally glancing over before. This works when looking for stuff around the house, too. Point and talk it through as you search.

It would be nice to be able to easily find all the obsolete backups, all the backups that failed to upload to external storage, maybe sort the backups by size (some got aborted for various reasons so they show very small sizes in the display)

The Status column combines both the state (running, done, or failed) recorded in the database, and signals from the server's filesystem to come up with something that makes sense:

• OK: State done, the files exist on the local server, a remote storage path is not present in the database record.
• Obsolete: State done, the files do not exist on the local server, a remote storage path is not present in the database record.
• Remote: State done, the files do not exist on the local server, a remote storage path is present in the database record.
• Running: The recorded state is running, and it's been less than three minutes since the last recorded progress signal from the backup engine.
• Failed: The recorded state is failed OR the recorded state is running, but it's been more than three minutes since the last recorded progress signal from the backup engine.

While you can easily determine the Running and Failed statuses from database information alone, you cannot do the same with the OK, Obsolete, and Remote statuses; for these, you need information about the server's filesystem. The problem is that the database cannot access this information. In fact, the database server may not even be on the same physical / virtual machine as the web server, i.e. they might be completely isolated from each other.

Now, you might think, why don't you record what happens on the filesystem into the database, making the status able to be computed just from database information, therefore searchable and orderable? That was indeed the case in very early versions of Akeeba Backup, but there's a problem.

Let's say a user takes a backup, storing it only on their server. Akeeba Backup records that information, and the backup record appears with the OK status. Sometime later, the user deletes the backup archive files outside of Akeeba Backup, e.g. by FTP, SFTP, their host's file manager, it doesn't really matter how. Since it's done outside of Akeeba Backup, Akeeba Backup does not know the files are missing. It still shows the backup record as OK. The user then tries to restore that backup. They cannot because, obviously, the backup archive no longer exists.

A lot of people will blame the software. First, there are the nutjobs who expect us to magically have all of their backups stored on our server, without them having to send them to us, pay for storage, or even have any indication whatsoever that this is even remotely possible who will ridiculously accuse us that we are magically holding their sites ransom. It's okay, these can be dismissed because a. you can't fix stupid, as anyone with more than 5 minutes of experience interacting with the public can attest (there are even sites like NotAlwaysRight documenting the plights of such interactions) and b. negative reviews from obvious nutjobs only add credibility to a listing (what a world we live in...).

The real problem is the people who are technically correct by complaining that the software should have picked up the change in the filesystem, which might not be up to the user anyway! For example, another admin or the host might have done something stupid without them knowing, an automation may have broken etc. Their negative review is a legitimate black mark because they are technically correct.

This did happen, and there was the question on how to solve it. One way is to re-evaluate the Status when displaying a bunch of records, storing the state back to the database. That was the original solution, but it's not good for two reasons. First, it will only result in an updated status in the database when you list records. Second, and follows from the first, when you filter by Obsolete you will NOT find all obsolete records as there might be records marked as OK which have now become obsolete. Therefore, this solution is still misleading, and the users are still rightfully complaining.

Which brings us the solution attempt the second: do NOT store any filesystem state information in the database! This works fantastically, but has the drawback that you can no longer search by Status. This is what I ultimately implemented because it can never mislead you, and the problem of finding a backup of a certain Status devolves into listing 100 records at a time and quickly scanning the list visually. Even if you have ten years worth of backups it's at most a ten minute job to find the record with the odd Status – I timed myself.

So, yep, I totally understand your request and I wish there was a way to implement it, but that would bring us back to one of the previous two states which are misleading to the user and will cause a lot of legitimate complaints. When faced with a "damned if you do, damned if you don't" situation, the maker of a mass-distributed piece of software will always select the solution which is least problematic for the majority of users. Such is life.