Issue Backup restore too very very long

[RomanLed]

Hello,

Backup restore files 200MB and database sql 5 MB too very very long!!, it already takes 5 hours

I've tried to restore several times, but after an hour I got angry then I stopped

 

[Bitpalast]

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-*.

 

[RomanLed]

It restored after 10 hours.
I do not have damaged copies, I checked 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-*.

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.

 

[Bitpalast]

To find out why a restore is hanging, look into the corresponding restore log file in /var/log/plesk/PMM/restore-*.

So what is the reason for the long duration?

 

[RomanLed]

I would also like to know?
the restoring process used 0.5-.1.5% of the processor, It may be a problem? no matter what I restore

 

[Bitpalast]

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.

 

[RomanLed]

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

 

[Bitpalast]

I think that 2% to 5% cpu usage during a restore is almost impossible, because that would mean that on a single-core processor the top command outputs 0.02 or 0.05. What type of processor is it and what is top really displaying?

 

[RomanLed]

Dedicated Root Server Hosting - Hetzner Online GmbH

The restoring process uses around ~1%

 

[Bitpalast]

Yes, but that's not the question. What is the load of the system?
# top
In the top line you see "load average:"

 

[RomanLed]

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

 

[Bitpalast]

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.

 

[RomanLed]

Yes, the backup file is bigger
But downloading and unpacking in the / tmp directory takes only a 10-15 minutes - restoring 5 hours

I also launched a test server, 100MB backup file and the same problem.
Also it is not the fault or configuration settings for my server.

 

[Bitpalast]

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.

 

[S.MohsenB]

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.

 

[The 8th]

I had the same issue @Bitpalast I'm restoring the WHMCS backup and it takes now 5 hours and still in process, i hope you can add a progress bar or percentage % so we can know what is the progress or if it is really works

 

[The 8th]

looks no response for the most of the posts here

 

[Sebahat.hadzhi]

At this point, the alternative I can suggest to check if the backup restoration task is running is:

https://support.plesk.com/hc/en-us/articles/12377537084567-How-to-check-if-a-Plesk-backup-restoration-task-is-still-running