What Really Happened to Ctrip’s Database? A Technical Deep‑Dive into the Attack and Backup Risks

Observed Outage

At around 2 PM, Ctrip’s PC homepage lost access to its core hotel and flight services, and users could not log in; the mobile app showed the same failures, and personal order queries were unavailable. News reports claimed the service went down at 11:09 AM, attributing it to an "unknown attack" on some servers.

Likelihood of a Database‑Wide Attack

Given the breadth of the impact—affecting more than a dozen business units that normally operate independently—it is unlikely the problem stemmed from a routine deployment bug or a simple operational mistake. The simultaneous failure of most services points to a large‑scale attack, possibly targeting the databases themselves.

Potential Attack Scenarios

If only the business nodes were compromised, the code or services could be quickly redeployed because the underlying machines would still be functional. However, the persistent "HTTP/1.1 Service Unavailable" responses across all search functions suggest that the load‑balancers or the database layer were hit.

Two extreme possibilities are considered:

Hackers gained deep knowledge of Ctrip’s internal systems and performed a prolonged, stealthy infiltration, ultimately deleting or overwriting database files and backups.

Attackers obtained root access on a majority of machines and executed destructive commands (e.g., dd to overwrite data), making recovery impossible.

Backup Architecture and Recovery Prospects

Ctrip reportedly uses a private OpenStack cloud, likely leveraging Swift for object storage. If backups reside in Swift, an attacker would need to locate and delete the three replica copies to achieve total data loss. If backups are stored on separate appliances or on‑premises, there is a higher chance of recovery.

Assuming regular daily backups and proper log shipping, at most a day’s worth of data could be lost. Without real‑time log backups, the impact could be more severe.

Worst‑Case Outlook

In the worst case—where the attacker controls most servers and destroys both the primary and replica databases as well as the backup storage—the service may remain down indefinitely, with data loss comparable to a “heart‑shot” scenario.