Table of contents of the article:
It was a morning like any other in our office, when the phone rang insistently. On the other end of the line, an excited voice reached us. It was a PHP developer who had decided to manage his production environment on a VPS hosted by a well-known Italian provider. He had chosen Plesk for its ease of use, convinced that it would give him full autonomy in managing the server without having to depend on a systems administrator. However, the reality was very different: his company's management system had suddenly gone offline and, with it, the entire company workflow was paralyzed.
"We have a server with Plesk, we can't figure out what happened, but the database won't start!” he said in a tone that oscillated between panic and desperation.
We started asking some preliminary questions. Had there been any recent updates? Anything unusual in the logs? After a few minutes of conversation, the first clue: “The disk was almost full… and then, suddenly, everything stopped.”
When Disk Fills Up: Effects on Plesk and MariaDB
A full disk partition can have devastating consequences on a server, especially if it hosts a MariaDB or MySQL database. If the system runs out of space to write to, services begin to fail unpredictably, processes crash, and the database can become corrupted while trying to complete interrupted operations. This is exactly what we feared.
Connecting to the server via SSH, we immediately confirmed the seriousness of the situation: the main partition was at 100% usage. This meant that MariaDB no longer had the leeway to perform critical operations, such as saving logs or handling the rollback of incomplete transactions. In these cases, the biggest risk is that the InnoDB engine gets stuck in an inconsistent state, making it impossible to start the database without manual recovery interventions.
The only immediate action possible was free up space to give the system some breathing space. After a quick analysis, we located and deleted old backups left in /var/lib/psa/dumps/, overgrown log files, and other useless temporary data. With a few gigabytes recovered, we tried restarting MariaDB in the hope that the problem would resolve itself.
But no, the service kept failing.
At that point, we started digging deeper. After analyzing the system logs and MariaDB logs, we made an alarming discovery: the directory /var/lib/mysql/ it was completely empty and without any database. There was no trace of the files .ibd, .frm o .MYD which normally make up a MySQL/MariaDB database.
This was a critical situation: Without those files, there was no database to recover. A MySQL server without data is like a car without an engine. But the question was: where did those files go? Was it an automatic action by Plesk? Did MariaDB delete them in a failed restore attempt?
Without backups available, the problem became even more serious. To be safe, we immediately asked the customer if a backup service was active. Automatic backup or snapshot of VPS. The answer made us shudder: no backup or snapshotting service had been subscribed.
Without a recent backup, recovery was a race against time. We then suggested contacting the hosting provider's support to check if, by pure chance, there was an undocumented snapshot of the machine. Although the snapshot service was not included in the plan, some hosting companies keep temporary copies for internal use, in case of failures or accidents.
The hoster didn't guarantee anything, but promised to check. In the meantime, we continued with the technical analysis, determined to find out where the database files went and if there was a way to recover.
Plesk and MariaDB: A Management Problem
One of the first things the developer tried to do was log into Plesk to check the database status and figure out what had happened. But here he ran into a new problem: Plesk itself was not accessible. The reason? Plesk management panel uses a database called psa, which resides on MariaDB. If the database fails to start, the Plesk web interface also becomes unusable, leaving the user with no point of control to manage the server.
This situation can be particularly frustrating for those who chose Plesk precisely for its user-friendly interface, convinced that it would make server management simple and immediate. However, in the event of a MariaDB crash, all server administration stops, including the management of accounts, domains and the databases themselves. Not only that: even web and email services may suffer, especially if the hosting configurations depend on information stored in the database psa.
At this point, the only possibility to intervene is SSH in with root privileges and fix the issue manually from the command line. This means having to perform advanced diagnostics, analyze system logs, find the cause of the problem, and apply the necessary fixes without the help of a graphical interface.
For those unfamiliar with advanced Linux management, this can be a daunting situation, and attempting to resolve the issue without the right skills can lead to further damage. Mistakes in applying commands, incorrect reinstallation attempts, or incorrect changes to configuration files can further compromise the server, requiring disaster recovery or, in the worst case, a complete reinstallation of the VPS.
The Unexpected Discovery: The Folder mysql.repair-innodb.*.d
Looking at the directory /var/lib/mysql, we found a worrying anomaly: it was completely empty. This meant that unless we found a copy of the data elsewhere, the database would be irretrievably lost. However, we knew that Plesk implements some automatic recovery mechanisms in case of problems with InnoDB, so we started looking for clues.
After a few minutes of analysis, we discovered something interesting in the folder. /var/lib/psa/dumps/: a directory called mysql.repair-innodb.20250320-093623.d. This name clearly indicated an automatic repair attempt performed by Plesk. When MariaDB detects severe corruption in InnoDB tables and fails to start, Plesk can attempt to move the data to a recovery directory, preventing the corrupted database from preventing the service from restarting. However, the automatic repair process does not always succeed, and in this case it seemed to have been interrupted by leaving the files stuck in this location.
At that point, the mission was clear: manually recover the database. We moved the entire contents of the folder mysql.repair-innodb.20250320-093623.d back in /var/lib/mysql, restoring the original location of the data files. With our hearts in our throats, we attempted to restart MariaDB.
The service started, indicating that at least the data structure had been recognized, but we soon realized that some tables were reported as corrupt. This could be because the previous move and repair attempt had not completed successfully. We didn't panic and we immediately moved on to the next step: checking and repairing the tables to fully restore the integrity of the database.
Database Repair and Optimization
We launched mysqlcheck --repair --all-databases, a fundamental command to verify and attempt to repair all tables in the database. This tool, integrated into MariaDB, allows you to perform integrity checks on data files and correct any damage to the tables. The operation took several minutes: the server was under stress due to the lack of recent optimizations and the accumulation of errors due to disk saturation.
We watched the terminal output carefully, waiting to see any positive signs. After a few moments of suspense, the first encouraging messages began to appear: several tables had been successfully repaired. Some required multiple attempts, while others required more in-depth internal data recovery. Fortunately, none of the core tables were completely unrecoverable, avoiding the risk of catastrophic data loss.
At that point, the database was working again, but we didn't stop there. To ensure optimal stability and performance, we also performed an optimization operation with the command:
mysqlcheck --optimize --all-databases
This step was crucial because after a repair, table files can become fragmented and take up more space than necessary, slowing down queries. The optimization consolidated data, defragmented indexes, and improved database efficiency.
Once this operation was completed, we performed a final check. The MariaDB service was stable, the queries responded without errors and the management system returned to function correctly. After three days of inactivity, our interlocutor's company could finally resume its work.
On the other end of the line, we heard a long sigh of relief. “I don’t know how to thank you, I thought I had lost everything!” he said gratefully. We, on the other hand, knew well that, with the right experience and a structured method, even the most critical situations can often be resolved.
Why Plesk Moved /var/lib/mysql in /var/lib/psa/dumps/?
When a MariaDB/MySQL database has critical issues related to InnoDB tables corrupted and corrupted data files, Plesk can automatically activate a mechanism emergency repair attempt. This process is started when the MariaDB service fails to start properly due to integrity errors on the database files.
One of the approaches taken by Plesk in these scenarios is the temporary move of the entire contents of the directory /var/lib/mysql/ in a safe area, which is typically found under /var/lib/psa/dumps/. Here a folder is created with a name like this:
/var/lib/psa/dumps/mysql.repair-innodb.YYYYMMDD-HHMMSS.d
This folder is designed to keep a copy of the database files in their original state before attempting any repair operations. The idea behind this procedure is to avoid MariaDB being left in a irreversible corrupt state, allowing the administrator to attempt manual data recovery if necessary.
When Plesk Decides to Move /var/lib/mysql?
Moving database files to a secure directory can occur in various scenarios, including:
-
Disk partition saturation – If the server runs out of space, MariaDB may crash while writing log files or data, leaving some InnoDB tables in an inconsistent state. Plesk may then attempt to move files to free up space and try a clean boot.
-
InnoDB Table Corruption – If MariaDB detects corrupted tables during startup, the InnoDB engine may refuse to start to prevent further damage. In such cases, Plesk can intervene by moving the data to a separate area for isolate the problem and attempt a repair.
-
Automatic restore failed – In some cases, Plesk may try to start MariaDB with a default option. forced recovery (As
innodb_force_recovery), but if the operation fails, it may leave the files in/var/lib/psa/dumps/to prevent a damaged database from preventing any subsequent recovery attempts. -
Unexpected system updates or crashes – During a Plesk or MariaDB engine upgrade, if the server is rebooted incorrectly or compatibility errors occur, some database files may become corrupted. Plesk may then move
/var/lib/mysql/for preserve data state before forcing a service restart.
What Happens if the Process Stops?
If the automatic repair attempt fails is interrupted or fails, the database is not restored and the main directory /var/lib/mysql/ remains empty, creating a serious problem: MariaDB can no longer find its data files and cannot start.
At this point, Plesk does not show any clear warning to the administrator as to why the database is down. The only way to find out is log in via SSH and manually inspect the folders.
If you find a folder like /var/lib/psa/dumps/mysql.repair-innodb.*.d, it is very likely that Plesk attempted an automatic recovery but failed to complete it. In such cases, you need to Manually move files from recovery folder to original directory (/var/lib/mysql/) and proceed with a manual database restore.
Plesk tries, it helps, but it's not enough
Although Plesk attempts to handle emergency situations on its own, its repair mechanism is not foolproof and can leave your server in a state of critical condition if the operation does not complete successfully.
Unless you have a deep understanding of MariaDB command-line management, recovering a database that has been automatically moved by Plesk can be a complex and risky operation.
For this reason, when managing a server with Plesk, it is essential to:
- Monitor disk space to prevent sudden saturations.
- Perform regular database backups, regardless of Plesk's automatic features.
- Have SSH access with root privileges to be able to intervene manually in case of serious problems.
For more details on Plesk automatic repair procedures, you can consult the official documentation:
The Moral: Autonomy vs. Systemic Competence
Plesk is probably the best of the web panels for managing hosting and servers, but relying exclusively on a graphical interface is not always a winning choice. The main problem with Plesk is not so much its functionality, but the false security it can give to those who use it without advanced system skills.
Many users rely on Plesk believing that the graphical interface is sufficient to ensure complete management of the server, without ever having to touch the command line. However, when critical problems such as MariaDB crash, the entire Plesk-based infrastructure comes to a halt, making any intervention impossible without SSH access and advanced Linux skills.
Another aspect that is often overlooked is that Plesk, by default, does not offer adequate protection against catastrophic scenarios, such as disk saturation or database corruption. If a user does not manually configure regular snapshots, automatic backups and proactive resource monitoring, risks finding themselves in emergency situations with no way out.
And here's the crux: Those who use Plesk are almost never system administrators. The typical target of this tool are developers, agencies, e-commerce managers or freelancers, who need to manage websites and applications without having to deal with the underlying infrastructure. This inevitably leads to a vicious circle: the user relies on Plesk thinking that he will never have to deal with complex problems, but when these arise, he does not have the tools or the knowledge to solve them.
When a server crashes, when a database disappears, when Plesk itself becomes inaccessible, It's no longer a matter of clicking buttons or following online guides. It takes real skills, it takes command line tools, it takes years of experience to know how to approach the problem without making the situation worse.
La more cautious solution? Rely on professional Linux system administrators, with decades of experience, capable of preventing and managing critical problems before they become disasters. A graphical interface can facilitate ordinary management, but when everything goes wrong, It is the experience of a true expert that makes the difference between data recovery and total data loss..
