Support

Hello,

we'd need more info about it and the error you got.

Please note that Akeeba Solo will only take care of creating a backup and move the files to the new location. When you're there you will have to configure your Prestashop installation to use the new values for new server. For example: https://classydevs.com/move-prestashop-from-localhost-to-server/

If Akeeba Solo don´t manage backup and restoration why it allows to do it.

I don't appreciate the allegation here. I understand you brought down production, but this feeble attempt at pawning off your responsibility to the software you used incorrectly does not exactly make you look stellar in your job.

Akeeba Solo does back up all your files and database contents. If it runs into a problem doing that, it tells you (warnings). If you tell it to do something else, it will do whatever you told it to do. I cannot tell you what it did and did not back up because the log file link is behind a login I do not have.

Akeeba Solo can reconfigure Joomla and WordPress upon restoration. For everything else, it provides the ANGIE For Miscellaneous PHP Applications installer which DOES NOT reconfigure the site upon restoration as explicitly stated in https://www.akeeba.com/documentation/akeeba-solo/angie-misc-setup.html.

To make this crystal clear: Solo cannot reconfigure software backed up and restored using the Miscellaneous PHP Applications installer. Since you changed your database password (it's different than what it was when you backed up your site) you need to change PrestaShop's configuration by hand. This is in the documentation and it was correctly diagnosed by Davide above, who also gave you a link to third party instructions which address this. It is step 5 in the link Davide already gave you above (https://classydevs.com/move-prestashop-from-localhost-to-server/).

We had an issue with the password of the database user in the first try. Apparently has characters not allowed. So we change the ftp user and set an easier password.

The problem you had with your database password IS NOT a limitation in Akeeba Solo or its restoration script and this was made perfectly clear to you in the message which reads:

Your database password contains special characters. Many web servers reject or modify these passwords, causing the database restoration to fail with a database connection error.

The problem is that some hosts enable the Apache mod_security2 module with the default OWASP Atomic ruleset. Certain combinations of punctuation and special characters trigger a false positive in one of these rules, preventing the form from submitting (the server typically returns an HTTP 403 Forbidden error). The correct but hard solution is to disable the rule which throws the false positive. The easy, temporary workaround is to change the database user's password. However, by doing so, you have necessitated changing your software's configuration with the new database connection information.

PrestaShop's documentation on the matter is scant but it does tell you that the database connection information is in /app/config/parameters.php as per Davide's information to you.

If this is still not clear, see https://presta.site/blog/en/how-to-change-database-connection-settings-in-prestashop/ which tells you the same.

You need to change the database connection information.

Next time be more prepared. Remember what I have written in the documentation:

Test your backups periodically. Maybe you excluded a database table you didn't mean to. Maybe a folder was unreadable but you ignored the warning. Maybe the FTP program you are using to download your backups is broken. Maybe you accidentally set the temp-directory or logs file directory of your site to your site's root or another important system folder, ending up excluding it automatically in the process. Maybe there was a bug in the version of Akeeba Solo or Akeeba Backup you were using, it created a corrupt archive and you didn't update to the next version that fixed it (it happens once every 3-4 years, we usually fix the issue within 24 hours). No matter what happened, a corrupt backup can ruin your day. Test your backups periodically to make sure that they actually work.

https://www.akeeba.com/documentation/akeeba-solo/restoring-backups.html#general-guidelines

This is not something unique to our backup software. This is a universal truth applicable to ALL backup solutions. There are three rules about backups which have been true ever since the advent of generic computers in the 1950s:

1. Backups must always follow the 3-2-1 rule (there must be 3 copies of the data, on 2 different media, 1 being off-site), and they must be tested. You don't want to find out that your last backup was wiped out when you need it the most.
2. Backups must be tested. The last place and time you want to familiarise yourself with the restoration procedure and troubleshoot restoration issues is in production, when production is down.
3. You'd better get used to the first two rules. These rules require you to put time and resources into the problem, but following them will prevent career-limiting events.

Ask any serious sysadmin anywhere and they will tell you the same.