• Please be aware: Kaspersky Anti-Virus has been deprecated
    With the upgrade to Plesk Obsidian 18.0.64, "Kaspersky Anti-Virus for Servers" will be automatically removed from the servers it is installed on. We recommend that you migrate to Sophos Anti-Virus for Servers.
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Resolved Please help: neither migration nor backup restore is working :(

DReffects

Basic Pleskian
Server operating system version
AlmaLinux release 8.6 (Sky Tiger)
Plesk version and microupdate number
Version 18.0.45 Update #1
Hello There!
I urgently have to migrate two servers to a new one and am unable to use both the Plesk Migrator and a manual backup restore.

The Plesk migrator gets stuck with "

Code:
Failed to fetch basic information about resellers, clients and domains data from source servers
Cause: Command execution failed on the local server with non-zero exit code.
command: rsync -l --chmod=Fu=rw,Du=rwx,go= --timeout=30 -e 'ssh -i /usr/local/psa/var/modules/panel-migrator/sessions/20220720161015/ssh-keys/id_rsa.XX.XX.XX.81 -p 22 -o PasswordAuthentication=no -o StrictHostKeyChecking=no -o GSSAPIAuthentication=no' /usr/local/psa/var/modules/panel-migrator/sessions/20220720161015/agent-config.source.json [email protected]:/root/plesk_migrator/plesk_migrator-zpv14zvwlj7w57b4om0jvjzmvm4b3pgf/pmm_agent/config.json
exit code: 30
stdout:
stderr: [sender] io timeout after 30 seconds -- exiting
rsync error: timeout in data send/receive (code 30) at io.c(195) [sender=3.1.3]

That is a critical error, migration was stopped.

I've searched through the forums and tried the following:
  • Disabled SELinux ("setenforce 0")
  • Disabled iptables and plesk firewall
  • In /etc/ssh/sshd_config
    • UseDNS no
    • PermitRootLogin yes
    • PasswordAuthentication yes
Unfortunately without any luck :(

My next step was to create a domain based backup on the source server and manually added the subscription to the new server and then tried to restore from backup.

While there is no hard error during restore i get the following warning:
Code:
Execution of /usr/local/psa/admin/plib/api-cli/domain.php --update XXXXXX.com -guid cbf6f65f-aa47-4400-a524-2eb2ebef0fb7 -creation-date 2007-01-10 -description '' -hosting true -hst_type phys -do-not-apply-skeleton -ip XX.XX.XX.XX -www-root httpdocs -login XXXXXX_com -passwd '' -passwd_type sym -hard_quota 0B -shell /bin/false -ignore-nonexistent-options failed with return code 1.
Stderr is
An error occurred during domain update: An error occurred during changing of hosting settings: System user update is failed: Unable to execute usermng: usermng: /usr/sbin/usermod execution failed:
usermod: user XXXXX_com_cucbqd0z9x5 is currently used by process 48517
usermng: Unable to modify user: XXXXX_com_cucbqd0z9x5

Both E-Mail and Databases seem to be restored fully - but i am missing ALL website data, including the httpdocs directory. Therefor this process is stuck as well.

I've tried to disable all php handlers serverwide and also disable php before restoring from backup but i cannot get past this error message.

I both of this issues with both source servers.
Source 1 is a CentOS Linux 7.9.2009 (Core) running Plesk Obsidian Version 18.0.44 Update #3
Source 2 is a CentOS Linux 7.9.2009 (Core) running Plesk Obsidian Version 18.0.45

Destination Server is a AlmaLinux release 8.6 (Sky Tiger) deployed from a previous CentOS8 installation and is running Plesk Obsidian Version 18.0.45 Update #1

All help is HIGHLY appreciated!

♡ ♥❤​

 
Try setting "UserDNS no" in the ssh config file and restarting ssh on the source server.
 
Looks like there is poor network performance between the source and the target servers. Here are troubleshooting steps:

1. Connect to the target via SSH
2. Create a file in the target server:
Code:
# echo "PleskSupport" > /root/plesksupport.txt
3. Transfer the file from the target to the source server: (IP xxx.xxx.xxx.xxx is the source server)
Code:
# time scp /root/plesksupport.txt [email protected]:/root/plesksupport.txt
[email protected]'s password:
plesksupport.txt 100% 13 0.1KB/s 00:00
real 0m29.630s
user 0m0.023s
sys 0m0.022s
4. Transfer the file from the source to the target server:
Code:
# time scp [email protected]:/root/plesksupport.txt /root/plesksupport.txt
[email protected]'s password:
plesksupport.txt 100% 13 0.1KB/s 00:00
real 0m30.588s
user 0m0.022s
sys 0m0.020s

If so, the advice is simple - fix this poor network performance with your network administrator.
Alternatively, if the problem requires an urgent solution, it is better to contact Plesk Technical Support: https://support.plesk.com/hc/en-us/articles/213953025-How-to-get-support-directly-from-Plesk-
 
Try setting "UserDNS no" in the ssh config file and restarting ssh on the source server.
Tried that already, did unfortunately not help :(

Looks like there is poor network performance between the source and the target servers. Here are troubleshooting steps:
Thank you very much for your very detailed response.
Regular https transfer speeds between the two sites are excellent - i can transfer at around 300mbit in either direction.

Here are the results of the scp test:

executed on target - transfer TO source FROM target:
Code:
plesksupport.txt                                                                                                                                          100%   13     0.6KB/s   00:00

real    0m6,330s
user    0m0,008s
sys     0m0,006s

executed on target - transfer FROM source TO target:

Code:
plesksupport.txt                                                                                                                                          100%   13     0.6KB/s   00:00

real    0m11,493s
user    0m0,006s
sys     0m0,007s

executed on source - transfer FROM source TO target:
The authenticity of host 'XXXXXXX)' can't be established.
ECDSA key fingerprint is SHA256:1yKllVCQcXP4XXXXXXXXXV6b9FVyyKw0Sbeo.
ECDSA key fingerprint is MDXXXXXX6c:6XXXXXXXXXX:3f:cd:a3:2b:15.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added XXXXXXXXXX (ECDSA) to the list of known hosts.
root@XXXXXX's password:
plesksupport.txt 100% 13 0.6KB/s 00:00

real 0m23.663s
user 0m0.014s
sys 0m0.009s

I just had a thought: The destination Server is currently behind a NAT firewall that only forwards certain ports. Are there specific ports needed for the Plesk Migrator? I've migrated to this destination before about a year ago and had no problems though.

Currently the following ports are being forwarded:
FTP 21,1024-1050,49152-49159
Mail 25,110,143,465,993,995
PLESK 715,8443,8447
SSH 22
WEB 80,443
(All TCP)


Thanks!
 
HOLY F*CKING SH*T. I found it.
This resolves THREE DAYS of agony. This is so stupid :(

I utilize an Ubiquiti Unifi Dream Machine Pro (UDM-PRO) on the target location as a easy to deploy security solution. The box of course has Threat Detection and Blocking enabled to provide advanced Security, DPI and so on.

THANK YOU @IgorG for pointing out directly that this might be a network issue.

While single transfers both by ssh/scp, https, ftp etc are fine between those locations as shown above, the security module of the Gateway decided to classify the migration process as an "Attempted Information Leak" (well, it's not wrong in a way...) and blocked it via it's IPS/IDS routine:


1658399087579.png

I have not the slightest clue why a single SCP transfer does does not trigger this but the migration does, especially because we are talking about an OUTGOING transfer that is being blocked, but after disabling the threat decetions "scan" routine the migrator started working:

1658399434805.png

THANK YOU ALL FOR YOUR HELP!
 
Back
Top