Cynical translation of that: I didn't understand the setup and made a change which deleted everything. I haven't found anyone else to blame yet but I'm desperately trying.
There was need to increase the amount of RAM in the server. As a result of that procedure - suddenly all data stored on the server has been lost! [..] the disappearance of the data was the result of the introduction of virtual server settings, which he never would have introduced.
For Amazon persistent storage, you don't just change a setting, you need to pay extra for EBS storage and design your service to use it, so saying the following:
We are constantly trying to determine who made changes to these settings and whether it will be able to recover lost data.
Suggests a continuing lack of understanding, and that makes it seem more likely that the service was built on quicksand and is now sunk. Even if we assume that they did have EBS volumes available and someone had redesigned their service to not use them, that they have no access audits, no regular setup audits, no long term backups, no revision control history, no change procedure and no email records (and nobody who remembers anything about it) to give them a clue what happened, that's pretty damning in itself for a financial service.
Once I realized that I deleted the machine [..] At the moment I am unable to clearly determine the causes of crashes
Maybe an artefact in the translation, but you can't accept that you caused it while also being unable to determine the cause!
I suppose that it is the result of actions of third parties, which are causing the server tried to cancel to hide their illegal activities
If this is a serious admission that their Amazon account was hacked, the assurance that unpaid cash from the sale of bit coins is safe seems a bad idea, and hiding it at the bottom of another announcement is really poor form. If it's not a serious admission then it reeks of pointing the blame anywhere except 'here' and is also poor form.
There was need to increase the amount of RAM in the server. As a result of that procedure - suddenly all data stored on the server has been lost! [..] the disappearance of the data was the result of the introduction of virtual server settings, which he never would have introduced.
For Amazon persistent storage, you don't just change a setting, you need to pay extra for EBS storage and design your service to use it, so saying the following:
We are constantly trying to determine who made changes to these settings and whether it will be able to recover lost data.
Suggests a continuing lack of understanding, and that makes it seem more likely that the service was built on quicksand and is now sunk. Even if we assume that they did have EBS volumes available and someone had redesigned their service to not use them, that they have no access audits, no regular setup audits, no long term backups, no revision control history, no change procedure and no email records (and nobody who remembers anything about it) to give them a clue what happened, that's pretty damning in itself for a financial service.
Once I realized that I deleted the machine [..] At the moment I am unable to clearly determine the causes of crashes
Maybe an artefact in the translation, but you can't accept that you caused it while also being unable to determine the cause!
I suppose that it is the result of actions of third parties, which are causing the server tried to cancel to hide their illegal activities
If this is a serious admission that their Amazon account was hacked, the assurance that unpaid cash from the sale of bit coins is safe seems a bad idea, and hiding it at the bottom of another announcement is really poor form. If it's not a serious admission then it reeks of pointing the blame anywhere except 'here' and is also poor form.
Is anyone else reminded of Leafyhost about now?