Support

I have seen that webcron can also inform of failure and if I understood correctly this check should be realized three or more hours after backup initiation for being on the safe side.

It needs to run at least 10' after the last backup has run and before any other backup has started. How much is that time since the backup started? It depends on the site :) Usually I recommend checking how long it takes to run a backup and add 50% or 10' to that, whichever is greater.

Extly, once upon a time, did a Joomla crontab based on the time page loads were realized. Is this feature working? I ask as if not server migration is not portable as I might have to depend on logging in to the control panel.

We have already explained why this feature was removed. There were 14 reasons that you can find in older versions of our documentation (it was 2+ printed pages). In short, if you expect visitor traffic to trigger your backup you'll end up with inconsistent backups at random times which might be corrupt too. Not exactly what you'd expect from backups!

Regarding server migration, um, it requires taking a backup and the restoring a backup. It is fully "portable" for the common definition of "portable" (yes, you can transfer your site to a new server). In fact, Akeeba Backup was created to transfer sites between servers. Backing up is just one of the possible use cases where the source and target server are the same. That said, I don't see how that has anything to do with scheduling your backups with CRON tasks. Also, I don't see how any of that has anything to do with Akeeba Solo, the standalone PHP backup application we are producing.

Yes, I understand that, but between having definitely broken backups and potentially forgetting to set up backups which one you'd prefer? As I said, look up the old documentation and you'll see why this feature was discontinued. It wasn't just bad, it was abysmal. All the issues we bumped on were simply impossible to fix. We'd have to, ironically, have greater control on your server than what you need to set up a CRON job in order to work around half of them. As for the other half of them, you'd need to make your site unavailable to most visitors while a backup is running which is a bit against the whole idea, right?

As for Akeeba Solo, yes, indeed you should get a 403 Access Forbidden since you do not have a SOLOPHP subscription. Akeeba Solo 1.0 betas were available to all subscribers in April 2014. Since late 2014 when the software went stable you need a valid SOLOPHP subscription to access it.

Hello Emilio,

I see that you've downloaded non-backup software (Admin Tools) during your active subscription's term. I can change your subscription type to SoloPHP but please do remember that you will no longer get downloads and support for Admin Tools. Furthermore support for Akeeba Backup for Joomla! / WordPress will not be provided, you will only receive support for Akeeba Solo.

Basically, you are asking me to forbid you to download and request support for our Joomla! products and, at the same time, allow you to download and request support only for the standalone Akeeba Solo product. Please let me know if this is acceptable.

PS: If you want both Joomla! and standalone products you can always log in to your account on our site and purchase a SOLOPHP subscription. Our system will give you an automatic discount of approximately 40% off the listed price.

Sorry for the delay, I am in the U.K. for the Joomla Day.

I have updated your subscription type. Please remember to log out and then log back in to get access to the correct downloads.

Regarding the update, we do not have an automated update CLI script for Akeeba Solo yet.