You can edit the global, component-wide options by clicking on the regardless of the active profile.
button towards the top right hand of the page, in the Joomla! toolbar area at the top of the page. The Options editor opens in a new page. Please note that the Options page is handled by Joomla itself, namely the built-in com_config component. Further to that, the component Options applyThe documentation of the component Options page is organised by each tab displayed by Joomla.
These options define how Akeeba Backup will display its administration interface
Help us improve our software by anonymously and automatically reporting your PHP, MySQL and Joomla! versions. This information will help us decide which versions of Joomla!, PHP and MySQL to support in future versions.
Note: we do NOT collect your site name, IP address or any other directly or indirectly personally identifying information. A randomly generated site ID is used to make sure only the latest information submitted by your site is taken into account every month. At the end of each month we generate and store aggregate information, discarding the individual data points collected for that month. Therefore it is impossible for us to link any of the information submitted back to a specific site or individual in full compliance with the European Union's General Data Protection Directive which governs our handling of personally identifiable information.
Defines how the Start time of backups will display in the Manage Backups page. Leave blank to use the default date format. The date format follows the conventions of the PHP date() function.
When this option is set to No the time the backup started is shown in GMT timezone in the Manage Backups page. If you set it to Yes the time will be shown in the logged in user's timezone.
Please note that this feature will not work reliably unless you have set the correct server timezone in Joomla's Global Configuration. Keep in mind that your server's timezone may be different than the timezone you live in or the timezone of the hosting company's offices. For example, it's possible for an Australian to be hosted with a British hosting company whose servers are in Amsterdam. The correct server timezone in this case would be Europe/Amsterdam.
Moreover, you need to have selected your local timezone in your user profile in Joomla!.
If these prerequisites are not met the time displayed will be off. Lack of configuration on your part is not a bug on our part. Please triple check your timezone settings before filing a "bug" with this feature.
Choose the suffix to append to the backup time in
the Manage Backups page. None
will result
in no suffix. We don't recommend it as it's not
immediately obvious which timezone is being used.
Time Zone
is the recommended and default
option. It will print the human readable timezone setting,
e.g. EEST for Eastern Europe Summer Time, PDT for Pacific
Daylight Time and so on. GMT Offset
will
instead display the timezone as an offset from GMT, for
example GMT+3 for Eastern Europe Summer Time or GMT-7 for
Pacific Daylight Time.
When this option is enabled, users restoring a backup will see the Delete everything before extraction option. This is a dangerous option, meant for advanced users. It will try to delete all files under the backed up site's root before starting the restoration. The obvious danger in this option is that it might delete more than you expected since it cannot and does not know the meaning of each folder under your site's root. It might end up deleting your subdomains, add-one domains, your emails or your cat photos.
Before using this option please make sure that you have kept copies of your backups and any important files outside of your site. If you screw up when restoring your site we take no responsibility. You have been warned.
Your settings can be automatically stored encrypted using the industry standard AES-128 encryption scheme. This will protect your passwords and settings from prying eyes. If, however, you do not want to use this feature, please set this option to No and reload the Control Panel page to apply this setting. Do note that your server must have either the mcrypt or the OpenSSL PHP extension installed for this feature to work. Please keep in mind that even if your site is using HTTPS this doesn't mean that you have the OpenSSL PHP extension installed. You usually have to ask your host to enable it for you.
Tip | |
---|---|
For security reasons, we recommend always having this option turned on |
Please note that you may have to go to the Configuration page and click on the button before Akeeba Backup can successfully detect if your server supports encryption or not. Before doing that, Akeeba Backup might always report that your server does not support encryption.
When doing AJAX requests the server-side code in
Akeeba Backup runs the PHP flush()
function
to indicate to the web server that it should start sending
data to the browser. We have seen a single server in
nearly 20 years where this is a problem, i.e. running
flush() causes it to crash. If you are one of the small
handful of people on such a misconfigured server, set this
option to Yes. Otherwise, leave it at its default No
setting.
Here you can define options which affect front-end, CRON and remote backups.
Only applies to Akeeba Backup Professional.
This option controls whether the legacy front-end backup feature of Akeeba Backup is enabled. This feature allows you to take backups and check for failed backups from the front-end of your site, using standard HTTP redirections. Please remember to enter a Secret Word if you decide to enable this feature.
Only applies to Akeeba Backup Professional.
This option controls whether the Akeeba Backup JSON API — used by third party services and the Akeeba Remote CLI command line tool — is enabled. This feature allows you to take backups from the front-end, using standard HTTP redirections. Please remember to enter a Secret Word if you decide to enable this feature.
Required to authenticate either of the two previous remote backup methods. Also protects the front-end backup feature from Denial of Service attacks by requiring you to pass this secret word in the front-end backup URL.
Please note that if you use any character other than a-z, A-Z and 0-9 you MUST NOT use the secret word verbatim in the front-end backup URL. Instead, you have to URL-encode it. The Schedule Automatic Backups page does that automatically for you. Just go to Components, Akeeba Backup, click Schedule Automatic Backups, scroll all the way down and use one of the tabs to get the URL or command line you need to use with the secret word properly encoded in the URL.
For security reasons, you must use a complex enough secret word. Akeeba Backup's JSON API and front-end backup features enforce that by disabling themselves if you are using a Secret Word with a low complexity. We strongly recommend using a "secret word" consisting of at least 16 random, mixed case alphanumeric characters. It should not be a dictionary word or based off a dictionary word. One good resource for truly random secret words is Random.org's password generator.
Note | |
---|---|
Why is this field not a password field? The Secret word is transmitted in the clear when you load the page and is also visible when you view the source of the page or right click on the field and choose Inspect Element. In other words, as long as someone has access to the component configuration page they can trivially find out the secret word. Not to mention that the secret work is also plainly visible in the Schedule Automatic Backups page. Always use HTTPS with a commercially signed SSL certificate when configuring or backing up your site. |
The timezone which will be used for all of the backup naming variables processed by Akeeba Backup. These are variables such as [DATE] and [TIME] which you can use in the filename template of backup archives, the backup output directory name, the front-end and remote backup emails and elsewhere.
The default option is called Default Joomla!
behavior
and it will find out the timezone the
same way Joomla! does: if there is a logged in user it
will use their timezone. If there is no logged in user
(e.g. front-end or remote backup) or there is a logged in
user but they do not have a timezone set in their user
profile the Server Timezone used in the site's Global
Configuration will be used instead. If that is not set it
will fall back to GMT (Greenwich Mean Time).
We recommend setting this option to the timezone the people responsible for taking and restoring backups are most familiar with. If you are the only Super User use the timezone where you normally live in.
When enabled, Akeeba Backup will send an email regarding the backup status every time a front-end or remote backup is complete or failed.
You can choose when Akeeba Backup will send the
email notifying you of the front-end or remote backup
completion. If you choose Always
it will
be sent every time a backup runs to completion. If you
choose Upload failed
the email will only
be sent for backups which completed but without managing
to transfer your backup archive to remote storage. The
latter option only has any effect on Akeeba Backup
Professional.
When the above option is enabled, the email will be sent to this email address. If you leave it blank, Akeeba Backup will send a copy of the email to all Super Administrators of the site.
You can enter multiple email addresses separated by
commas. For example:
Please note that the email addresses are fed directly into Joomla's email library. If Joomla considers your email address to not be well-formed it will not send an email to it at all. We recommend avoiding UTF-8 in email addresses for this reason. Each email message to each email address is sent separately (the are not CC'ed or BCC'ed). The more email addresses you include and the more time it takes for the remote mail server to respond the longer this feature will take to run. We recommend using less than 5 email addresses to avoid PHP timing out. If you need more than 5 email addresses you should consider creating an email forwarder on your server, i.e. an email address which will automatically forward all email messages sent to it to multiple recipients.
This option lets you customise the subject of the email message which will be sent when a remote, CRON or front-end backup succeeds. You can use the backup naming variables, i.e. [HOST] for the domain name of your site and [DATE] for the current date and time stamp. Leave blank to use the generic default option.
This option lets you customise the body of the email message which will be sent when a remote, CRON or front-end backup succeeds. Leave blank to use the generic default option. The email is delivered as plain text; you may not use any HTML to format it. You can use the backup naming variables, i.e. [HOST] for the domain name of your site and [DATE] for the current date and time stamp, inside the body text. Moreover, you may also use any or all of the following variables in order to enhance the clarity of your message:
The numeric ID of the current backup profile
The description of the current backup profile
The number of archive parts of the backup archive which was just generated
A list of filenames of the archive parts of the backup archive which was just generated
A list of filenames of the archive parts of the backup archive which was just generated and their approximate sizes.
Please note that Akeeba Backup does not store the exact size of each part file. It only stores the total size of all backup parts it has created. Akeeba Backup makes the following assumptions for determining the approximate size of each backup part:
The size of the only file of a single part backup is equal to the total size of the backup.
The file size of the whole parts (.j01, .j01, ... for JPA and JPS archives and .z01, .z02, ... for ZIP archives) is equal to the Part Size for Split Archives that you have defined in its configuration. This is true for almost all backup archives. In extremely rare cases parts may be up to 200 bytes short of the part size for split archive. It may also be wrong in case of a filesystem error which caused a backup archive to become truncated. That's why we're calling the size shown by this feature "approximate".
The file size of the last part (.jpa, .jps, .zip) of a multi-part archive is equal to the total backup size minus the Part Size for Split Archives that you have defined in its configuration times one less than the total number of parts.
Not recording the exact part size is deliberate. Trying to do that on backup archives with hundreds of parts would risk exhausting the PHP memory and cause the backup to fail. We consider being able to take a backup to be far more important than getting down-to-the-byte accurate file sizes reported in an email. Furthermore, byte accuracy is irrelevant since the file sizes are reported in Kb, Mb or Gb (automatically scaled).
The total size of the backup. If it's a single part backup it reports the size of the only backup archive part. If it's a mulitpart backup archive it reports the sum of the sizes of all backup archive parts. The size is printed in Kb, Mb or Gb (automatically scaled).
Available since Akeeba Backup 3.5.3. Shows the status of post-processing, e.g. uploading the file to remote storage like Amazon S3. If you are not using post-processing or you have the Akeeba Backup Core edition, this is always empty. If the transfer to the remote storage was successful it will output "Post-processing (upload to remote storage) was successful". If the transfer fails it will output "Post-processing (upload to remote storage) has FAILED".
The options under Check for failed backups are used with the feature for checking for failed backups automatically.
A backup will be considered stuck (failed) after this many seconds of inactivity. Please note that uploading backup archives to remote storage, such as Amazon S3, using the native CRON mode might take substantially longer than that. We advise you to leave this value as is and schedule the backup failure checks to take place a substantial amount of time (e.g. 1 hour) after the expected end time of your scheduled backups. If a backup failure check takes place before a backup has finished it is very possible that you will end up with a failed backup!
The email address which will be notified for failed backups
Leave blank to use the default. You can use all of the backup naming variables, e.g. [HOST] and [DATE]
Leave blank to use the default. You can use all of the backup naming variables, e.g. [HOST] and [DATE].
Akeeba Backup can notify you on backup start, finish and –sometimes– on backup failure using push notifications delivered through the third party application Pushbullet. Push messages are delivered to all your devices running the Pushbullet client software including smartphones and tablets (iOS, Android, Windows) as well as laptops and desktops (Windows, Linux, Mac OS X).
Please note that backup failure notifications can only be delivered for backups started through the back-end. For technical reasons beyond our control these notifications can not be delivered for remote (JSON API) and scheduled (CRON job) backups: if the backup fails the PHP executable stops working, therefore our PHP code to send notifications can not work.
Enable this option to allow Akeeba Backup to display desktop notifications. Unlike push notifications, these are only shown when you are taking a backup from the backend of your site, though your browser. They are displayed by your browser, not PushBullet. This feature is only compatible with browsers implementing the desktop notifications API for JavaScript such as Firefox, Safari or Google Chrome.
Select the push notifications type. You can select between PushBullet, Web Push and None. If you choose None the push notifications are disabled.
PushBullet is a third party, free of charge, service which sends notifications to your browser or its mobile application. As of mid-2021 they no longer have an iOS / iPadOS application.
Web Push, or Push API, is a web standard supported by most modern browsers. It is supported by Firefox, Chrome, Edge, Opera, Brave and many more browsers. Safari 16 supports Web Push starting with macOS Ventura and iOS 16.1. After setting this option to Web Push please save the settings and go to Components, Akeeba Backup for Joomla. You will now see a small area for managing push notifications, right below the backup quick icons.
Enter your PushBullet Access Token. You can find it in your PushBullet account page. Do note that this token gives full access to your PushBullet account and is visible by everyone who can view and edit Akeeba Backup's settings.
Using Web Push notifications has the following server requirements:
The PHP curl
extension must be installed
and enabled.
The PHP mbstring
extension must be
installed and enabled. This is also a hard requirement for
Joomla itself to work correctly.
The PHP openssl
extension must be
installed and enabled. This is also a Joomla requirement for
using WebAuthn and most Multi-factor Authentication methods
among other things.
If you are using PHP 7.2 the PHP gmp
extension must be installed and enabled. If you are using
PHP 7.3 or later you do NOT need this extension but having
it won't hurt; in fact, it will make push notifications (and
Joomla's WebAuthn and Multi-factor Authentication)
faster.
If the requirements are not met you will most likely not be able to receive push notifications from Akeeba Backup.
Web Push is an API implemented by your browser. Push notification endpoints are managed by the company which makes your browser e.g. Mozilla for Firefox, Google for Chrome, Microsoft for Edge, Apple for Safari and so on. We (Akeeba Ltd) have no control over the API or the endpoints being used. If your host needs to whitelist specific domains to access them over HTTPS please do not ask us which are the Web Push endpoints for your browser; we don't know as we are not your browser's maker. If your host cannot figure it out either you will not be able to use Web Push notifications on your site.
When you subscribe a specific browser on a specific device to receive push notifications we use that freshly created push notification subscription to send a notification to your browser. If you do not receive that notification it means that something's wrong between your server and your browser maker's servers. We cannot help you; we are responsible neither for your server's configuration nor the network infrastructure and endpoints maintained by the browser's makers. All we can tell you is that in this case you should click the button to disable push notifications to prevent Akeeba Backup wasting time trying to send you a push notification you cannot receive.
To better protect your privacy, the Push API allows the
applications using it — like Akeeba Backup — to encrypt the push
notifications using asymmetric cryptography, the same kind of
cryptography used by HTTPS to protect your purchases online. We
do make use of this encryption, generating a key pair the first
time you visit Akeeba Backup's Control Panel after setting the
Push Notifications option to Web Push.
These keys are stored in a hidden component key in the Options
page called vapidKeys
(VAPID is the official name
of the cryptography scheme used by the Push API; yes, we
understand it's a negative word, do tell that to the browser
makers and the W3C who are responsible for choosing that silly
name).
Note | |
---|---|
Since the push notification endpoint URL is under the control of the browser's maker it would be possible for them to read your push notifications. Using encryption means that only your server has they keys to create encrypted notifications and only your browser (but NOT the browser's maker!) has the keys to decrypt them. Therefore all the browser's maker sees is “garbage” — encrypted text they can neither read nor modify. This ensures privacy of your push notifications. |
The cryptographic keys cannot and must not be changed. If
you change them, existing push notification subscriptions will
stop working as they cannot be decoded. If you start receiving
notifications with garbage data, console errors about being
unable to decode the push data or stop receiving notifications
altogether what has happened is that the VAPID keys got changed,
e.g. because you restored an old backup of your site or some
third party software messed with the settings of our component.
In this case delete the records from the
#__user_profiles table which have a
profile_key
equal to
com_akeebabackup.webPushSubscription
. Do remember
that #__ needs to be replaced by the table
name prefix for your site.
When you enable push notifications you subscribe
a specific browser on a specific device to
receive push notifications. The information to do that is
recorded in the
#__
user_profiles
table (where #__
is the table name
prefix for your site) in the records which have a
profile_key
of
com_akeebabackup.webPushSubscription
. There is one
record for each user subscribing to push notifications. When
Akeeba Backup sends notifications it goes through all records.
If you demote a user (move them to a user group which does not
have access to Akeeba Backup) their push notification
subscriptions are NOT removed. As a result, they will continue
receiving notifications. The same applies if the user account is
disabled and all of its other information is replaced with
anonymous / fake information, like most GDPR tools do. They only
way to get rid of notifications in this case is to delete the
user account completely.
When Akeeba Backup needs to send push notifications it has to perform one HTTPS request for every push notification subscription of every user with push notifications enabled. These requests typically take a few milliseconds. Given enough users and devices and/or a slow server or a server blocking outbound connections this may cause a long enough delay which will result in the backup failing with a timeout. If this is the case you have no option other than NOT using push notifications with Web Push.
The notification endpoints provided by browsers typically have rate limits i.e. there's an upper limit to how many notifications can be sent and how fast they can be sent. These limits are NOT published anywhere, nor can we wait and retry sending notifications later (the backup would time out and fail). It is possible that if you have a backup that raises multiple warnings shortly before it finishes that you will not receive some notifications such as the backup start, the warnings or the backup end notification. Do NOT rely solely on push notifications to monitor whether your backup executes and/or whether it executes without warnings.
Notifications are also grouped. All notifications sent by
Akeeba Backup are tagged as com_akeebabackup
to
help the browser understand they come from the same source. Your
browser may elect to group notifications or even only show you
only the first or the last notification received with this tag;
we have no control over this behaviour. As a result it is
possible that you will not receive some notifications such as
the backup start, the warnings or the backup end notification.
As we said above, do NOT rely solely on push notifications to
monitor whether your backup executes and/or whether it executes
without warnings.
Depending on your browser and Operating System it is possible that you will receive the push notifications even your browser is not running. For example, this happens with Google Chrome on Android and with most browsers on Windows (they run a background task to receive push notifications, perform background data updates and check for new versions). If this is not the case for your browser and Operating System (e.g. most browsers on macOS and iOS) you will most likely receive the push notifications next time you open your browser. However, your browser may decide that the notifications are “too old” to bother you with them in which case they might not result in a visible / audible notification OR they might not be delivered at all. We are repeating ourselves, but, please, do NOT rely solely on push notifications to monitor whether your backup executes and/or whether it executes without warnings.
Push notifications are handled by a small piece of
JavaScript installed in your browser called a Service Worker.
The path to Akeeba Backup's Service Worker is
media/com_akeebabackup/js/WebPushWorker.min.js
or
media/com_akeebabackup/js/WebPushWorker.js
under your site's root. Browsers allow you to inspect which
Service Workers are installed and remove them. If you remove
Akeeba Backup's Service Worker you will no longer receive push
notifications. It is possible that your browser removes the
Akeeba Backup Service Worker as part of a different operation,
e.g. when clearing all caches, switching to a different user
profile and so on. If you stop receiving push notifications log
into your site and go to Components, Akeeba Backup to
automatically reinstall the Service Worker to your
browser.
Web Push notifications, just like PushBullet notifications, do NOT rely on your browser running at the time the notification is sent. Therefore you will be sent a notification even from unattended / non-interactive backup operations such as backups running over the legacy front-end backup URL, backups running over the JSON API, backups running through the Joomla CLI integration, and backups running through Scheduled Tasks. If you receive a notification when you are not using Akeeba Backup you now know where it came from and why.
This is the standard Joomla! ACL permissions setup tab. Akeeba Backup fully supports supports Joomla! ACLs and uses the following three custom permissions:
Allows the users of the group to take backups.
Allows the users of the group to access the Configuration page, as well as all features which define what is included/excluded from the backup.
Allows the users of the group to download backup archives from the Manage Backups page. It also grants them access to the Site Transfer Wizard feature.