Helllooo.
Really strange error, I restored hestiacp backup to new server and any wordpress installation have the same error: wp-admin/install.php
Any idea?
Here anothe same problem,
WordPress Redirecting to wp-admin/install.php
deleting any restored website and reinstall from akeeba backup for wordpress, any website works correctly on the new server! why this happen? I don’t see any errors in the logs
I dont use wordpress but will play along. what logs did you check ?
What versions of Hestia are on the old server and the new one ?
What os was on the old server and the new one ?
What database server did you use on the old server and the new one ?
what databases are listed on the new server and how did you find this out ?
What credentials did you use to access the new database and the old one ?
Did you use apache on the old and on the new server or not ?
what apache modules are active on the old server and the new one ?
you state hestia back and then later akeeba backup. describe exactly how you backed up and restored your system
do you still have access to the old system ? does it work ? why did you upgrade ?
Good luck. You were not providing enough information for anyone to determine if this is a hestia problem, a wordpress problem or something else.
check wp-config.php db user and password is correct.
Have the same problem - new HestiaCP server, full restore of user and all files, settings, databases, etc. Everything matches compared to old and new server but still all WordPress installations are redirected to wp-admin/install.php
User name, database and passwords are correct (as they are restored…). Why? Anyone?
When you restore a user on another server the DB name might change if the username changed. If that is the case you have to update the wp-config.php with the new DB name and user
The redirection is coming from Wordpress not from HestiaCP. Mostly because of DB issues. Check your database table prefix.
Thanks for the tips. The problem is not access to the database, that works but the databases have NO tables after restore. The size hasn’t changed according to HestiaCP under DB tab, but there’s nothing in it!
I use rclone to store my backups, with ztd compression. When I restore, I see this in the terminal:
v-restore-user user user.2024-08-23_11-45-17.tar 'no' 'no' 'no' '' 'no' 'no'
-- DB --
2024-08-23 11:49:40 user_20465
/backup/tmp.RwsTRyHF7K/db/user_20465/user_20465.mysql.sql.zst: 104290249 bytes
2024-08-23 11:49:41 user_210520
/backup/tmp.RwsTRyHF7K/db/user_210520/user_210520.mysql.sql.zst: 20043538 bytes
2024-08-23 11:49:41 user_62745
/backup/tmp.RwsTRyHF7K/db/user_62745/user_62745.mysql.sql.zst: 756041 bytes
2024-08-23 11:49:42 user_94926
/backup/tmp.RwsTRyHF7K/db/user_94926/user_94926.mysql.sql.zst: 54619 bytes
Using zip, I see this when I restore:
v-restore-user user user.2024-08-23_11-56-00.tar 'no' 'no' 'no' '' 'no' 'no'
-- DB --
2024-08-23 11:57:00 user_20465
2024-08-23 11:57:01 user_210520
2024-08-23 11:57:02 user_62745
2024-08-23 11:57:02 user_94926
2024-08-23 11:57:03 user_23232
So I thought that the restore went well (the .sql files are all correct and populated). But: according to phpMyAdmin, NO tables exist.
I can’t see the sql files decompressing in that output.
Could you please check whether zstd is installed?
dpkg -l | grep zstd
type pzstd
If it isn’t installed, install it and try again:
apt install zstd
If it is installed execute the command using bash debug and share the output:
bash -t /usr/local/hestia/bin/v-restore-user user user.2024-08-23_11-56-00.tar 'no' 'no' 'no' '' 'no' 'no' | tee /tmp/v-restore-output
As the output will be large, you can use this to share it (paste the url that you will get):
cat /tmp/restore-output | nc termbin.com 9999
**dpkg -l | grep zstd**
type pzstd
ii libzstd1:amd64 1.5.4+dfsg2-5 amd64 fast lossless compression algorithm
ii zstd 1.5.4+dfsg2-5 amd64 fast lossless compression algorithm -- CLI tool
pzstd is /usr/bin/pzstd
Output is available here: https://termbin.com/removed
Thank you!
I see no apparent problem and your db is being imported:
import_mysql_database /backup/tmp.940wanzAQm/db/user_20465/user_20465.mysql.sql
So if the data is not in the tables the import must be failing.
First, check whether there is data in the db:
mysql -uroot -e 'select user,host from mysql.user where user = "user_20465";'
mysql -uroot -B -N -e 'SHOW DATABASES;' | grep user_20465
mysql -uroot -B -N -D user_20465 -e 'show tables;'
If the last command show the tables, check if there is content in one of the tables (replace 5g38U_users with the actual name of one of your tables):
mysql -uroot -B -N -D user_20465 -e 'select * from 5g38U_users;'
If you can’t see the data:
cd /usr/local/hestia/func/
cp rebuild.sh rebuild.sh.backup
sed -Ei 's/(mariadb -h.*DB.*1)( >.*1$)/\1/' rebuild.sh
And now, try to restore again and you should see if there are errors importing the sql files:
v-restore-user user user.2024-08-23_11-56-00.tar 'no' 'no' 'no' '' 'no' 'no'
Edit: If you see nothing even after doing the changes to rebuild.sh do this and restore again:
cd /usr/local/hestia/func/
sed -Ei 's/mariadb -h/mariadb -v -h/' rebuild.sh
Thank you! The command
sed -Ei 's/(mariadb -h.*DB.*1)( >.*1$)/\1/' rebuild.sh
gives an error when restoring:
> 2024-08-23 15:06:08 user_20465
>
> /backup/tmp.BylLhZt1kA/db/user_20465/user_20465.mysql.sql.zst: 104288356 bytes
>
> ERROR at line 1: Unknown command '\-'.
edit: Unpacking the backup and importing the .sql file manually works without errors. But I want to move more then 58 sites so the restore function is quite desirable.
I can’t replicate the problem using my backups.
Could you please extract the sql file and show the first lines? Also, if there are lines with these characters \-
mkdir /tmp/test_sql
tar xvf /backup/user.2024-08-23_11-56-00.tar ./db/user_20465/user_20465.mysql.sql.zst -C /tmp/test_sql
cd /tmp/test_sql/db/user_20465
pzstd -d user_20465.mysql.sql.zst
grep -E '\\-' user_20465.mysql.sql
head -50 user_20465.mysql.sql
First lines:
/*!999999\- enable the sandbox mode */
-- MariaDB dump 10.19 Distrib 10.5.25-MariaDB, for debian-linux-gnu (x86_64)
--
-- Host: localhost Database: user_20465
-- ------------------------------------------------------
-- Server version 10.5.25-MariaDB-deb11-log
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8mb4 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;
/tmp/test_sql # grep -E '\\-' user_20465.mysql.sql
/*!999999\- enable the sandbox mode */
Crap. So it’s the first line, which is also mentioned here?
if you are using the same mariadb version or newer it should nit matter but we should patch the issue
Seems so, a compatibility issue between mariadb-dump versions.
What’s the mariadb-dump version in the server where you are trying to restore?
mariadb-dump -V
You could try this fix.
Edit /usr/local/hestia/func/rebuild.sh and replace this line:
mariadb -v -h $HOST -u $USER -p$PASSWORD $DB < $1
by
tail -n +2 $1 | mariadb -v -h $HOST -u $USER -p$PASSWORD $DB
and try to restore again.
Source:
mariadb-dump Ver 10.19 Distrib 10.5.25-MariaDB, for debian-linux-gnu (x86_64)
Destination:
mariadb-dump Ver 10.19 Distrib 10.11.6-MariaDB, for debian-linux-gnu (x86_64)
Trying restore now after modification of rebuild.sh
-edit- Works!!
Thank you for your help!
1 Like
That seems the problem, old version 10.5.25 has the change applied but 10.11.6 doesn’t (the change has been applied on version 10.11.8).
Great 
You are welcome.
I’ve upgrade the mariadb-10.11.6 installation to 10.11.9 using this page Download MariaDB Server - MariaDB.org on my Debian 12 server, restored the rebuild.sh script and now a restore from backup works fine! Cheers @sahsanu !
1 Like