{"id":"IL-0576","org":"CareNet","date":"2025-10-07","docs":[],"title":{"en":"Every dataset in CareNet's production BigQuery data warehouse was deleted, and UNDROP SCHEMA could not restore them","ko":"테스트 코드가 운영 BigQuery 데이터 웨어하우스의 데이터셋을 전부 지웠다"},"domain":["database","gcp"],"impact":{"scope":"All datasets of the production BigQuery data warehouse used for data analysis by several departments; it is not connected to user-facing services","users":"unknown","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"BigQuery time travel with bq cp recovered most of the data, but only because the table names were known, and it does not bring back views or table functions. Test code should not be able to reach production, and service accounts should not hold more permissions than they need.","ko":"bq cp 로 복원하려면 테이블 이름을 알고 있어야 하고, 이 방법으로는 뷰와 테이블 함수를 되살릴 수 없다. 글쓴이의 팀은 BigQuery 의 타임 트래블 기능과 bq cp 명령 덕분에 데이터 대부분을 되살릴 수 있었다고 정리했다."},"related":[],"sources":[{"url":"https://zenn.dev/carenet/articles/recovering-from-bigquery-dataset-deletion","kind":"blog","archived":"https://web.archive.org/web/20260928051010/https://zenn.dev/carenet/articles/recovering-from-bigquery-dataset-deletion"}],"summary":{"en":"CareNet uses BigQuery as its production data warehouse for analysis, shared by several departments in one Google Cloud project. Test code from the AI technology development team, meant to initialise test-environment data, ran against production because of a configuration mistake, using the team's service account, which held more permissions than it needed. The code deleted each production dataset and created a new one with the same name.\n\nUNDROP SCHEMA failed because a dataset with the same name already existed again. At 13:06 the AI technology development team found that running bq cp in Cloud Shell could restore individual tables through BigQuery time travel, which can return a table to its state at a point within the past 7 days, and that this worked even after the same-name dataset had been recreated. The teams restored the tables one at a time to a point before the incident, which required knowing the name of every table, and by 16:00 most tables were back without losing most of the data. bq cp cannot restore views or table functions, so these were recreated from the creation queries kept in BigQuery saved queries. The AI technology development team then held a postmortem and shared the causes and the prevention measures with the other departments.","ko":"CareNet 은 BigQuery 를 운영 데이터 웨어하우스로 쓴다. 이 데이터 웨어하우스는 사용자가 쓰는 서비스와 연결되어 있지 않다. 여러 부서가 Google Cloud 프로젝트 하나를 함께 쓰며 데이터 분석용으로 데이터를 모은다. 2025년 8월 어느 날, AI 기술 개발실이 수정하던 테스트 코드가 설정 실수로 운영 환경을 대상으로 실행됐다. 이 코드는 테스트 데이터를 초기화하려고 데이터셋을 지우고 같은 이름으로 다시 만드는 코드였고, 그 결과 운영 환경의 데이터셋이 전부 지워졌다. 삭제를 실행한 것은 AI 기술 개발실의 서비스 계정이었고, 이 서비스 계정에는 필요 이상의 권한이 있었다.\n\n10:41 에 시스템 개발 본부가 장애를 처음 알렸고, 11:47 에 원인이 된 서비스 계정을 찾았다. 데이터셋을 되살리는 UNDROP SCHEMA 쿼리는 같은 이름의 데이터셋이 이미 새로 만들어져 있어서 동작하지 않았다. 13:06 에 AI 기술 개발실이 복원 방법을 알아냈다. BigQuery 의 타임 트래블 기능은 지난 7일 안의 특정 시점 상태를 되살릴 수 있고, Cloud Shell 에서 bq cp 명령에 장애 전 시점을 지정하면 같은 이름의 데이터셋이 다시 만들어진 뒤에도 테이블을 복원할 수 있었다. 팀은 테이블을 하나씩 복원했고 16:00 까지 테이블 대부분이 돌아왔다. 이 방법으로는 뷰와 테이블 함수를 되살릴 수 없어서 저장된 쿼리에 남아 있던 생성 쿼리로 다시 만들었다. 그 뒤 AI 기술 개발실은 포스트모템을 열어 원인과 재발 방지책을 정리하고 다른 부서에 공유했다."},"trigger":{"en":"Test code that was being modified contained a step that resets test data by deleting a dataset and recreating it with the same name. Because of a configuration mistake, the step ran against production and deleted and recreated every production dataset.","ko":"수정 중이던 테스트 코드가 테스트 환경의 데이터를 초기화하려고 데이터셋을 지우고 같은 이름으로 다시 만드는 처리를 했는데, 설정이 잘못되어 이 처리가 운영 환경의 모든 데이터셋에 실행됐다."},"severity":"unknown","symptoms":["data-loss"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"published","detection":{"en":"The system development division posted the first report of a BigQuery failure on Slack at 10:41, and its investigation found at 11:47 that the AI technology development team's service account had deleted the production datasets.","ko":"10:41 에 시스템 개발 본부가 Slack 에 BigQuery 에서 장애가 났다는 첫 보고를 올렸다. 11:47 에 시스템 개발 본부가 조사해 AI 기술 개발실의 서비스 계정이 운영 데이터셋을 지운 것을 찾았다."},"components":["database"],"root_cause":"human-operation","remediation":[{"text":{"en":"Restored the tables one at a time with bq cp in Cloud Shell from BigQuery time travel, to a point before the incident","ko":"Cloud Shell 에서 bq cp 명령에 장애 전 시점을 지정해 타임 트래블로 테이블을 하나씩 복원했고, 데이터 대부분을 잃지 않고 되살렸다."}},{"text":{"en":"Recreated views and table functions, which bq cp cannot restore, from the creation queries kept in BigQuery saved queries","ko":"bq cp 로 되살릴 수 없는 뷰와 테이블 함수는 BigQuery 의 저장된 쿼리에 남아 있던 생성 쿼리로 다시 만들었다."}}],"action_items":[{"text":{"en":"Enforce controls so that test code cannot access the production environment","ko":"테스트 코드가 운영 환경에 접근하지 못하게 확실히 막는다."}},{"text":{"en":"Remove the excessive permissions granted to the service account","ko":"서비스 계정에 주어져 있던 과한 권한을 정리한다."}},{"text":{"en":"Keep dataset and table information as managed metadata, because restoring with bq cp requires knowing the table names","ko":"bq cp 로 복원하려면 테이블 이름을 알아야 하므로, 데이터셋과 테이블 정보를 메타데이터로 관리한다."}},{"text":{"en":"Keep the creation queries of views and table functions in a place such as GitHub, because bq cp cannot restore them","ko":"bq cp 로는 뷰와 테이블 함수를 복원할 수 없으므로, 그 생성 쿼리를 GitHub 같은 곳에서 관리한다."}},{"text":{"en":"Consider how BigQuery should be backed up","ko":"BigQuery 의 백업 방식을 검토한다."}}],"contributing":["no-safeguard-on-destructive-change"],"recurrence_of":null,"symptoms_text":{"en":"On a day in August 2025, at 10:41, CareNet's system development division posted a first report on Slack that a failure was occurring in BigQuery, the production data warehouse. At 11:47 the division's investigation found that the production datasets had been deleted by a service account belonging to the AI technology development team.\n\nThe data warehouse is used for data analysis and is not connected to user-facing services; several departments share a single Google Cloud project to collect their data in it. At 11:00 the AI technology development team talked about the failure in a meeting but did not suspect its own team and only watched.\n\nAt 12:44 the system development division reported that an UNDROP SCHEMA query, the BigQuery feature for restoring a deleted dataset, did not work. The deleting process had created a new dataset with the same name right after deleting each one, and BigQuery appeared to treat the dataset to be restored as not existing.","ko":"2025년 8월 어느 날 10:41 에 시스템 개발 본부가 Slack 에 BigQuery 에서 장애가 났다는 첫 보고를 올렸다. 운영 데이터 웨어하우스의 데이터셋이 모두 지워져 있었다.\n\n11:00 에 AI 기술 개발실 회의에서 이 장애가 화제에 올랐지만, 이 팀은 자기들이 원인이라고 생각하지 못하고 지켜보기만 했다. 11:47 에 시스템 개발 본부가 조사해 AI 기술 개발실의 서비스 계정이 운영 환경의 데이터셋을 지운 것을 밝혀냈다.\n\n12:44 에 시스템 개발 본부가 데이터셋을 되살리려고 실행한 UNDROP SCHEMA 쿼리가 동작하지 않는다고 알렸다. 지워진 데이터셋과 같은 이름의 데이터셋이 곧바로 새로 만들어져 있어서, BigQuery 가 복원할 대상 데이터셋이 없다고 판단한 것으로 보였다.\n\n13:06 에 AI 기술 개발실이 Cloud Shell 에서 bq cp 명령을 쓰면 테이블 단위로는 복원할 수 있을지 모른다는 것을 알아냈다."},"updated_at":"2026-11-14T12:34:22.278207Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0576","org_slug":"carenet"}