Error when trying to migrate to new server

Well, I have a server that is running a very old OS and I have another server that is running a recent os. I did a backup to a local directory on the old server, rsync’ed the backup files to the new server and restored them. I’m on a pretty slow network so it didn’t make sense to try to get them to my local machine and then transfer them to the new server. Better to copy system to system. They were fairly large files.

1 Like

Yes! I find that strange, but it worked.
Thanks,
Jim.

I think gomez_Adams was confused by your ambiguous use of ‘rsync’ and ‘the files’. It sounded like you were doing both the backup and rsync of the directories.

Using rsync to copy files is perfectly fine of course, but unnecessary (could just use scp) because there is nothing to actually sync.

I was confused / interpreted it the same way at first.

Indeed, I just did a migration like you, but did include an rsync of the directories after I had stopped postfix on the source (old) machine (and before starting on the new) so that I wouldn’t miss a single email in the migration.

You could do this by having postfix shut off (on both machines) during the whole migration, but it was substantially less downtime to rsync the dirs after backing up and transferring the domains.

1 Like

OK I see your point. Since there were no files on the destination, using rsync didn’t waste any time but I do sometimes use rsync when I should use scp. I’m guilty of that. The mail users on the system are very quiet. Sometimes weeks go by with no mail other than spam so I wasn’t too worried about losing anything.
Thanks for the clarification.
Jim.

Exactly what I thought.

@Jamie if Virtualmin backup feature can create tar.bz2 formats, then it should recognize it upon restore. It would be better to return an exact error message, in case something goes wrong, rather than a static message as $text{'restore_etar'}.

@gnulabs Failed to read backup file : /root/migback//swedmr.se.tar.bz2 : Not a valid tar or tar.gz file

Have you simply tried renaming the file to .tar.gz and trying again? Besides, what happens, if on the target server you try to manually extract in console as:

tar -xf swedmr.se.tar.bz2

… does it work?

I think that error message is a bit misleading - it should say “not a valid tar , tar.gz or tar.bz2 file”

Make sure you have the bunzip2 command installed on the destination system.

This is what I meant by saying “return exact error message”. :slightly_smiling_face: If command isn’t installed, it should say so.

He wasn’t using the gui to create and restore it. He used command line and specified to restore a tar.gz in a location where only a tar.bz2 existed, hence his error.

Which is why I asked all along: why wouldn’t you just use the gui and let it take care of everything automatically?

Everybody is so hung up on command line that they don’t realize you have to be specific in what you’re doing there. If you tell the command line to restore a tar.gz file in a location and there isn’t anything in there but a tar.bz2 it is not going to work.

Same problem with the GUI so…

The underlying library that is used, is the same for both CLI and GUI.

@gnulabs

Could you simply try renaming the file to .tar.gz and see what it does? Besides, what happens, if on the target server you try to manually extract it using a console, as:

tar -xf swedmr.se.tar.bz2

… does it work?

There is a limit to how large a file you can upload via the GUI. I found that out when restoring a ~33GB backup to my AlmaLinux test server. rsync (or better yet, SCP) have no such limits.

Richard

I have no issues with decompressing when using --compression zip… The errors I see now is the maradb errors

//Johan

I have taken a closer look and I could not restore your backup on my Debian 10 instance too, getting MariaDB error:

Restore failed : SQL set password for 'user_name'@'127.0.0.1' = failed : You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '' at line 1

I think I have an idea why this might be happening.

First, do you have an option for passwords hashing enabled in Virtualmin?

Seconds, how do your password for this database user look like exactly (you can post it to our private chat). I think it’s some sort of escaping issue. This information would help to understand what exactly is happening.

Again, a backup I made on my Ubuntu 20.04 restored just fine on Debian 10 without such issues.

Where do you check virtual hash? And I guess you mean in orginating system?

//JOhan

This is usually done upon post-install wizard but also can be changed later from templates:

It can be manually checked in Virtualmin domain config file (located at /etc/webmin/virtual-server/domains/ directory) searching for hashpass param.

How large the database that is being restored?

If you login as root to MariaDB (on target system) using command:

mysql -u root -p

and run

SHOW VARIABLES LIKE 'max_allowed_packet';

What output do you get?

If it’s too small (equals to 1M) could you go to Servers ⇾ MySQL Database Server: MySQL Server Configuration page and change maximum packet size to let’s say 256M:

… and see if that changes anything? I know that the error message doesn’t state that this is the cause of the problem but just to be sure?

We will look into your issue as soon as we can. We’ve been busy with other buy fixes recently. Sorry for a delay!

since it appears to be the same as my issue I’ve tested some of the proposed fixes here. I have all hash types enabled, and the max_allowed_packet size did not fix the issue.

It could be an escaping issue because the password for one account that’s failing includes characters like: @}^!=

I added print statements to view them before the call to execute_user_creation_sql and it looks like $pass and $encpass are empty when passed into create_mysql_database_user.

1 Like

This is helpful. Thank you. We will look into it!

I tried to restore all other domains and they work fine… Just the hflink.com that fails

//Johan