Support

The restoration does not delete any file or directory. It only overwrites files. The code is there so that anyone can verify this claim. Moreover, the backup archive is still there, you should be able to use it to restore the site using Kickstart. The software does get tested by half a dozen people over the globe on a variety of hosting environments before even a beta goes out. Moreover, people using the betas report bugs and we usually resolve them in a matter of hours.

Can you please provide more information about this incident? Which version of Akeeba Backup were you using? Did you use the FTP mode to perform the restoration? There were some issues with restoration in Beta 1 and Beta 2, but the 3.0 stable release released 2 months ago and the 3.0.1 bugfix release which was released three weeks ago fixed them. None of those bugs, however, could lead to the problem you described, simply put because there is no such code in the restoration script.

Also note that websites do not "vanish" like that. Even if the restoration screwed up at some point (for instance, due to incorrect permissions), only a single file should be affected. Technically it's IMPOSSIBLE to remove all files and all directories of a site from the restoration script. As all PHP developers can attest, doing a recursive delete of a site would hit a timeout, therefore it would need a process split in multiple steps. Since the script would be gone as part of one of the steps (but certainly not the final step), the next call to it would throw an error and the recursive deletion would have stopped. Based on your report, neither of these happened, unless I am missing some critical information here.

At this point I would also like to note that there are thousands of users who have - unlike you - found Akeeba Backup to be anything but "utter crap". If - despite the fact that what you describe and the way you describe it happened can't happen and that this impossible issue has never happened to the dozens of users who have been using it - wish a refund, please provide me with your invoice number and PayPal address and I will refund you in full.

It took me a while to replicate your problem, because you forgot to mention the actual step which caused the problem. Here is the procedure in its entirety:
1. You went to the Adminsiter Backup Files page
2. You selected a backup and clicked on Restore
3. As soon as the extraction was over you got to a page telling you that the installer should open within five seconds; if not, click on a link. Below that there is a button labelled "Finalize restoration" which is supposed to remove the installation directory.
4. The installer didn't open and you didn't click on the "here" link to open it manually. Instead, you clicked on the Finalize Restoration which freaked out - as the installation hadn't happened yet - and removed the site's root.

I realized that all of us who tested the software took for granted that a user should run through the actual installer before clicking on that button. It also never occurred to us that the button's label is misleading and its behaviour unpredictable when the installer hasn't already run. What is more puzzling to me is that no-one else ran into this for the past 3 months this feature is included in Akeeba Backup, most possibly because they were reading and following the manual during the site restoration.

Anyway, I accept that the current behaviour is far from optimal and has to be changed immediately. To this end, I am replacing the button with one which will open the installer and give instructions on how you can manually remove the installation directory after the restoration is over. This change will appear in the next developer's release.

Please accept my sincere apologies for this situation. I am upgrading your account to a lifetime membership on the Deluxe level and I hope that you will continue to use Akeeba Backup and report any bugs you may encounter through the ticket system where I can attend to them much faster than through the public forum.

Thank you for your continued trust in our software and for providing me with enough information to replicate this issue :)

As a side note, you might want to follow some advice for securely storing backups. The best strategy is to have three copies of every backup archive, ideally stored in different physical locations. One very easy to follow procedure is to use the cloud storage option of Akeeba Backup to automatically upload your backup archives to DropBox, leave one copy on the server so that you can use the integrated restoration. This results in the file being at three places: your server, DropBox's servers and your local PC (as DropBox synchronizes the contents of the local directory with their server). This may sound like paranoia, but at least you can be assured that even in the case of a problem like the one you had nothing is lost.