Facebook
Twitter
-
If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
CentOS2Alma discussion
Issue Backup restore too very very long
- Thread starter RomanLed
- Start date
If a previous backup or restore has crashed (is hanging, unresponsive), you must first kill the process before attempting a new one, because the new one won't run before the previous one has finished. You can normally do it this way:
1) On Linux console run
# ps aux | grep PMM
2) Kill the processes that belong to the Plesk Migration Manager, e.g.
# kill 12345
# kill 98765
(use the process IDs identified in step 1)
To find out why a restore is hanging, look into the corresponding restore log file in /var/log/plesk/PMM/restore-*.
1) On Linux console run
# ps aux | grep PMM
2) Kill the processes that belong to the Plesk Migration Manager, e.g.
# kill 12345
# kill 98765
(use the process IDs identified in step 1)
To find out why a restore is hanging, look into the corresponding restore log file in /var/log/plesk/PMM/restore-*.
It restored after 10 hours. 
I do not have damaged copies, I checked this way
nothing helps!
As part of the test I wanted to restore the SQL database 1MB, after an hour I turned off
The backup file was downloaded from sftp to / tmp a few minutes and restoring from this file is a joke.
I do not have damaged copies, I checked this way
nothing helps!
As part of the test I wanted to restore the SQL database 1MB, after an hour I turned off
The backup file was downloaded from sftp to / tmp a few minutes and restoring from this file is a joke.
So what is the reason for the long duration?
Are there no entries in /var/log/plesk/PMM/restore-* that could help to identify the cause? Normally, everything is logged there. I'd also check /var/log/messages at the time of the restore, because it might show some general system issues. And it would be good to run "top" to check the server's cpu load. If the load is very high, it can considerably slow down the restoration process, because untaring the archives uses a lot of cpu time.
There are no errors or similar things in the logs.
The all process has a usage of 2-5% processor at that time.
I started the second test server on a different system, but also with the same version Plesk Onyx - this is exactly the same problem!
There are some entries on the net about a slow recovery by the Plesk, so this is probably problematic for Plesk.
Simply can not use Plesk for backup/restore
The all process has a usage of 2-5% processor at that time.
I started the second test server on a different system, but also with the same version Plesk Onyx - this is exactly the same problem!
There are some entries on the net about a slow recovery by the Plesk, so this is probably problematic for Plesk.
Simply can not use Plesk for backup/restore
Load Average 0.84 .069 0.70
Load Average 0.22 0.34 0.53
within a few minutes
For example, I also have Softaculous installed, which I use for a Prestashop backup of the store.
Restoring the 300 Mb database and 2 GB directories takes 2-3 minutes.
Plesk is a good solution, but the backup function is a misunderstanding
Load Average 0.22 0.34 0.53
within a few minutes
For example, I also have Softaculous installed, which I use for a Prestashop backup of the store.
Restoring the 300 Mb database and 2 GB directories takes 2-3 minutes.
Plesk is a good solution, but the backup function is a misunderstanding
Last edited:
Could it be possible that your backup set is much larger than the 200 MB mentioned in your first post, but you are trying to restore only that one portion from it? If a large backup archive is located on an external archive (ftp server), Plesk first needs to download the full backup and all increments that lead to the one that you want to restore. Afterwards, all these archives need to be unpacked, and as a final step the actual restoration takes place.
Please try the following: Before restoring, first download the external backup into the server storage. Then, in a separate step, restore from the local server repository. This should be considerably faster.
Please try the following: Before restoring, first download the external backup into the server storage. Then, in a separate step, restore from the local server repository. This should be considerably faster.
I think this needs investigation of the restore log files by support staff. The only reasons I can think of why the restore process is slow is that the server does not handle computations on the untaring of the file correctly. Basically, the restore process only consists of standard Linux operations, like copy, rename, tar. There is not so much magic about it. The major hold-up during a restore is checking the file signature and untaring the .tar archive(s). Once it is untared, the rest of a restore is only a file copy operation. That ought to be as fast as any other file copy operation on the operating system. However, untaring and checking the file signature can take very long if the system does not have enough computational power, e.g. has a lot of load otherwise. If that is not the case, I don't see why a significant delay could occur.
i have same problem.
my plesk is 18.0.4 and my backup files are incremental (base is 61GB and 6 incremental file with about 1.5 GB).
i trying restore this backup but it`s taking too long time because plesk use only 1 thread for /usr/lib/plesk-9.0/sw-tar for restore the backup.
my plesk is 18.0.4 and my backup files are incremental (base is 61GB and 6 incremental file with about 1.5 GB).
i trying restore this backup but it`s taking too long time because plesk use only 1 thread for /usr/lib/plesk-9.0/sw-tar for restore the backup.
