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