SOLVED Root partition is full or how to grow / from 32GB to like 64GB?

[Benjamin D.]

Hi, not sure if this questions fits in MISC, but...

My dedicated server running WHM 110.0 has encountered a completely new issue today: The root partition is 100% full (20MB left!) and so I ran this (sorry, code formatting is completely broken on this forum) : sudo find /var -size +200M -exec ls -ld {} \;

This allowed me to find a couple WP databases that were abnormally big and I managed to get back 2GB. Root partition is 32GB (29GB after formatting) and I find it's not big enough in 2023 for a dedicated server running a ton of Wordpress sites. So now there is 1.9GB free which is enough for now but I feel like the issue might repeat in a couple days.

How can I grow the root partition to like 64GB? The physical hard disk on which this 32GB root partition is located is multiple terabytes in size, so I could theorically take a few GB from the rest of that physical hard disk, but I just don't know what command to run to do it.

 

[cPRex]

Hey there! Unfortunately, I wouldn't know this one either. cPanel doesn't handle any management of the hardware or the operating system, so it would be best to ask the hosting provider or datacenter if it is safe to perform that type of work with your specific server, and they'd be able to let you know the correct steps to do that without data loss.

 

[Benjamin D.]

Then, I'm stuck because the data center does not offer any kind of software/configuration support, which I had hoped WHM could do since it's at the OS level and takes care of installing kernel updates and whatnot, but I guess I will have to order another server, modify the partitions, keeping in mind it will never be possible to change those afterwards, and then copy terabytes of accounts to that new server. I mean, it's kind of a bummer. Why is the root partition so tiny? And why is WHM storing MYSQL databases on the tiniest partition to begin with? Wouldn't it make much more sense to store all the MYSQL databases on the /home partition instead?! Can WHM help me move them to the /home partition? Like what are my options?

 

[ffeingol]

How is your current drive partitioned?

WHM does not decide where things go per-se (other than home folders). By default /var/lib/mysql is where the databases will go. Depending on how the drive is partitioned will determine where MySQL databases end up.

 

[cPRex]

Exactly - you aren't "stuck" just, you had to move to plan B, which is often more complicated.

There are ways to move the MySQL data directory that we have outlined here: https://support.cpanel.net/hc/en-us/articles/360057909913-How-to-Move-MySQL-Datadir

 

[Benjamin D.]

@ffeingol It's by default. Several years ago, I ordered a dedicated server from the data center and I ticked the WHM/cPanel option and it came with this:

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 3.7T 0 disk
├─sda1 8:1 0 511M 0 part /boot/efi
├─sda2 8:2 0 29.3G 0 part /
├─sda3 8:3 0 3.6T 0 part /home
└─sda4 8:4 0 3.9G 0 part [SWAP]
sdb 8:16 0 3.7T 0 disk /home3
sdc 8:32 0 3.7T 0 disk /home2

I never chose to partition it like this nor to have MYSQL databases in that tiny, tiny root partition. It's just too tiny for 2023 needs. I never even suspected MYSQL databases to be stored there until it became a problem many years later (today). What is the reason for WHM to not store them in the /home partition with all other services? (email, websites, SSL certs, etc) ?

 

[cPRex]

We should clarify that it may be your host's default, but cPanel doesn't assign any partitioning - that all happens when the OS is configured.

 

[Benjamin D.]

It's the data center's template, I would presume. Either way, I am now reading your suggested link, cPRex. If I could move the databases to /home I think it would resolve the issue as they're using probably 95% of the space out of the 32GB.

If I follow the procedure from your link, will the next WHM update break these changes as it usually does when you poke around configuration files by yourself?

 

[cPRex]

No, those changes don't get overwritten by the system in future updates.

 

[ffeingol]

Just so you are aware, you're kind of playing "whack a mole". With that partition scheme (I know it was not your choice) EVERYTHING except /home is in the root partition. There are lots of things in /var that can grow quite large (/var/log /var/spool etc.). So when you fix the issue with MySQL DB's, something else may cause that partition to fill.

 

[Benjamin D.]

It has not been a problem over the last 6 years, but I get the point. Pretty sure once I get 20GB of databases out of the 32GB partition, I'll be able to sleep much better. I will plan this procedure at night over the weekend and let you know how it goes next week. How long do you think it takes to migrate 20GB of MYSQL databases to another partition on the same disk? In your opinion, is it the same speed as just copying regular files from a folder to another folder on the same disk or is it drastically slower?

 

[ffeingol]

At the end of the day it's just a disk to disk copy. It would be hard to accurately answer without knowing a lot about the databases. If you have a lot of databases with a lot of small files, it's going to go slow (like copying mailboxes in mdir format). If you have lots of databases with big tables it goes faster. Either way, 20 GB of data disk to disk on the same server should not be horrible. The biggest issue is that all the sites will be offline while you copy, since MySQL will need to be down.

 

[Benjamin D.]

"all the sites will be offline while you copy"
... Well that was my other question, since in the procedure, it says to stop MYSQL *AFTER* the copy and so, why would the web sites be down while we "copy" the databases (rather "dump" the databases) ? My guess would have been that a web site will appear SLOW or to be down for a couple seconds if a visitor requests it exactly at the same time the mysqldump is happening on that site's database. Before or after the mysqldump is reading it, it should not be locked and it really should not be locked at all if the website's PHP script is only READING from it in the first place.

 

[quietFinn]

In step 1 you make backup of the databases, in step 3 you stop MySQL, in step 6 you move the databases to another directory, and in step 9 you start MySQL.

 

[Benjamin D.]

Oh, I misread, so step 1 is only for safety, it's not even part of the actual database moving, indeed. I need ONE MORE coffee cup haha... alright, will be attempting this in a few days (over the weekend) and will let you know. Thanks.

 

[Benjamin D.]

Alright, so I wanted thank you for the link, that solution worked perfectly fine: https://support.cpanel.net/hc/en-us/articles/360057909913-How-to-Move-MySQL-Datadir

Also, for future admins doing this to their dedicated server: BE PREPARED FOR SERIOUS DOWN TIME. It took almost half an hour just to perform this move command:
mv /var/lib/mysql /home/var_mysql

Thanks again.

 

[cPRex]

I'm glad it went well!