Support

UNiTE, Remote CLI, eXtract Wizard

#33456 – Akeeba restoration command

Posted in ‘UNiTE, Remote CLI, eXtract Wizard’
This is a public ticket. Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.
Saturday, 25 July 2020 07:52 CDT
prosys

Dears 

kindly note that i have a problem with running  Akeeba unite tool that is not working  and gives me this result only 

ErrorImageURL

and please note i use Below Command And XML,

please Advice me what to do.

thanks,

 

note :

command on root dir As Below:

/usr/local/bin/php-cli /home/nginx/domains/addustour.com/private/unite-package-4.0.4/unite.phar /home/nginx/domains/addustour.com/private/unite-package-4.0.4/site.xml

please note that the XML filled As Below:

<?xml version="1.0" encoding="UTF-8"?>
<unite scripting="02_angie">
<siteInfo>
<package from="site"></package>
<deletePackage>0</deletePackage>
<localLog>test.log</localLog>
<emailSysop>0</emailSysop>
<name>bak.addustour</name>
<email>[email protected]<;/email>
<absolutepath>/home/nginx/domains/addustour.com/private/unite-package-4.0.4</absolutepath>
<homeurl>undefined
<livesite>undefined

<jpspassword><![CDATA[xxxxx]]></jpspassword>

<ftphost>51.15.16.3</ftphost>
<ftpport>21</ftpport>
<ftpuser>addustour</ftpuser>
<ftppass>xxxx</ftppass>
<ftpdir>/public</ftpdir>
<adminID>1</adminID>
<adminUser>root</adminUser>
<adminPassword><![CDATA[xxxxxxxx]]></adminPassword>
</siteInfo>
<databaseInfo>
<database name="addustour">
<changecollation>0</changecollation>
<dbdriver>mysqli</dbdriver>
<dbhost>localhost</dbhost>
<dbuser>addustour</dbuser>
<dbpass>xxxxxxx</dbpass>
<dbname>addustour</dbname>
<dbprefix>joos_</dbprefix>
</database>
</databaseInfo>

<postrun>
<emailto>[email protected]<;/emailto>
<emailsubject>Restoration complete</emailsubject>
<emailbody><![CDATA[
Addustour Restoration complete
]]></emailbody>
</postrun>
</unite>

Custom Fields

Which tool do you want support for? akeeba unite
Tool version (in x.y.z format) 4.0.4
 
Monday, 27 July 2020 01:49 CDT
nicholas

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.



Nicholas K. Dionysopoulos

Lead Developer and Director



🇬🇷Greek: native

🇬🇧English: excellent

🇫🇷French: basic



Please keep in mind my timezone and cultural differences when reading my replies. Thank you!



Monday, 27 July 2020 05:13 CDT
prosys

Dear support ,

thank for your assistance , i foolow your instructions and unforgettably i have no result! 

so, I attached here  2 files , one  for UNITE service run log.txt its details about command and log , and other file for WordPress XML-configuration.

Please advise us a.s.a.p. what to do.

Thanks for your support.

 
Monday, 27 July 2020 08:06 CDT
nicholas

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?



Nicholas K. Dionysopoulos

Lead Developer and Director



🇬🇷Greek: native

🇬🇧English: excellent

🇫🇷French: basic



Please keep in mind my timezone and cultural differences when reading my replies. Thank you!



Monday, 27 July 2020 08:40 CDT
prosys

  Dear nicholas,

Thanks for your great support,
i didnt found wp-config.php with the extracted archive in our restoration server.
i have found this file wp-config.php in my original server website under this path /home/nginx/domains/akeeba.example.com/public
and also note that i dont have all this folder in restoration server: /home/nginx/domains/akeeba.example.com/

do i have to copy this file from original server to restoration server to same location or does it have a some kind of installation on restoration server?
please advice,

 
Monday, 27 July 2020 10:06 CDT
nicholas

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?



Nicholas K. Dionysopoulos

Lead Developer and Director



🇬🇷Greek: native

🇬🇧English: excellent

🇫🇷French: basic



Please keep in mind my timezone and cultural differences when reading my replies. Thank you!



Monday, 27 July 2020 10:29 CDT
prosys

Dear nicholas,

 

Kindly note that the backup was created using this tool:

Akeeba Backup CORE for WordPress  Version 3.0.1

 

and this is the command for cron job (for creating backup on original server):

0 2,13,19 * * * /usr/local/bin/php /home/nginx/domains/akeeba.Example.com/public/wp-content/plugins/akeebabackupwp/app/cli/backup.php > /dev/null 2>&1

 

Note i used the same file backup.php that provided from Akeeba backup Core for wordpress

please Advice

 

Thanks

 
Monday, 27 July 2020 13:10 CDT
nicholas

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.



Nicholas K. Dionysopoulos

Lead Developer and Director



🇬🇷Greek: native

🇬🇧English: excellent

🇫🇷French: basic



Please keep in mind my timezone and cultural differences when reading my replies. Thank you!



Tuesday, 28 July 2020 14:22 CDT
prosys

 

Dear NICHLAS ,
Thanks for your support.

Please find my answers Of each your enquirers in bellow:

ـ 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).

Answer  : WE USE Ols akeeba backup version ,   BECOUSE OUR PHP VER  is old ver  PHP5.6

ـ 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. There are exactly three reasons why this file might not be present in the backup archive:

-The file  wp-config.php is already EXISTS  in site's root.
Answer : YES

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

Answer : NO


-The file or its containing folder is unreadable.

Answer : NO 

Please advise ,

Thanks 

 
Wednesday, 29 July 2020 00:27 CDT
nicholas

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.



Nicholas K. Dionysopoulos

Lead Developer and Director



🇬🇷Greek: native

🇬🇧English: excellent

🇫🇷French: basic



Please keep in mind my timezone and cultural differences when reading my replies. Thank you!



Wednesday, 29 July 2020 03:41 CDT
nicholas

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.



Nicholas K. Dionysopoulos

Lead Developer and Director



🇬🇷Greek: native

🇬🇧English: excellent

🇫🇷French: basic



Please keep in mind my timezone and cultural differences when reading my replies. Thank you!



Friday, 28 August 2020 17:17 CDT
system
This ticket has been automatically closed. All tickets which have been inactive for a long time are automatically closed. If you believe that this ticket was closed in error, please contact us.
This ticket is closed, therefore read-only. You can no longer reply to it. If you need to provide more information, please open a new ticket and mention this ticket's number.

Support Information

Working hours: Typically we work Monday to Friday, 9am to 7pm Cyprus timezone (EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets, but we cannot respond to them, outside of our working hours.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!