Facebook
Twitter
Username:
TITLE
If the "Maximum number of simultaneously running scheduled backup processes" is set, shorter backups that start after a longer backup are prioritized
PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE
CentOS 7.9, Plesk Obsidian with latest MU
PROBLEM DESCRIPTION
Scenario:
"Maximum number of simultaneously running scheduled backup processes" is set to "2",
Backup process priority: 10, IO priority: 7
Run all backup processes with low priority.
A full server backup starts at 1 am. It normally stores approx. 500 GB to an external FTP storage and normally finishes at around 9 am.
However, on the server approximately eight subscribers have defined their subscription backups to run some time between 2 am and 7 am.
All of the shorter individual subscriber backups are executed within an expected, short backup duration. But they hinder the longer full server backup, that started way earlier than the subscriber backups, from continuing. This results in a very long delay of approximately 3 h 30 m (in this case) for the full server backup. Once all the shorter subscriber backups are through, the full server backup continues.
It seems that either due to process priority settings or the "simultaneously running" setting it is possible that backups take priority over an already started backup, maybe during backup process "breaks" of the longer, already started process?
Please see
talk.plesk.com
for more details including log excerpts.
STEPS TO REPRODUCE
Probably something like this:
1) Create a significant amount of data in some subscriptions, so that a full server backup takes a long time to complete, e.g. several hours.
2) Create several subscriptions with individual backup jobs that are scheduled within a certain time frame.
3) Define a full server backup that starts before the first individual subscription backup.
4) Check telemetry of the full server backup.
ACTUAL RESULT
Not sure if this is easy to reproduce, because it might need specific "timed" hits on exactly the right time slot so that subscriber backups gain priority over an already running full server backup. But my result here is that the full server backup is paused until all subscriber backups that were started later completed.
EXPECTED RESULT
First come, first serve. If the full server backup is started first at night, it should maintain priority over all consecutive backup processes that are scheduled by subscribers. It should not pause for what reason ever just because a subscriber backup for some reason was "faster" to gain control over a process slot.
ANY ADDITIONAL INFORMATION
(DID NOT ANSWER QUESTION)
YOUR EXPECTATIONS FROM PLESK SERVICE TEAM
Help with sorting out
TITLE
If the "Maximum number of simultaneously running scheduled backup processes" is set, shorter backups that start after a longer backup are prioritized
PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE
CentOS 7.9, Plesk Obsidian with latest MU
PROBLEM DESCRIPTION
Scenario:
"Maximum number of simultaneously running scheduled backup processes" is set to "2",
Backup process priority: 10, IO priority: 7
Run all backup processes with low priority.
A full server backup starts at 1 am. It normally stores approx. 500 GB to an external FTP storage and normally finishes at around 9 am.
However, on the server approximately eight subscribers have defined their subscription backups to run some time between 2 am and 7 am.
All of the shorter individual subscriber backups are executed within an expected, short backup duration. But they hinder the longer full server backup, that started way earlier than the subscriber backups, from continuing. This results in a very long delay of approximately 3 h 30 m (in this case) for the full server backup. Once all the shorter subscriber backups are through, the full server backup continues.
It seems that either due to process priority settings or the "simultaneously running" setting it is possible that backups take priority over an already started backup, maybe during backup process "breaks" of the longer, already started process?
Please see
Question - Very long backup time for one specific subscription despite low file count and low disk space usage
On one single subscription of one single server backup telemetry measures a very long gap of 3 h 30 m and/or duration for packing files. However, the subscription has only 28,000 files in total and occupies only 9 GB of disk space uncompressed. 3 GB of that are .tar.gz files. Question: Why...
talk.plesk.com
STEPS TO REPRODUCE
Probably something like this:
1) Create a significant amount of data in some subscriptions, so that a full server backup takes a long time to complete, e.g. several hours.
2) Create several subscriptions with individual backup jobs that are scheduled within a certain time frame.
3) Define a full server backup that starts before the first individual subscription backup.
4) Check telemetry of the full server backup.
ACTUAL RESULT
Not sure if this is easy to reproduce, because it might need specific "timed" hits on exactly the right time slot so that subscriber backups gain priority over an already running full server backup. But my result here is that the full server backup is paused until all subscriber backups that were started later completed.
EXPECTED RESULT
First come, first serve. If the full server backup is started first at night, it should maintain priority over all consecutive backup processes that are scheduled by subscribers. It should not pause for what reason ever just because a subscriber backup for some reason was "faster" to gain control over a process slot.
ANY ADDITIONAL INFORMATION
(DID NOT ANSWER QUESTION)
YOUR EXPECTATIONS FROM PLESK SERVICE TEAM
Help with sorting out
