• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Forwarded to devs Plesk server backups slow

D

dvries

New Pleskian
​
PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE:
Debian 8.10
Plesk 17.8.11 Update #5
​
PROBLEM DESCRIPTION:
We use the command pleskbackup server to make backups of the user information. Website and e-mail data are not made with this command.

The backups are very small. Nevertheless, it takes between 30
minutes and 1 hour before it is finished. Why does it take so long for such small (change) backups?
​
STEPS TO REPRODUCE:
With this command you can imitate it:

/opt/psa/bin/pleskbackup server -v --configuration --exclude-logs --no-gzip --output-file=
​
ACTUAL RESULT:
It takes between 30 minutes and 1 hour before the backup is finished.
​
EXPECTED RESULT:
I think the backup with such small files should be ready within 10 minutes or 20 minutes. But not 30 minutes or 1 hour.
​
ANY ADDITIONAL INFORMATION:
​
YOUR EXPECTATIONS FROM PLESK SERVICE TEAM:
Answer the question​
 
Have you tried to find a reason in backup logs?
/usr/local/psa/PMM/logs/backup-<datetime> for example?
 
I found something in /opt/psa/PMM/sessions/DATE/migration.log:

[2018-05-30 00:39:49.888|28593] INFO: pmm-ras started : /opt/psa/admin/sbin/pmm-ras --get-dump-info --dump-file-specification=backup_info_1805300022.xml --with-feedback --session-path=/opt/psa/PMM/sessions/2018-05-30-002246.240 --verbose --skip-content-validation
[2018-05-30 00:39:49.889|28593] INFO: Repository '/var/lib/psa/dumps': Initializing...
[2018-05-30 00:39:49.889|28593] INFO: Repository '/var/lib/psa/dumps': Initialized
[2018-05-30 00:39:49.889|28593] INFO: Repository '/var/lib/psa/dumps': Get backup info from backup_info_1805300022.xml
[2018-05-30 00:39:49.889|28593] INFO: Repository '/var/lib/psa/dumps': Get initial backup info for backup_info_1805300022.xml
[2018-05-30 00:39:49.889|28593] INFO: Repository '/var/lib/psa/dumps': Get info from .discovered/backup_info_1805300022/props
[2018-05-30 00:39:49.890|28593] INFO: Read properties from xml backup_info_1805300022.xml
[2018-05-30 00:39:49.890|28593] INFO: Repository '/var/lib/psa/dumps': Validate backup backup_info_1805300022.xml
[2018-05-30 00:39:49.890|28593] INFO: Repository '/var/lib/psa/dumps': Get info from .discovered/backup_info_1805300022/props
[2018-05-30 00:39:49.891|28593] INFO: Repository '/var/lib/psa/dumps': Validate backup (common phase) backup_info_1805300022.xml
[2018-05-30 00:39:49.948|28593] INFO: Repository '/var/lib/psa/dumps': Put info to .discovered/backup_info_1805300022/status_OK
[2018-05-30 00:39:49.949|28593] INFO: Repository '/var/lib/psa/dumps': Get all child backups for backup_info_1805300022.xml

[2018-05-30 00:48:52.379|28593] INFO: Repository '/var/lib/psa/dumps': Get info from clients/CLIENTNAME/.discovered/backup_info_1805300022/props

[2018-05-30 00:48:56.249|28593] INFO: pmm-ras finished. Exit code: 0
[2018-05-30 00:48:56.313|28177] INFO: Export file backup_info_1805300022.xml
[2018-05-30 00:48:56.313|28177] INFO: Repository '/var/lib/psa/dumps/': Initializing...
[2018-05-30 00:48:56.313|28177] INFO: Repository '/var/lib/psa/dumps/': Initialized
[2018-05-30 00:48:56.313|28177] INFO: Repository '/var/lib/psa/dumps/': Get all child backups for backup_info_1805300022.xml

[2018-05-30 00:53:08.255|28177] INFO: Repository '/var/lib/psa/dumps/': Get info from clients/CLIENTNAME/backup_info_1805300022.xml

/usr/local/psa/PMM/logs/LOGFILE:

[2018-05-30 00:22:46] Acquire PmmcliDaemon lock
[2018-05-30 00:22:46] daemon job started
[2018-05-30 00:22:46] daemon job delayed for 30 minutes
[2018-05-30 00:52:47] UnsuspendTaskAction added
[2018-05-30 00:52:47] UnsuspendTaskAction added
[2018-05-30 00:52:47] UnsuspendTaskAction added
[2018-05-30 00:52:47] UnsuspendTaskAction added
[2018-05-30 00:52:47] UnsuspendTaskAction added
[2018-05-30 00:52:47] UnsuspendTaskAction added
[2018-05-30 00:52:47] UnsuspendTaskAction added
[2018-05-30 00:52:47] UnsuspendTaskAction added
[2018-05-30 00:52:47] UnsuspendTaskAction added
[2018-05-30 00:52:47] UnsuspendTaskAction added
[2018-05-30 00:52:47] UnsuspendTaskAction added
[2018-05-30 00:52:47] UnsuspendTaskAction added
[2018-05-30 00:52:47] UnsuspendTaskAction added
[2018-05-30 00:52:47] UnsuspendTaskAction added
[2018-05-30 00:52:47] UnsuspendTaskAction added
[2018-05-30 00:52:47] UnsuspendTaskAction added
 
Could you measure execution time of the command?
Code: 
/bin/time -v find /var/lib/psa/dumps -name '*.xml' -exec cat {} \; -o -name 'props' -exec cat {} \; > /dev/null
 
DenisG said:
Could you measure execution time of the command?
Code: 
/bin/time -v find /var/lib/psa/dumps -name '*.xml' -exec cat {} \; -o -name 'props' -exec cat {} \; > /dev/null
Click to expand...

Yes, I did:

/bin/time -v find /var/lib/psa/dumps -name '*.xml' -exec cat {} \; -o -name 'props' -exec cat {} \; > /dev/null

real 4m15.764s
user 0m13.208s
sys 0m23.824s

Thank you!
 
Could you run another command?
Code: 
find /var/lib/psa/dumps -name '*.xml' | wc -l
And are there any extra directories in /var/lib/psa/dumps? Standard structure is described here.
 
DenisG said:
Could you run another command?
Code: 
find /var/lib/psa/dumps -name '*.xml' | wc -l
And are there any extra directories in /var/lib/psa/dumps? Standard structure is described here.
Click to expand...

Thanks for your reply! I have executed them:

find /var/lib/psa/dumps -name '*.xml' | wc -l
0

Directories and MySQL dump files:

drwxrwx--- 65 root root 4096 Oct 3 2016 clients
drwxrwx--- 1980 root root 151552 Jun 7 08:46 .discovered
drwxrwx--- 26 root root 4096 Nov 17 2016 domains
-rw-r--r-- 1 root root 1100 Jun 7 08:12 .last-dumps
-rw------- 1 root root 2157825 Jun 7 04:31 mysql.daily.dump.0.gz
-rw------- 1 root root 2160481 Jun 6 04:29 mysql.daily.dump.1.gz
-rw------- 1 root root 2160479 Jun 5 04:31 mysql.daily.dump.2.gz
-rw------- 1 root root 2158725 Jun 4 04:29 mysql.daily.dump.3.gz
-rw------- 1 root root 2156890 Jun 3 04:30 mysql.daily.dump.4.gz
-rw------- 1 root root 2157099 Jun 2 04:33 mysql.daily.dump.5.gz
-rw------- 1 root root 2153553 Jun 1 04:33 mysql.daily.dump.6.gz
-rw------- 1 root root 2170423 May 31 04:34 mysql.daily.dump.7.gz
-rw------- 1 root root 2168266 May 30 04:37 mysql.daily.dump.8.gz
drwxrwx--- 7 root root 4096 Aug 17 2016 resellers

du -h -d0 /var/lib/psa/dumps
3.9G /var/lib/psa/dumps

The data is mainly in:

/var/lib/psa/dumps/clients/<USERNAME>/domains/<DOMAIN>.com/.discovered and /var/lib/psa/dumps/clients/<USERNAME>/.discovered:

drwxr-xr-x 2 root root 4096 May 11 2017 backup_info_1705111612
drwxr-xr-x 2 root root 4096 Jun 07 09:57 backup_info_1804190807

The folders are then empty. (each 4 KB) There are also users/domain names who have already been removed in Plesk? Are they not cleaned up here by Plesk?
Why doesn't Plesk do any find command if there are old folders that are not updated? (they can removed)

It also contains very old data in /var/lib/psa/dumps/.discovered.
 
find /var/lib/psa/dumps -name '*.xml' | wc -l
0
Click to expand...
It means you do not have any 'live' backups in /var/lib/psa/dumps. I suggest to rename the folder /var/lib/psa/dumps, e.g. to /var/lib/psa/dumps.old and create the new one with the same permissions. Lately /var/lib/psa/dumps.old can be deleted.
 
DenisG said:
It means you do not have any 'live' backups in /var/lib/psa/dumps. I suggest to rename the folder /var/lib/psa/dumps, e.g. to /var/lib/psa/dumps.old and create the new one with the same permissions. Lately /var/lib/psa/dumps.old can be deleted.
Click to expand...

Thank you, I renamed it and recreated it:

find /var/lib/psa/dumps -name '*.xml' | wc -l
234

du -h -d0 /var/lib/psa/dumps
11M /var/lib/psa/dumps

time /opt/psa/bin/pleskbackup server -v --configuration --exclude-logs --no-gzip --output-file=/var/lib/psa/dumps

^Accounts [3/38], Domains [6/196], Dumping 'HASH(0x1922630)' in progress
Accounts [4/38], Domains [18/196], Dumping 'HASH(0x1922c60)' in progress
Accounts [5/38], Domains [30/196], Dumping 'HASH(0x19223c0)' in progress
Accounts [7/38], Domains [43/196], Dumping 'HASH(0x191edc0)' in progress
Accounts [13/38], Domains [54/196], Dumping 'HASH(0x191b778)' in progress
Accounts [16/38], Domains [64/196], Dumping 'HASH(0x191bc88)' in progress
Accounts [21/38], Domains [77/196], Dumping 'HASH(0x191e160)' in progress
Accounts [23/38], Domains [89/196], Dumping 'HASH(0x191ea00)' in progress
Accounts [27/38], Domains [102/196], Dumping 'HASH(0x191eb20)' in progress
Accounts [30/38], Domains [114/196], Dumping 'HASH(0x191e898)' in progress
Accounts [30/38], Domains [127/196], Dumping 'HASH(0x191b580)' in progress
Accounts [30/38], Domains [141/196], Dumping 'HASH(0x191b670)' in progress
Accounts [30/38], Domains [154/196], Dumping 'HASH(0x1922750)' in progress
Accounts [30/38], Domains [168/196], Dumping 'HASH(0x191eee0)' in progress
Accounts [35/38], Domains [177/196], Dumping 'HASH(0x1922e58)' in progress
Accounts [35/38], Domains [185/196], Dumping 'HASH(0x191b4d8)' in progress
Accounts [38/38], Domains [196/196]
-------------- Start print backup log hire --------------
<?xml version="1.0" encoding="UTF-8"?>
<execution-result status="warnings" log-location="/opt/psa/PMM/sessions/2018-06-11-120831.981/migration.result">
<message severity="warning" code="msgtext" id="92b0b39a-0e92-46ad-85e4-628e7b14ffe6">
<description>Harness not finished running at /opt/psa/PMM/agents/shared/Storage/ArchiveStorage.pm line 196.
</description>
</message>
</execution-result>
-------------- End print backup log hire --------------

You can view additional information in the log file located in /opt/psa/PMM/sessions/2018-06-11-120831.981 directory. This directory will be removed automatically after 30 days

The backup finished with status 'warnings' and had some problems. Look at log file for detailed information.

real 18m3.935s
user 0m2.500s
sys 0m1.280s

This is shorter than 1 hour. Could it be that it takes so long because that the other directory was more than 3 GB?
 
Thankyou for the information! They now last between 15 minutes and 25 minutes.
For a file with only configuration files (not larger than 1MB) this is quite long.

This backup should be ready within 5 minutes?

du -h -d0 /var/lib/psa/dumps = 21 MB

There is no customer data (/var/www/vhost, MySQL and e-mail) in our backups. We make that with a different method.
 
I'm experiencing the same and can't find out why.
Code: 
# time /opt/psa/bin/pleskbackup server -v --configuration --exclude-logs --no-gzip --output-file=/var/pleskbackup.tar

-------------- Start print backup log here --------------
<?xml version="1.0"?>
<execution-result local-dump-created="true" export-dump-created="true" status="success"/>

-------------- End print backup log here --------------

You can view additional information in the log file located in /opt/psa/PMM/sessions/2021-04-09-120130.369 directory. This directory will be removed automatically after 30 days.

The backup finished successfully

real    41m41.862s
user    0m25.176s
sys     0m9.416s
Code: 
# ls -lh /var/pleskbackup.tar
-rw-r--r-- 1 root root 21M Apr  9 12:42 /var/pleskbackup.tar
Code: 
# cat /opt/psa/PMM/sessions/2021-04-09-120130.369/dump-status.xml
<?xml version="1.0" encoding="UTF-8"?>
<agent-dump-status total-accounts="131" total-domains="412" completed-accounts="131" completed-domains="412"/>
Code: 
# du -h -d 0 /var/lib/psa/dumps
38M     /var/lib/psa/dumps

# time find /var/lib/psa/dumps -name '*.xml' -exec cat {} \; -o -name 'props' -exec cat {} \; > /dev/null

real    0m0.115s
user    0m0.040s
sys     0m0.044s
Code: 
# plesk version
Product version: Plesk Obsidian 18.0.30.2
     OS version: Debian 9.13 x86_64
     Build date: 2020/09/30 13:00
       Revision: 54aa592cbfe57596bf3c834d4c3e9ed0367a84b6

Can someone try the provided pleskbackup command? I'd like to know if this happening to everyone. Maybe it's only on Debian? This server is running with SSD storage and isn't slow at all, only this process takes way to long. It also happens when backing up clients or domains with pleskbackup. I hope other Plesk users will share their results. Thank you for that!
 
Plesk since 18.0.35 gathers telemetry of backup processes. The telemetry can be displayed via using the extension Backup Telemetry. Currently the extension can be installed only from command line
Bash: 
plesk bin extension --install backup-telemetry
After the installation you can go to backups list and open the telemetry for a backup from the list, for example for a backup created via the command
Bash: 
plesk bin pleskbackup server --configuration
The telemetry data helps to find out bottlenecks of backup processes.
 
DenisG said:
Plesk since 18.0.35 gathers telemetry of backup processes. The telemetry can be displayed via using the extension Backup Telemetry. Currently the extension can be installed only from command line

Bash: 
plesk bin extension --install backup-telemetry
Click to expand...

This is incredibly useful! Should be part of the standard installation
 
You must log in or register to reply here.

Similar threads

Joe Payne
Resolved Error using server backup to Dropbox after update to 18.0.56
Replies
2
Views
2K
Joe Payne
Joe Payne
PeopleInside
Issue with Google Drive Backup
Replies
6
Views
571
PeopleInside
PeopleInside
A
Resolved Full server scheduled backup shows "Backup to Cloud Pro" message
Replies
17
Views
3K
Peter Debik
P
Lexz
MX record lost after backup restore
Replies
2
Views
1K
Anatolii Zaporozhets
Anatolii Zaporozhets
M
Issue My plesk server is completely down
Replies
6
Views
1K
Kaspar@Plesk
Kaspar@Plesk
Back
Top