• Plesk Uservoice will be deprecated by October. Moving forward, all product feature requests and improvement suggestions will be managed through our new platform Plesk Productboard.
    To continue sharing your ideas and feedback, please visit features.plesk.com

Question backup freezes and system/SQL hangs

shopuser

Basic Pleskian
Server operating system version
Ubuntu 20.04.6 LTS
Plesk version and microupdate number
Plesk Obsidian 18.0.71 Update 1
During the backup ( viaSFTP to extern server ) of a subscription, this freezes and so does the system, all websites (with SQL) are no longer accessible, CPU performance in monitoring is approaching zero.
1752911136995.png
Plesk is still accessible

After stopping the backup and restarting the server, everything works again.

It may be the database backup, which is 1.28 GB in size.
 
It's a pity :( that there is no solution. The problem is also with other websites, also a different server and the database MariaDB is only 429 Mb
 
Backup Locally is the from time to time , and sometimes just this one subscription is super slow backups never ending / freeze
and I have to cancel the backup and restart the server.

CPU
AMD EPYC 7282 16-Core Processor (8 core(s))
Version
Plesk Obsidian v18.0.72_build1800250901.06 os_Ubuntu 20.04
Betriebssystem
Ubuntu 20.04.6 LTS

RAM 32.00 GB

SSD
234.31 GB

1757685140836.png

1757685071956-png.28671
 

Attachments

  • 1757685071956.png
    1757685071956.png
    54.4 KB · Views: 18
Backup Locally is the from time to time , and sometimes just this one subscription is super slow backups never ending / freeze
and I have to cancel the backup and restart the server.


Excellent point. In that case you might have an enormous number of files in some subfolder. They might be small, but many, for example a million or more files of only a few bytes each. This could match your symptoms, because in that case, it "feels" like the backup doesn't move on, but in reality, it takes the tar utility program ages to collect all those files into an archive. I've seen that situation several times with customers accounts here where users had indeed millions of "temporary" files in some subdirectory of their websites, some /httpdocs/tmp or similar directories. Prestashop has been an issue in the past with millions of session* files, but other websites have been seen doing the same. The point there is that these don't occupy much space, but every single one needs to be addressed separately by tar, so the backup becomes extremely slow.

Mitigation suggestions 1:
Install the free backup telemetry add-on:
1757685996101.png

then check how long the different stages of a backup take. You might find one domain/website that takes hours while others complete within minutes. Look deeply into the directory structure of that website.

Mitigation suggestion 2:
While the backup is running, execute on the linux console:
# ps aux | grep pmm
It will give an output like
Code:
root     3474562  0.6  0.0 368488 40800 ?        S    16:08   0:00 /usr/bin/python3 -Estt /usr/local/psa/admin/sbin/pmmcli_daemon
root     3476781 55.0  0.0 331000 14352 ?        RN   16:10   0:00 /usr/local/psa/admin/bin/pmm-ras --get-dump-info --session-path=/usr/local/psa/PMM/sessions/2025-09-12-160832.472 --dump-file-specification=backup_info_2509121608.xml --with-feedback --debug --verbose
root     3476788  0.0  0.0 222024  1116 pts/0    S+   16:10   0:00 grep --color=auto pmm
Take the session-path and expand it with /migration.log, then follow along what's logged, because then you can see where the system is currently at, e.g.
less usr/local/psa/PMM/sessions/2025-09-12-160832.472/migration.log
You can also tell from the load column of the output whether it is doing something or not. In the example above you can see the "55.0", clearly indicating it has not crashed.
You could then also run
iotop
to see whether a lot of disk activity is going on. There probably will be a lot.
When you see a lot of activity, but the backup seems to take very long, look deeply into the directory structure of the path that is being backed up (you can see where the system is by looking at the migration.log as described above). Find the culprit there.
 
Last edited:
yesterday evening the same :

1757747779807.png



i have stoped the backup and restart the server, in the backupmanager teh show komplet backup
undefined
without error
 
Back
Top