Incident Library

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

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

Lessons

–

Sources

Related cases

Check your cluster for this

kubegap audits a Kubernetes cluster for conditions like the ones in this case, Cloud block storage, Database backups and snapshots among them, read-only, from Claude Code or Codex. Its checks cite public reports like this one.

For AI tools and scripts

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.