Ok is the cyberpanel installation is from 2nd March makes sense, the bug was corrected last week, (dont kill the messenger the revisions management on the version control is bad at the moment)
The trigger that deleted the files was the out of disk space.
The issue was that when a backup failed, it deleted the files(the worst scenario possible for an IT guy).
@usmannasir can you point me to where this command is called, this is probably why the unfinished backup folder is not deleted, as a mention, this ca mean that it could be also some other situation where it can still happen.
@MyIDKaTePe I’m sure it can be recreated but it’s not something I aim to do. dazburn just chimed in to clarify that the issue is still present in an up-to-date version of CyberPanel despite the staff saying otherwise and I just added in my findings. Neither of us came here to ask for help, we’re just saying that we’ve experienced the same bug that OP reported.
If it was actually only fixed last week as per @ricardojds’s comment then it makes sense, however we appeared to be running the latest version this morning and were greeted by a “Your CyberPanel is up to date” message on SSH login.
It didn’t delete everything except wp-content, it deleted everything including wp-content and then wp-content was recreated (as an empty shell) by an automatic script that needed to make a folder inside it.
If you run mkdir -p wp-content/something/something-else it will create all the parent directories for your innermost one.
The main point I came to make is that this bug had the potential to destroy an entire business for someone who didn’t have any other backups except Google Drive installed.
Thankfully, we’re not complete amateurs, but there is no way I could recommend Cyberpanel to anyone if such a major error and deletion of all site files could even be a possibility, bug or no bug.
@ricardojds thanks for the note about 2nd March installation. Can someone advise in simple terms how to update Cyberpanel then? Should we be installing the dev version because at the moment our server is showing it’s using 2.1 Build 1 though, not Build 2.
This is yet another example of why it is MISSION CRITICAL, TOP PRIORITY to improve the versioning system before you work on anything else.
We currently don’t receive any notification that there have been minor updates, so most people have no idea that they need to do so. This is even more urgent when you push tiny updates to fix CATASTROPHIC bugs, such as this one.
It seems completely clear that you should be making proper use of the 2.1.X for all of these - each minor commit should result in the final digit incrementing. It can go to 2.1.99999999 if needed. And then when a major feature is added, it moves to 2.2.0. And when there are breaking changes, it moves to 3.0.0. This is basic, standard practice.
If this makes your development/git workflow more difficult, so be it - it doesn’t matter compared to this. Though, given that this is standard practice, I don’t see how it could be difficult to manage. You’ll just have to adapt your workflow. There is no other choice.
Again, someone nearly lost their entire business because of this bug. Moreover, how many servers and businesses are currently running on a version of 2.1.2 that doesn’t have this fix (let alone all the other fixes from the past 6 months since 2.1.2 was released)? Thousands? Tens of thousands? More? All of your efforts to improve the security and stability are irrelevant if people aren’t made aware until an official version comes out every 6-12 months…
It would be completely unforgivable if you don’t urgently take the appropriate steps (detailed above) to fix this problem once and for all.
@die2mrw007@shoaibkk@asma, I’m copying you here to make sure you are aware and that you can put your energy towards supporting Usman in urgently making this crucial change