Resolved Deleting backups over ssh - I'm doing something wrong

[akira9000]

Hi,

On Plesk Onyx 17.5.x ( can't check last digit as can't login )

In the browser I'm getting

ERROR: Plesk\Exception\Database: DB query failed: SQLSTATE[HY000]: General error: 1021 Disk full (/var/tmp/#sql_481_0); waiting for someone to free some space..., query was: DESCRIBE `sessions`

Additionally, an exception has occurred while trying to report this error: Zend_Exception
No entry is registered for key 'translate' (Mysql.php:53)

This is because overnight my disk got full - I think it's backups filling the space but I can no longer get to Plesk through the GUI to delete them. When I df I can see I'm at 100% on /dev/vda3 where the sites live.

I'm trying to get to the backups through SSH but I'm doing something wrong as get "No such file or directory" when I run what I found on Google. So,

cd /var/lib/psa/dumps

then

ls

to see what's in there, identify the oldest backup and then run:

/root/local/psa/admin/bin/pmm-ras --verbose --debug --delete-dump --dump-specification=backup_info_1707112001.xml --session-path=/var/log/plesk/PMM

Then I get the "No such file or directory"

Any pointers on what I've screwed appreciated.

 

[UFHH01]

Hi akira9000,

/root/local/psa/admin/bin/pmm-ras

pls. use the path:

/usr/local/psa/admin/sbin/pmm-ras .....

... as the Plesk "root" - directory is located at "/usr/local/psa" ( on Debian/Ubuntu - based system, the path is "/opt/psa" , but as you have an existing symlink "/usr/local/psa" to "/opt/psa", you are always able to use "/usr/local/psa" for each of your corresponding Plesk - commands. ​

 

[akira9000]

Bingo! Many thanks.

 

[akira9000]

Spoke too soon. Something seems to have gone out of sync with disk usage and the backups. After the clear up the disk got down to approx 30G usage out of 50G. Since the weekend on nightly Plesk internal backups the disk has now hit 100% again even though this should have taken weeks rather than days I also am not getting email warnings from Watchdog regarding disk usage - bit weird.

Should I also delete the following from /var/lib/psa/dumps ? I have SSH'd in and deleted the only xml file I could find which has got the disk down to 93%.

domains
mysql.daily.dump
mysql.daily.dump.0.gz
mysql.daily.dump.1.gz
mysql.daily.dump.2.gz
mysql.daily.dump.3.gz
mysql.daily.dump.4.gz
mysql.daily.dump.5.gz
mysql.daily.dump.6.gz
mysql.daily.dump.7.gz
mysql.daily.dump.8.gz
mysql.preupgrade.17.5.3-17.5.3.20170426-122411.dump.gz
mysql.preupgrade.17.5.3-17.5.3.20170516-032329.dump.gz
mysql.preupgrade.17.5.3-17.5.3.20170601-034547.dump.gz
mysql.preupgrade.17.5.3-17.5.3.20170614-031731.dump.gz
mysql.preupgrade.17.5.3-17.5.3.20170620-032326.dump.gz
mysql.preupgrade.17.5.3-17.5.3.20170702-034006.dump.gz
mysql.preupgrade.17.5.3-17.5.3.20170705-174602.dump.gz
mysql.preupgrade.17.5.3-17.5.3.20170711-034332.dump.gz
mysql.preupgrade.17.5.3-17.5.3.20170718-031503.dump.gz
mysql.preupgrade.17.5.3-17.5.3.20170725-033223.dump.gz
mysql.preupgrade.17.5.3-17.5.3.20170808-034724.dump.gz
mysql.preupgrade.17.5.3-17.5.3.20170817-031744.dump.gz
mysql.preupgrade.17.5.3-17.5.3.20170825-033636.dump.gz
mysql.preupgrade.17.5.3-17.5.3.20170902-031738.dump.gz
mysql.preupgrade.17.5.3-17.5.3.20170919-032718.dump.gz
mysql.preupgrade.17.5.3-17.5.3.20171002-033631.dump.gz
mysql.preupgrade.17.5.3-17.5.3.20171009-034952.dump.gz
mysql.preupgrade.apsc.17.5.3-17.5.3.20170426-122412.dump.gz
mysql.preupgrade.apsc.17.5.3-17.5.3.20170516-032330.dump.gz
mysql.preupgrade.apsc.17.5.3-17.5.3.20170601-034548.dump.gz
mysql.preupgrade.apsc.17.5.3-17.5.3.20170614-031732.dump.gz
mysql.preupgrade.apsc.17.5.3-17.5.3.20170620-032328.dump.gz
mysql.preupgrade.apsc.17.5.3-17.5.3.20170702-034008.dump.gz
mysql.preupgrade.apsc.17.5.3-17.5.3.20170705-174603.dump.gz
mysql.preupgrade.apsc.17.5.3-17.5.3.20170711-034333.dump.gz
mysql.preupgrade.apsc.17.5.3-17.5.3.20170718-031504.dump.gz
mysql.preupgrade.apsc.17.5.3-17.5.3.20170725-033225.dump.gz
mysql.preupgrade.apsc.17.5.3-17.5.3.20170808-034726.dump.gz
mysql.preupgrade.apsc.17.5.3-17.5.3.20170817-031745.dump.gz
mysql.preupgrade.apsc.17.5.3-17.5.3.20170825-033638.dump.gz
mysql.preupgrade.apsc.17.5.3-17.5.3.20170902-031740.dump.gz
mysql.preupgrade.apsc.17.5.3-17.5.3.20170919-032720.dump.gz
mysql.preupgrade.apsc.17.5.3-17.5.3.20171002-033632.dump.gz
mysql.preupgrade.apsc.17.5.3-17.5.3.20171009-034953.dump.gz

Maybe just time for a bigger disk lol

 

[UFHH01]

Hi akira9000,

actually, the depending log should point you to issues, where "leftovers" might exist for some reasons. Even that the backup - process should be a "fully automated" process, without any manual interactions, there could still exist an issue here or/and there ( nothing is really perfect, unfortunately ) from time to time. Your depending backup - log - files are located at => /var/log/plesk/PMM and should be inspected, if you experience any issues/errors/problems with your backups.

From time to time, I clean all content inside of "/var/lib/psa/dumps" and afterwards I start a new, fresh complete backup manually and I change/modify some backup settings, so that Plesk has to rewrite the existing backup - task ( pls. make sure to re-change your little change again, so that your initial setup meets your previous settings ).

 

[akira9000]

Thanks for the fast reply.
When I try to run:

/usr/local/psa/admin/bin/pmm-ras --verbose --debug --delete-dump --dump-specification=mysql.daily.dump.0.gz --session-path=/var/log/plesk/PMM

for example, I get an error at the end

Repository error: file name 'mysql.daily.dump.0.gz' not ends with '.xml'

[2017-10-11 14:28:52.145| 9249] INFO: pmm-ras finished. Exit code: 152

So this command only works with xml?

 

[UFHH01]

Hi akira9000,

pls. note, that a correct example would look like:

... --dump-specification=<backup_name>.xml ...

 

[akira9000]

I'm confused. There are no more xml files in that directory. But there are plenty of files like:
mysql.preupgrade.17.5.3-17.5.3.20170426-122411.dump.gz

How can I delete these?

 

[UFHH01]

Hi akira9000,

How can I delete these?

Pls. just login with a SSH - client to your server ( logged in as user "root ), move to the directory and use the "rm" - command.

Example:

cd /var/lib/psa/dumps

ls -lah

rm mysql.preupgrade.17.5.3-17.5.3.20170426-122411.dump.gz

 

[akira9000]

cool, thanks

 

[akira9000]

Nailed it. Was completely coincidental that one of the domains was creating huge 5G log files full of the same php errors. Found this very handy command that pointed the way

du -x / |sort -rnb |more

Thanks for your help - again.