IL-0538 Sakura Internet · 2012-01-05database
Sakura Cloud storage maintenance deleted 53 in-use customer disks, and the disks could not be restored from backup
Sakura Cloud was released on 15 November 2011, and its storage device had failures on and off from 9 December 2011 to the end of March 2012. One of the problems was performance: from early January, as more customers created disks, the number of shared file systems on the storage device grew, and the CLI that the cloud system uses to create and delete file systems became slow to respond and to finish commands. The number of file systems was one reason for the slowdown, so in the emergency maintenance on 5 January Sakura Internet started deleting disks that had not finished being created because of the load and disks whose contracts had been cancelled. The load was too high for the normal procedure, so the team wrote a batch command for this maintenance and used it to delete the unneeded file systems all at once.
The batch command was not reviewed or tested enough, and nobody noticed that its rule for which kinds of file systems to delete (ones that failed to be created, ones that were cancelled) was wrong. It deleted 53 disks that were in use. These were file systems that had been created in advance as stock to prevent storage performance degradation, and the command took them for disks that had not been created properly. A backup mechanism existed, but backups had become less frequent because of the storage load, and the deleted disks were new enough that their backups had not started yet, so they could not be restored. After this incident Sakura Internet simplified the process for deleting unneeded file systems and made it a rule that scripts without enough review and testing are not run. The storage problems as a whole led Sakura Internet to add a second storage device on 12 March 2012 and later to replace the storage with a device it developed itself.
- Severity
- –
- Scope
- 53 Sakura Cloud disks that customers were using were deleted and could not be restored
- Users affected
- –
- Region
- –
- Time to detect
- –
- Time to resolve
- –
Symptoms
During emergency maintenance on 5 January 2012, a bulk deletion of unneeded file systems on the Sakura Cloud storage device also deleted 53 disks that customers were using. The deleted disks could not be restored from backup.
The maintenance was a response to a storage device that had been slowing down since early January. Every customer disk on Sakura Cloud is a shared file system on the storage device, and as the number of shared file systems grew with the number of users, the storage device's CLI (Command Line Interface), through which the cloud system creates and deletes files, took longer to connect and to run commands. To keep the number of file systems down, unneeded file systems had to be deleted often, and creating and deleting disks took very long or timed out. Under the high load, the normal deletion procedure could not be run at all.
Symptom Data loss
Root cause
Root cause Operator error
- Trigger
- In the emergency maintenance on 5 January 2012, Sakura Internet ran a batch command written only for that maintenance to delete unneeded file systems on the storage device in bulk.
Detection
–
Remediation
–
Action items
- Simplify the process for deleting unneeded file systems
- Do not run scripts that have not been reviewed and tested enough
Lessons
–
Sources
Related cases
IL-0218GitLab.com's primary PostgreSQL data was wiped by mistake and, with no working backup, the site was down about 18 hoursGitLab · 2017same root cause · shared Cloud block storage, Database backups and snapshots
IL-0242Both PostgreSQL servers behind matrix.org were lost during a disk expansion, and the homeserver was down for 24 hoursMatrix.org Foundation · 2025same root cause · shared Database backups and snapshots
IL-0534Amazon S3 in US-EAST-1 could not serve GET, LIST, PUT or DELETE requests for hours while its index subsystem restartedAmazon Web Services · 2017same root cause · shared Cloud block storage
IL-0573A developer's mistake dropped nine main tables of the Baemin billing MariaDB database and payments briefly stoppedWoowa Brothers · 2016same root cause · shared Database backups and snapshots
IL-0319Dropping databases on the MySQL replica mysql2 also dropped them on mysql1, as the pair actually ran master-masterOregon State University Open Source Lab · 2015same root cause · shared Database backups and snapshots
IL-0337EBS volumes in one US East Availability Zone got stuck after a network change cut EBS nodes off from their replicasAmazon Web Services · 2011same root cause · shared Cloud block storage
Check your cluster for this
For AI tools and scripts
- This case as JSON: https://incidentlib-api.benchlet.com/cases/IL-0538
- The cases most like it: https://incidentlib-api.benchlet.com/cases/IL-0538/similar
- MCP server (Streamable HTTP, no key):
https://incidentlib-mcp.benchlet.com/mcp
The API needs no key. The MCP server offers search_incidents, get_incident, list_incidents, get_topic and vocab; both are explained on API and MCP.