Facebook
Twitter-
Please be aware: Kaspersky Anti-Virus has been deprecatedWith 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.
Forwarded to devs Recurring, intermittent backup process stuck since update to 18.0.41 on three independent systems
- Thread starter Bitpalast
- Start date
D4NY
Regular Pleskian
UPDATE - Is it possible that a 25mbps download and 18mbps upload speed (tested from my pc not from server) to the FTP Backup Space is too slow for having good time performance?
Can't understand why for months everything was fine and in the last 3 days all slow or stuck.
Anyway, Happy Christmas everyone.
Can't understand why for months everything was fine and in the last 3 days all slow or stuck.
Anyway, Happy Christmas everyone.
The speed will likely be higher when a server from a data center connects directly, because these are normally connected to the internet with a much higher bandwidth. You can use sftp on your Linux console to connect to your backup space directly, e.g.
# sftp [email protected]
then test-transfer a large file like
> put test.dump
or
> get test.dump
The program will show you the speed of the connection.
The problem in the specific case can be that with many backups going, the number of concurrent connections to your FTP space is limited so that some backup connections fail. You can probably contact your data center where you have the FTP backup space to find out, what their limit on concurrent FTP connections is. Rule of thumb: Per backup job from Plesk you need three concurrent connections.
You can also experiment with this setting in panel.ini file:
[pmm]
ftpForbidReuseConnection = 1
This will make backups more sequential, it could help when your FTP storage space has strict limits on the number of concurrent connections.
# sftp [email protected]
then test-transfer a large file like
> put test.dump
or
> get test.dump
The program will show you the speed of the connection.
The problem in the specific case can be that with many backups going, the number of concurrent connections to your FTP space is limited so that some backup connections fail. You can probably contact your data center where you have the FTP backup space to find out, what their limit on concurrent FTP connections is. Rule of thumb: Per backup job from Plesk you need three concurrent connections.
You can also experiment with this setting in panel.ini file:
[pmm]
ftpForbidReuseConnection = 1
This will make backups more sequential, it could help when your FTP storage space has strict limits on the number of concurrent connections.
D4NY
Regular Pleskian
The speed seems to be ok, maybe not the fastest in the world but it can't be the problem.
The storage box is hosted in Hetzner and we have 10 concurrent connections:
It's the stability of the FTP connection that let me think to be the source of the problem. SFTP via SSH was ok 2-3 times but the 4th time after put the password it lag infinity. Opening Backup Manager for some websites was ok, for others it took minutes to open or to give timeout error.
Anyway i've open a ticket in Hetzner and also modified the scheduled backup time for 70 websites along 24 hours (it was scheduled in 9 hours during the night).
The storage box is hosted in Hetzner and we have 10 concurrent connections:
It's the stability of the FTP connection that let me think to be the source of the problem. SFTP via SSH was ok 2-3 times but the 4th time after put the password it lag infinity. Opening Backup Manager for some websites was ok, for others it took minutes to open or to give timeout error.
Anyway i've open a ticket in Hetzner and also modified the scheduled backup time for 70 websites along 24 hours (it was scheduled in 9 hours during the night).
Hetzner once told me that their Storage Box is using a virtualized FTP solution. From my experience with the service it is indeed the case that on their the "10 concurrent" connections are not immediately freed after using them. You did it right to spread backup times over the day not to have too many going on at the same time.
D4NY
Regular Pleskian
[NEW YEAR UPDATE]
During the Christmas holidays i've asked Hetzner if the Storage Box could have problems with the stability of the connection. The answer was something like "the host has quite busy, but not. If you want we can switch the box to another host". Obviously i switched to check if something change.
In the last days of 2022 i've scheduled backup for only 2 of the 70 and also set a single website for every 15 minutes (during whole day) so there's no possibilty to have concurrent backup at the same time. The result was not good because, even if the .tar file has been saved after hours, i got the same errors about FTP.
I was starting to look around and check other ftp solutions for my backups (hoping that it's not a Plesk problem and i'm not sure about that) when suddenly, on 4 January i got no error mail and the backup has completed normally. So i reactivated all backups scheduled now every 15 minutes and the day after i had a big surprise: every backup was completed successfully and exactly at the scheduled hour. I'm happy, but i can't understand. Nothing changed Plesk side and the new box was running since 28 december so it can't be.
Anyway now take a look at how fast and precise as a swiss clock are my backups:
If anyone has an idea can be useful for similar cases. Anyway i think backups are the weakest point in Plesk.
This is just a suggestion for the future updates.
During the Christmas holidays i've asked Hetzner if the Storage Box could have problems with the stability of the connection. The answer was something like "the host has quite busy, but not. If you want we can switch the box to another host". Obviously i switched to check if something change.
In the last days of 2022 i've scheduled backup for only 2 of the 70 and also set a single website for every 15 minutes (during whole day) so there's no possibilty to have concurrent backup at the same time. The result was not good because, even if the .tar file has been saved after hours, i got the same errors about FTP.
I was starting to look around and check other ftp solutions for my backups (hoping that it's not a Plesk problem and i'm not sure about that) when suddenly, on 4 January i got no error mail and the backup has completed normally. So i reactivated all backups scheduled now every 15 minutes and the day after i had a big surprise: every backup was completed successfully and exactly at the scheduled hour. I'm happy, but i can't understand. Nothing changed Plesk side and the new box was running since 28 december so it can't be.
Anyway now take a look at how fast and precise as a swiss clock are my backups:
If anyone has an idea can be useful for similar cases. Anyway i think backups are the weakest point in Plesk.
This is just a suggestion for the future updates.
"the host has quite busy, but not. If you want we can switch the box to another host"
I had previously gotten the same reply on the same case description, I think that was >2 years ago.
They are using a virtualized file system for their Storage Boxes, I am pretty sure that it must have something to do with that as the only reports with similar symptoms are coming from other of their users. The root cause however remains unknown.
I had previously gotten the same reply on the same case description, I think that was >2 years ago.
They are using a virtualized file system for their Storage Boxes, I am pretty sure that it must have something to do with that as the only reports with similar symptoms are coming from other of their users. The root cause however remains unknown.
Similar threads
