Resolved General error: 1021 Disk full while backing up all data from server [Obsidian 18.0.35]

[WhizzHacks]

Currently we have a system with 233 GiB ~ 250GB and we use about 139GiB ~ 149GB, every day in the night the data from the server should get backed up but the plesk backup so there is about 100GiB free storage and the plesk backup always encounters following error:

Warning: Subscription "domain"
Unable to back up files from /var/www/vhosts/domain owned by system user. Error: DB query failed: SQLSTATE[HY000]: General error: 1021 Disk full (/tmp/#sql_3e95_0.MAI); waiting for someone to free some space... (errno: 28 "No space left on device"), query was: DESCRIBE `disk_usage`

The overall situation of my disk is good, this is what I get with "df -h" command:

USED/WHERE


What should I do to prevent this error and backup up my data again?

 

[IgorG]

Have you checked free inodes too and 'cat /proc/user_beancounters' if it is a container?

 

[IgorG]

Also I'd suggest you delete temporary files that are older than 14 days:

# find /tmp -type f -mtime +14 -exec rm {} \;
# find /var/tmp -type f -mtime +14 -exec rm {} \;

before the backup process.

 

[WhizzHacks]

Thank you @IgorG but I already did this. The configuration from my server should be good, but I guess plesk saves the backups in the cache when they are created, or am I wrong?

 

[IgorG]

But what about this Issue - General error: 1021 Disk full while backing up all data from server [Obsidian 18.0.35] ?

 

[WhizzHacks]

Free inodes are good, and your command didn't work for me with ssh: File or directory not found

 

[WhizzHacks]

@IgorG do you have any other suggestions?

 

[Bitpalast]

On a 56% disk usage it is actually possible to encounter a "disk full" error when /tmp is not a separate partition but a path on /. Because in this case the temporary Plesk dump directory DUMP_D and the temporary system directory DUMP_TMP_D (normally /tmp) are on the same partition that is already occupied by 56%. If the limit is barely met, the "disk full" error causes the database to fail.

Further, if you succeed to run the backup without errors, it is likely that you will not be able to restore it. Because for restore, the full backup needs to be stored locally first, then unpacked. While the unpacking is in progress, storage space is needed for both, the packed file AND the unpacked files. When your disk is more than half full, this cannot work, because the unpacked files alone will occupy (almost) half of the disk space, but there is also storage space required for the packed backup file.

In my opinion, the only possible solution to this issue is to add more disk space. For example, you could add a second disk just for temporary files and maybe local backups.

I suggest to add a second hard disk and to move the DUMP_D and DUMP_TMP_D (see /etc/psa/psa.conf) to that disk. Also create /tmp as a separate partition, disable executable permissions on that partition (edit /etc/fstab and change the permissions of the new /tmp to defaults,nodev,nosuid,noexec) and mount that partition as your new /tmp.

 

[kalss]

So what's the way to fully backup a server with only one main partition and when partition is 80% full ?

 

[Bitpalast]

You need to add more disk space. If you are on a virtual machine, your provider might be able to simply allow more disk space on the existing partition. However, you can also add a new disk or a second, separate partition and more DUMP_D and DUMP_TMP_D to that partition.

 

[WhizzHacks]

So what's the way to fully backup a server with only one main partition and when partition is 80% full ?

Add another Disk to your server (min. the size of the main disk), change the dump and the dump_d Folder to the new partition, and try again