Support

Hello,

do you mean backup profile, maybe? Backup archives are not linked to anything on your site, actually it's used by Akeeba Backup to "discover" archives that you manually uploaded on your web space.

Regarding your original question, it's not possible to preserve some options, but what you can and should do is to write your configuration in an abstract way using variables. In your case, instead of hardcoding the backup path, you can use variables such as [SITEROOT] or [ROOTPARENT] so it will work regardless of the location.

Finally, how often are you import backup profiles? Usually that's an operation that you have to do just one or two times during the life span of a website.

The "Importing archive" I was referring to is this one: https://www.akeeba.com/documentation/akeeba-backup-joomla/import-archives.html

Looking at your use case, since the output folder is completely different, the only solution is to manually edit them after you restored the backup.

What you can do is to simply create a backup profile where you exclude the Akeeba Backup tables, so they won't be restored on the new site.

The configuration of backup profiles is stored in the #__akeebabackup_profiles table. The backup history is stored in the #__akeebabackup_backups table. The restoration script already allows you to select which tables to omit on restoration. Therefore the feature you want is already implemented.

Kindly note that this will only work if a. you have turned off encryption of backup profile settings and b. you are restoring on top of the exact same Akeeba Backup version.

We are not going to ever implement a feature explicitly and misleadingly labelled as "Keep current Akeeba Backup configuration" which just skips restoring two tables. The simple reason is that by doing that we are NOT actually doing what that label says, as you might have divined from reading the two caveats in the immediately preceding paragraph. As I said, this works in this way ONLY under two conditions which are trivial for a human to enforce, but impossible to enforce programmatically as they do stretch across two different sites.

Let me go further into that.

If you are using settings encryption (default) then each site may have a different settings encryption key. The key is stored in a file, therefore it will be backed up and restored. If there is a mismatch between the key and the encrypted profile data, then the profile data cannot be decrypted and you get the profile reverting to factory defaults.

Obviously, in YOUR use case it's not a problem because the dev site is a clone of the live site you will be restoring again on top of the dev site, therefore they have the same settings encryption key (as long as you did not disable and then re-enable settings encryption on either site in the meantime). This, however, is not a reasonable assumption to make in the general case of a feature present in mass-distributed software which has to operate in all possible use cases.

Therefore, for this feature to work in the general mass-distributed software use case we would need to cache the current encryption key, decrypt all existing backup profiles, and then re-encrypt them with the new key. However, this is impossible because the archive extraction (which overwrites the key file) precedes the restoration and we cannot travel back in time. Extracting the key file under a different name is a major problem because we would now need special code to handle this situation even if the "Keep current Akeeba Backup configuration" feature is not used. This is a major concern if we are talking about incremental backups, or the far more often occurring use case of someone needing to replace their sites files without going through the full restoration.

So, just because of that, this feature is impossible to be made reliable in the general use case of mass distributed software.

Even if that was not a problem, remember that there was a second condition I explained: you need to have the same Akeeba Backup version. This is not just idle speculation. The structure of both tables (schema) is not set in stone. It evolves over time. It does not change often, but it does change. For example, in the last 5 years we renamed #__ak_stats to #__akeebabackup_backups and added the frozen and instep fields to it. Moreover, the #__ak_profiles table was renamed to #__akeebabackup_profiles and the quickicon field was added. If there is a mismatch between the expected table structure and the actual structure in the database you will have all sorts of problems, from a few warnings in the interface to being unable to access your site due to SQL errors in the plugins which come with Akeeba Backup.

Ensuring that there is no version mismatch between the backed up data and the database data is a hard, but solvable problem, but it can only have one result: disable this feature if a mismatch was detected. Our experience says that even people who are not interested in this feature would come here to ask why this feature is disabled, which is a major waste of time for both parties involved. Considering the dearth of use cases where this feature would actually be useful it sounds like implementing it would be a colossal waste of time.

Finally, if someone chose to merely not restore these tables but restored into a database which completely lacks those tables they would end up with a broken Akeeba Backup installation. Even worse, this would prevent them from accessing their site due to SQL errors caused by the plugins shipped with Akeeba Backup, preventing them from repairing their installation.

Therefore, we conclude that in the general mass distributed software use case this feature would cause far more problems than it solves. Moreover, we know from experience (remember that I've written and been maintaining this software for 18 years) that your use case is already addressed by other existing features, and nobody before you had an issue using them. So, it sounds like there would be a lot of time spent in development and support of a feature that nobody actually needs except one person, making it a horrible candidate for a software feature in general, and a seriously bad business decision if we want to be absolutely frank to each other. As a result, this feature cannot and will not be implemented.

Kindly note that there are many more features in Akeeba Backup and/or as part of your Professional subscription which can be used to achieve something similar:

• You can skip the table from being backed up. Possible since 2007.
• You can skip the table from being restored. Possible since 2019. This is the solution I recommend, as long as you ensure the two conditions I outlined which will take you all of one minute a month at worst.
• You can export and import backup profiles through the interface.
• You can export, import, and reconfigure backup profiles using CLI commands, which means the process can be automated.
• You can automate restoration with UNiTE (which means the rule about skipping tables can be automated), and it can also run arbitrary SQL files if you so wish.

Personally, I use the last two solutions. I use UNiTE to restore the backup archive of our live site to the development server, having it run arbitrary SQL commands to anonymise all personally identifiable information. The restoration shell script uses Akeeba Backup CLI commands to reconfigure the existing backup profiles, changing their output directory, and imports another backup profile which takes backup to a special location I have for the dev site's backup only. I also do some other things (import the latest backup from the remote storage before restoration, and post-restoration linking to the development versions of our software and the site's template) to make it easier to develop on that site, but that's beyond the point. The whole idea is that I put the effort once and now I run restore_akeeba_site to have everything execute in the time it takes me to walk to the kitchen and make myself a coffee.

Everyone else who had a similar use case to yours has found a process using one or more of the aforementioned features which works for them. The easiest is what Davide told you, using relative output directories and making sure the relative path is valid on both the live and the development server. This is what I used before we implemented CLI commands for Akeeba Backup. My output folder was [SITEROOT]/something and I made sure that the something folder existed in both the live and development server under the site's root.

The alternative I gave you follows exactly your proposal for a feature, but I am not tremendously fond of it. It has a fairly big margin of failure. It's a matter of time before you restore on top of the wrong version of Akeeba Backup and end up with a restored site which appears broken. What I would do if I did not want to use any kind of automation would be having different backup profiles for the live and development site, neither of which would be profile #1. This way I would be able to restore the site as-is and just switch to the correct profile depending on whether I am on the live or dev site. Further to that, I would use a different backend template style with a different primary colour to visually remind me which site I am working on. This reduces the number of post-restoration steps to a dead simple one: change the default backend template style. This is something I am using during development, when doing back-to-back restorations which require me to have both the original and the restored site's backends open at the same time.

In any case, what you asked is already possible with an existing feature of the restoration script, so I am going to close this ticket.