Resolved Error during scheduled backup process

[Dirk]

Hi guys,
every morning I receive following Email:

Server
Plesk entry point: https://www.meinedomain.de:8443/

The following error occurred during the scheduled backup process:

Nicht genügend Speicherplatz für das Backup.​

That's all. No more information. "Nicht genügend Speicherplatz für das Backup." means something like: insufficient diskspace. Strange thing is, I do have 400GB free diskspace, and the backup does work out fine and is completed without errors inside plesk.

Any ideas?

root@hxxxxx:~# df -h
Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf
udev 1,9G 0 1,9G 0% /dev
tmpfs 392M 43M 350M 11% /run
/dev/md1 454G 28G 404G 7% /
tmpfs 2,0G 0 2,0G 0% /dev/shm
tmpfs 5,0M 20K 5,0M 1% /run/lock
tmpfs 2,0G 0 2,0G 0% /sys/fs/cgroup
/dev/md0 969M 74M 830M 9% /boot
tmpfs 392M 0 392M 0% /run/user/0

 

[Dirk]

Anyone...?

 

[Bitpalast]

Plesk admin can configure one backup, but each subscription can also configure its own backup. Could it be possible that a subscription has configured a backup, and for that subscription's backup the disk space is insufficient?

 

[Dirk]

Hey, thnx Peter,
good idea!
I never activated the backup inside the subscriptions - but they were there. Is it possible, that plesk does that automatically as soon as a new domain is added?
I disabled them manually and I hope that the error-email will not reappear tomorrow. Will keep you informed about it.

 

[Dirk]

Damn - didn't solve the problem :-/
I disabled the subscription-backups and only the plesk-wide backup is active. Still every morning that very annoying email. The strange things are:
- the backups are complete
- the error email-option is disabled
Any ideas?

 

[Bitpalast]

Is it a backup to an external FTP storage space or a backup to the internal hard disk? How did you validate that the backup is complete?

Please check the backup.log and pmmcli.log backup log files in /usr/local/psa/PMM/logs/backup-2016-12-*... directory of your backup. They should contain many details on the backup process and might reveal the cause of the message.

 

[Dirk]

Thanks for your support, Peter,

- the backup is only to internal hard disk
- I validated the backup by checking the backups inside plesk. It marks the backup as valid
- I checked the logs:
backup.log has a lot of infos and one error:

[16763]: 2016-12-28 05:05:31.520 ERROR 6336ae5e-ef70-47d8-853f-e66c313ebd6a Cannot connect to mysql localhost:3306 (database 'wordpress_6')​

pmmcli.log has no errors:

[2016-12-28 05:01:02.955|16762] DEBUG: LOG: custom log /var/log/plesk/PMM/backup-2016-12-28-05-01-02-954/backup.log
[2016-12-28 05:01:02.977|16762] INFO: Executing asynchronously <subprocess[16763] 'nice --adjustment=10 /usr/bin/perl /opt/psa/admin/bin/plesk_agent_manager server --owner-uid=00000000-0000-0000-0000-000000000000 --owner-type=server --keep-local-backup --session-path=/opt/psa/PMM/sessions/2016-12-28-050102.955 --output-file=/opt/psa/var/modules/dropbox-backup/server.hxxxxxx.stratoserver.net.tar'>
[2016-12-28 05:01:02.979|16762] DEBUG: Acquired session mutex: MainThread
[2016-12-28 05:01:02.979|16762] DEBUG: detecting running pmmcli daemon...
[2016-12-28 05:01:02.980|16762] DEBUG: starting pmmcli daemon...
[2016-12-28 05:01:02.986|16762] DEBUG: Executing asynchronously [16764] process. CmdLine is '/opt/psa/admin/sbin/pmmcli_daemon'
[2016-12-28 05:01:02.986|16762] DEBUG: Create type=Backup
[2016-12-28 05:01:03.281|16762] DEBUG: Released session mutex: MainThread
[2016-12-28 05:01:03.282|16762] DEBUG: Acquired session mutex: MainThread
[2016-12-28 05:01:03.282|16762] DEBUG: Update task id=28, type=Backup
[2016-12-28 05:01:03.482|16762] DEBUG: Released session mutex: MainThread
[2016-12-28 05:01:03.483|16762] DEBUG: <pmmcli.MakeDumpAction object at 0x7f3d7e358890>: response
[2016-12-28 05:01:03.487|16762] INFO: Outgoing packet:
<?xml version="1.0" ?><response>
<errcode>0</errcode>
<data>
<task-id>28</task-id>
</data>
</response>​

But there is one strange thing. It mentions /opt/psa/var/modules/dropbox-backup/server.hxxxxxx.stratoserver.net.tar, but neither did I set a backup to dropbox, nor can I find where to disable it...? Could that be the problem?

 

[Dirk]

O.K. - found the Dropbox-Module. Disabled it - let's see what tomorrow brings ;-)

 

[Bitpalast]

Yes, that's the culprit.

 

[Dirk]

Still receiving the error-mail.
No more sign of Dropbox, but still the daily error-email.

pmmcli.log says:

[2016-12-29 04:12:03.596|28322] DEBUG: LOG: custom log /var/log/plesk/PMM/backup-2016-12-29-04-12-03-596/backup.log
[2016-12-29 04:12:03.602|28322] INFO: Executing asynchronously <subprocess[28323] 'nice --adjustment=10 /usr/bin/perl /opt/psa/admin/bin/plesk_agent_manager server --owner-uid=d115a741-6748-4990-ac87-754c10ae9720 --owner-type=server --dump-rotation=-1 --incremental --description=Scheduled Backup. All configuration and content. --keep-local-backup --exclude-pattern-file=/opt/psa/PMM/sessions/2016-12-29-041203.597/exclude --session-path=/opt/psa/PMM/sessions/2016-12-29-041203.597'>
[2016-12-29 04:12:03.603|28322] DEBUG: Acquired session mutex: MainThread
[2016-12-29 04:12:03.603|28322] DEBUG: detecting running pmmcli daemon...
[2016-12-29 04:12:03.603|28322] DEBUG: starting pmmcli daemon...
[2016-12-29 04:12:03.625|28322] DEBUG: Executing asynchronously [28324] process. CmdLine is '/opt/psa/admin/sbin/pmmcli_daemon'
[2016-12-29 04:12:03.625|28322] DEBUG: Create type=Backup
[2016-12-29 04:12:04.013|28322] DEBUG: Released session mutex: MainThread
[2016-12-29 04:12:04.014|28322] DEBUG: Acquired session mutex: MainThread
[2016-12-29 04:12:04.014|28322] DEBUG: Update task id=29, type=Backup
[2016-12-29 04:12:04.292|28322] DEBUG: Released session mutex: MainThread
[2016-12-29 04:12:04.293|28322] DEBUG: <pmmcli.MakeDumpAction object at 0x7f8d147568d0>: response
[2016-12-29 04:12:04.298|28322] INFO: Outgoing packet:
<?xml version="1.0" ?><response>
<errcode>0</errcode>
<data>
<task-id>29</task-id>
</data>
</response>​

I am absolutely clueless... any more ideas??

 

[Bitpalast]

If you are sure that there are no other backup jobs that throw an error I assume this is a case for individual Plesk support (ticket) or that it is a bug.

 

[Dirk]

O.K., thanks for your help. I will open a support tickert and post the result as soon as I have one.

 

[Dirk]

Plesk repair all
Solved the problem. Thank God