Support

You do not get an error (yet). You get the non-verbose result of running UNiTE with this XML file. You need to use the --verbose --debug=1 switches in the command line to see where the problems are.

I can see by a quick glance that your XML file is both malformed and has sections which do not make sense. This line is wrong, it means nothing:

<package from="site"></package>

As you can read in our documentation, the only valid value for the from attribute is "remote" if you want UNiTE to perform a remote backup and download the resulting backup archive. There is no such thing as from="site". The correct form is something like:

<package>your_backup_archive_name.jpa</package>

which tells UNiTE to use a file already present in the same folder as its XML configuration file.

The following line is wrong

<email>[email protected]<;/email>

The semicolon makes it invalid XML. It should read:

<email>[email protected]</email>

The following two lines are invalid XML as well:

<homeurl>undefined
<livesite>undefined

The correct approach is to NOT include them if they are not meant to have values. That said, I believe you got these lines by pasting URLs to our site's editor and your XML file does not look like that.

All the FTP keys you have set, they are not used to retrieve the backup archive. They are used to set up Joomla's FTP layer. So I'm pretty sure you don't want them to be there either.

The following line is also wrong (random semicolons):

<emailto>[email protected]<;/emailto>

It should read

<emailto>[email protected]</emailto>

Now, if I am guessing correctly, what you want to do is retrieve the latest backup from your server over FTP and restore it with UNiTE. UNiTE cannot retrieve the latest backup. You can either use the ftp command line client or Akeeba Remote CLI. In both cases you need a shell script.

Here is a sample script which uses Akeeba Remote CLI and UNiTE (plus the standard sed, awk and tr Linux commands) to find the latest backup on a site, download it, change UNiTE's XML configuration file to reference this downloaded file and run UNiTE to restore it. All you need is a valid UNiTE XML configuration file and editing the script file's Configuration section. Do remember to enable the JSON API on your site for this script to work.

#!/usr/bin/env/bash

########## Configuration ##########
# The URL to your site. No trailing slash
SITE_URL=https://www.example.com
# Your site's Secret Key
SITE_SECRET=my-really-very-secret-key
# The name of the UNiTE XML file you will use to restore the downloaded file
RESTORATION_XML=site.xml

########## DO NOT EDIT BELOW THIS LINE ##########

# Get the latest backup ID
LATEST_BACKUP_ID=`php remote.phar --from=0 --to=0 listbackups -m --host=$SITE_URL --secret=$SITE_SECRET | tail -n 1 | awk -F'|' '{printf "%s", $2}' | tr -d "[:space:]"`

[[ -z "$LATEST_BACKUP_ID" ]] && exit 127

# Download the latest backup using HTTP
CURDIR=`pwd`
DOWNLOADED_FILE=`php remote.phar download -m --id=$LATEST_BACKUP_ID --dlmode=http --dlpath=$CURDIR --host=$SITE_URL --secret=$SITE_SECRET | grep INFO | awk -F'|' '{printf "%s", $2}' | awk -F' ' '{printf "%s", $3}'`

[[ -z "$DOWNLOADED_FILE" ]] && exit 128

# Update the XML file with the name of the downloaded file
sed "s/<package>.*<\/package>/<package>$DOWNLOADED_FILE<\/package>/" site.xml -i

# Run UNiTE verbosely
php unite --verbose $RESTORATION_XML

You can save this as a shell script file e.g. download-and-restore.sh and change its permissions to 0755 e.g. chmod 0755 download-and-restore.sh. You can then run it directly or use it with CRON jobs.

Regarding cleaning up after itself, you should use <deletePackage>1</deletePackage> in your XML configuration file.

Remember, UNiTE is a tool in your toolchain. It is not a toolchain by itself. Granted, it has remote backup and download from S3 features but these date back to 2010 when there was no Akeeba Remote CLI and no easy to use Amazon S3 command line client. That's why I never added any more all-in-one features. There was no point. You can always combine the tools you have to do things that are impossible with a monolithic mega-tool.

Is the wp-config.php file included in your backup archive? Was it extracted in the site directory you specified in the XML file?

If not, does your site have a wp-config.php file in its site root to begin with?

No, this file needs to be included in the backup archive. You do not need and must not transfer it manually. Its presence in the backup archive is essential for restoring a WordPress site (this file gives us information about where the site used to be located in when it was backed up).

Have you excluded this file manually from the backup?

We have three separate issues here.

1. You have used Akeeba Backup Core for WordPress but you only have an Akeeba Solo subscription. Normally this disqualifies you from support. I am willing to look beside it anyway but do take care of issue #2 below.

2. The version of Akeeba Backup for WordPress you are using is really old, unsupported and incompatible with the current version of UNiTE. Please take a backup with the latest version of Akeeba Backup for WordPress or Akeeba Solo (in the 7.x version range).

3. You have still not answered my question about whether you have excluded the wp-config.php file from the backup. This is a critical piece of information without which I cannot help you. Let me explain why.

Your restoration fails because the wp-config.php file does not exist after the archive extraction is complete. This means that the file was not present in the backup archive. Regardless of using Akeeba Backup instead of Solo and an old version at that, this is NOT normal. This file is backed up by default. It needs to be backed up and extracted from the archive for the restoration to work.

There are exactly three reasons why this file might not be present in the backup archive:

a. The file does not exist. We've seen it in some managed WordPress hosts that's why this was the first thing I asked you to check. You told me it exists so I am no longer considering this a plausible reason. All of my answers henceforth are with the assumption that this file does exist in your site's root.

b. You excluded it yourself, e.g. using the Files and Directories Exclusion page in Akeeba Backup / Solo; or

c. The file or its containing folder is unreadable.

In the second case is an operator error which can be easily rectified. The latter case you need to check the ownership and permissions of the file.

So before I tell you to do something I need to know what is the most likely problem. If you excluded the file you can change something in the interface and take a new backup. If it's a file / folder readability issue you would need to contact your host.

Regarding your Akeeba Backup version. It is way too old. Akeeba Backup for WordPRess 3.0.1 was released in February 2018. I cannot provide any support for it, period. I already know it won't work with the version of UNiTE you are using. What is the point of trying to help you with something I already know is not possible because of changes in how UNiTE works over the years?

Also note that the last version of Akeeba Backup for WordPress supporting PHP 5.6 was version 3.6.1, released in October 2019. Please install Akeeba Backup for WordPress 3.6.1 on your site and take a new backup.

If you cannot restore the new backup please ZIP and attach the backup log file from the backup you are trying to restore.

Correction. The latest Akeeba Backup for WordPress version which supports PHP 5.6 is 7.1.4. We did not introduce a minimum PHP 7.1 requirement until version 7.2.0. So the version you are using is two and a half years out of date to what you should be using.