Trouble Migrating

[AcidUK]

Hello,

I am in the process of moving over 10-20 sites to a new dedicated server. I have set vestacp up in the same way (as per the documentation).

I can export users to a backup file, however when I transfer this to the new machine and try to v-restore-user, it is complaining that the tar file is not valid. I have checked the archive, and it is intact, and contains files in an appropriate structure.

I have tried this with the admin account, but also with a user account (both before and after manually creating the account.

I would be grateful for any advice.

Here is the process I have been trying and the error messages:

On original box

Code: Select all

v-backup-user <username>
-- SYSTEM --
2014-07-05 19:30:35 <username>.conf
2014-07-05 19:30:35 stats.log
2014-07-05 19:30:35 history.log
2014-07-05 19:30:35 pam

-- WEB --
2014-07-05 19:30:35 <website>
2014-07-05 19:30:39 <website>
2014-07-05 19:30:39 <website>
2014-07-05 19:30:40 <website>
2014-07-05 19:30:40 <website>
2014-07-05 19:30:41 <website>
2014-07-05 19:31:00 *** 6 domains ***

-- DNS --
2014-07-05 19:31:00 <domain>
2014-07-05 19:31:00 <domain>
2014-07-05 19:31:00 *** 2 domains ***

-- MAIL --
2014-07-05 19:31:01 *** 0 domains ***

-- DB --
2014-07-05 19:31:01 <db> (mysql)
2014-07-05 19:31:01 <db> (mysql)
2014-07-05 19:31:01 *** 2 databases ***

-- CRON --
2014-07-05 19:31:02 *** 0 jobs ***

-- User Dir --
2014-07-05 19:31:02 adding directory tmp
2014-07-05 19:31:02 *** 1 user directory ***

-- SUMMARY --
2014-07-05 19:31:02 Local: /backup/<username>.2014-07-05.tar
2014-07-05 19:31:03 Size: 274 Mb
2014-07-05 19:31:03 Runtime: 1 minute

root@<original>:/home/backup# scp /backup/<username>.2014-07-05.tar <user>@<remotehost>:/home/backup/
<user>@<new>'s password:
<username>.2014-07-05.tar                        100%  273MB  10.5MB/s   00:26

On newbox

Code: Select all

root@<newbox>:/home/backup# v-restore-user <username> /home/acid/<username>.2014-07-05.tar
Error: backup /home/backup/<username>.2014-07-05.tar is not valid

root@<new>:/home# tar tfv /home/backup/torsweb.2014-07-05.tar | head -n 10
drwx------ root/root         0 2014-07-05 19:31 ./
drwxr-xr-x root/root         0 2014-07-05 19:31 ./db/
drwxr-xr-x root/root         0 2014-07-05 19:31 ./db/<site>/
drwxr-xr-x root/root         0 2014-07-05 19:31 ./db/<site>/conf/
-rw-r--r-- root/root       178 2014-07-05 19:31 ./db/<site>/conf/<site>.mysql.<site>
drwxr-xr-x root/root         0 2014-07-05 19:31 ./db/<site>/vesta/
-rw-r--r-- root/root       200 2014-07-05 19:31 ./db/<site>/vesta/db.conf
-rw-r--r-- root/root    593714 2014-07-05 19:31 ./db/<site>/<site>.mysql.sql.gz
drwxr-xr-x root/root         0 2014-07-05 19:31 ./db/<site>/
drwxr-xr-x root/root         0 2014-07-05 19:31 ./db/<site>/conf/

Many thanks for any ideas!

[imperio]

Hi,
on your old server, you was used vestacp?

[AcidUK]

Yes, it was installed on version 7 or 8 of vestacp, and updated to 9 without errors the day before I attempted this migration. Both are running ubuntu, the older box may be a version of ubuntu behind (13).

The only other thing I can think of is that the older machine had only one core and 2gb of ram, while the new one significantly more powerful, which I know changes what the installer does It's there any way for me to find out what the new box is rejecting the archive based on? E.g. verbose or debugging output?

P.s, thank you very much for your help and your amazing product! I have been evangelising its simplicity and ease of setup to everyone who will listen. We used to use ispconfig, but this is miles beyond out on terms of usability.

[AcidUK]

Solved.

I went through the v-restore-user script, and noted the 'check' condition for the archive - the file must be in the /home/backup/ directory. I had it in my user directory (although was issuing commands from root). I did this because I had transferred the file with scp, and I had not yet set up ssh key access for the new machine for root.

I corrected the problem by moving the backup archive to /home/backup.

Excellent. Thank you for your awesome software!

[AcidUK]

Just another quick update in case anyone else comes across this issue, there was more to it. While this worked for the first user I tried to restore, I had the same error for the second. I had to create the user manually on the new system (without any sites), run the backup, and then replace the created backup file before attempting the restore. I do not know if all of this was necessary, but this allowed me then to successfully restore the backup. I hope this helps someone!

[xZero]

I have exactly the same issue. I running latest VestaCP on old Debian 7.8 Server and same on new Debian 8.2 server.
Archive is created on old server and afterwards whole /home/backup transferred using SCP to new server /home/backup.

cat /var/log/vesta/error.log :

Code: Select all

2015-12-05 16:13:04 v-restore-user 'username' '/home/backup/username.2015-12-05.tar' [Error 2]

OP solution unfortunately doesn't work in my case. Any help?

[imperio]

Code: Select all

v-restore-user username username.2015-12-05.tar

[xZero]

Code: Select all

root@debian:/home/backup# v-restore-user network network.2015-12-05.tar
Error: backup doesn't exist
root@debian:/home/backup# v-restore-user network /home/backup/network.2015-12-05.tar
Error: backup /home/backup/network.2015-12-05.tar is not valid

First response is rather weird - I'm right in the /home/backup directory.

Code: Select all

root@debian:/home/backup# ls -l network.2015-12-05.tar
-rw-r----- 1 root root 57528320 Dec  5 16:12 network.2015-12-05.tar
root@debian:/home/backup# file network.2015-12-05.tar
network.2015-12-05.tar: POSIX tar archive (GNU)

Almost all my public_html directories are actual symlinks whose leads to another directory-es (exists in new system). Can that be cause of issue?

[xZero]

So no more help I guess?

[rsearle]

Looking at the Vesta code, I found:

/usr/local/vesta/func/main.sh line 6:

Code: Select all

BACKUP='/backup'

... and /usr/local/vesta/bin/v-restore-user lines 39-46:

Code: Select all

# Check backup function
is_backup_valid() {
    if [ ! -e "$BACKUP/$backup" ]; then
        echo "Error: backup doesn't exist"
        log_event "$E_NOTEXIST" "$EVENT"
        exit $E_NOTEXIST
    fi
}

... so at line 41, the backup file is not found, because by default it is expected at /backup/$backup, NOT /home/backup/$backup.

I fixed this by changing /usr/local/vesta/func/main.sh line 6 to:

Code: Select all

BACKUP='/home/backup'

And then the user restore worked fine.

The error about 'backup ... is not valid', appears to relate to format checking of the $backup parameter string. It looks like it doesn't like punctuation or path delimiters or something. I didn't have to nail this problem, because the fix to main.sh worked for me.

Cheers,

Russell Searle
Psicom