Over the weekend, I was breaching 90%-ish of my inodes limit on my webhost. This led me to a blunder with Softaculous WordPress Manager while removing some installs. This was due to a bloated but necessary plugin for some of my WordPress demonstration sites. I’ve been trimming all of my installs for some time now, managing as low as 78%.
A few staging sites’ install brought it back up to 83-85% usage. This plugin install on several sites tipped it up to 93%. This plugin also spammed WordPress-admin-bar-incessant-annoying-as-heck-promotions, which necessitated another plugin. So I decided to kill off one staging site, already in production plus an orphan entry.
There are two options to manage your WordPress installations in cPanel by Softaculous. The first option, Softaculous WordPress Manager, and the other, Softaculous Script Installation (Manager). I used the former, and I got the following screen.
My previous webhost limits me to only 10 databases, so I had to combine a few installations. The two buttons Remove and Uninstall were very distinct, and clear about its functions, but it somehow still deleted the shared database, and folder of the orphan install. I keep it to redirect to the new URL, located on a different folder.
During the webhost switch, duplicates or orphans install popped up, and were undeleteable. This forced me to recreate renamed/deleted folders and databases to get rid of those ghost records. That should have been an indicator that this would delete files, folders, and/or databases. Perhaps removing the phantom records, while not active, (renamed or deleted) would also delete the linked files/folders/databases, due to the records still pointing to the actual files/folders/databases.
The recent database were copied and downloaded, just in case. Recklessly I deleted the record while also downloading it. A quick check revealed I indeed did screw it up.I saw that the database download was complete, but wary if it was corrupted during the download. The recent changes and updates made were numerous. That equates to serious man hours to bring it up to date again.
Nevertheless, I uploaded the recent download, and restored the database user account and access to it, and luckily everything worked, for now. The inodes limit is now just under 80%. The other method, allows a more granular control over the folder and database, but if I recalled correctly (during my webhost migration), this didn’t work all the time too.
Be First to Comment