# Un ingegnere ha eliminato il database di produzione di GitLab. 300 gigabyte.

Published: 2026-09-10

31 gennaio 2017, 23:27 UTC: un ingegnere di GitLab, alle prese con una replica rotta alla fine di una lunga notte, rimuove la directory dei dati di PostgreSQL su db1 invece di db2. db1 è il primario. Circa 300 GB del database di GitLab.com scompaiono in uno o due secondi, e dei cinque meccanismi di backup e replica, nessuno funziona. Postmortem: la cronologia dal picco di spam al nome host sbagliato, perché pg\_basebackup sembrava bloccato, perché pg\_dump falliva silenziosamente (binari 9.2 su un database 9.6, e-mail di errore respinte da DMARC), il ripristino di 18 ore da uno snapshot di staging di 6 ore trasmesso in diretta su YouTube, e chi è veramente il responsabile. Verdetto sulla risposta: SHIP IT.

Canonical: https://thedailydiff.dev/it/video/2026-09-10-gitlab-rm-rf/

## Contenuto di questo video

- 31 gennaio 2017: rm -Rvf sulla directory dei dati del primario; ~300 GB rimossi, 4,5 GB rimasti
- 5 backup su 5 falliscono: bucket S3 vuoto (mancata corrispondenza della versione di pg\_dump), nessuno snapshot Azure sul DB, replica cancellata, copia LVM giornaliera senza webhook
- 1 febbraio, 18:00 UTC: GitLab.com di nuovo online da uno snapshot manuale di 6 ore; documento live, streaming live, postmortem senza colpe con una lista di correzioni

## Trascrizione tradotta

Tradotto dalla narrazione originale inglese. L'audio e i sottotitoli disponibili sono controllati da YouTube.

0:00 Un ingegnere di GitLab esegue rm -rf sul server di database sbagliato, e trecento gigabyte di GitLab dot com svaniscono in uno o due secondi, circa il tempo necessario per leggere un nome host. 31 gennaio 2017, 23:27 UTC. GitLab twitta di aver accidentalmente eliminato dati di produzione, apre le sue note sull'incidente a internet e trasmette il recupero su YouTube, la seconda trasmissione in diretta più vista sulla piattaforma. Il giorno dopo, per iscritto: su cinque tecniche di backup,

0:25 nessuna funziona in modo affidabile. Come succede, perché è possibile e chi è effettivamente il responsabile. Questo è The Daily Diff, postmortem. 17:20: un ingegnere fa uno snapshot della produzione per testare un bilanciatore di carico in staging. 19:00: lo spam martella il database, più un lavoro che elimina definitivamente un dipendente di GitLab segnalato da un troll per abuso. 23:00: la replica è talmente indietro che il primario ha già scartato

0:48 il log di cui ha bisogno; l'unica soluzione è cancellare la replica e copiare il primario di nuovo. pg\_basebackup si blocca senza output. In realtà sta aspettando, silenziosamente, il primario; nessuno lo sa, e il runbook non lo dice. L'ingegnere, che intendeva smettere alle undici, decide che la directory dei dati vuota è il problema e la rimuove. Su db1. Il primario. Se ne accorge uno o due secondi dopo; di circa trecento gigabyte,

1:11 ne rimangono 4,5. I backup. Uno: pg\_dump su S3, giornaliero. Il bucket è vuoto. Il cron job viene eseguito su un server applicativo senza database, quindi il pacchetto seleziona binari PostgreSQL 9.2 per un database 9.6, fallisce e invia un'e-mail del fallimento, che viene respinta per DMARC mancante. Due: snapshot del disco Azure, abilitati per i file server, non i database.

1:32 Tre: la replica, cancellata di proposito un'ora fa. Quattro: lo snapshot giornaliero, vecchio di 24 ore, ogni webhook rimosso dal sync di staging. Cinque: lo snapshot manuale delle 17:20, per un test non correlato. Questo vince. Ripristinare significa copiare il disco di staging in produzione tramite lo storage economico di Azure a sessanta megabit al secondo: diciotto ore. GitLab dot com è di nuovo online il 1° febbraio alle 18:00 UTC, sei ore di dati più vecchi.

1:58 git blame: due nomi host distanti un carattere, e cinque sistemi di backup da cui nessuno ha mai ripristinato. Non l'ingegnere. Il postmortem, firmato dal CEO, lo mantiene anonimo, colora di rosso il prompt di produzione e assegna la durabilità dei dati a un proprietario, perché fino ad ora non ne aveva nessuno. Raggio d'azione: diciotto ore di inattività, sei ore di dati persi, circa cinquemila progetti, cinquemila commenti,

2:18 settecento nuovi utenti e cinquemila persone che guardano una barra di avanzamento. Hacker News dà al documento live 1.162 punti e ne cita uno linea indietro: su cinque backup, nessuno. Verdetto, postmortem: SHIP IT, sulla risposta. Gestiscono l'incidente in pubblico, incolpano il processo e pubblicano la lista di correzioni con i numeri di emissione. Azione del lunedì: ripristinare un backup. Se non l'hai mai ripristinato, non ne hai uno.

2:42 Inviami l'incidente di cui non ti è ancora permesso parlare, nei commenti, o a the daily diff dot dev. E questa è la differenza per oggi. Sono Niko di Axrisi. Merge responsabilmente.

## Fonti

- [GitLab, "Postmortem of database outage of January 31" (Feb 10, 2017)](https://about.gitlab.com/blog/postmortem-of-database-outage-of-january-31/) — about.gitlab.com
- [GitLab, "GitLab.com database incident" (Feb 1, 2017)](https://about.gitlab.com/blog/gitlab-dot-com-database-incident/) — about.gitlab.com
- [@gitlabstatus, "We accidentally deleted production data…"](https://twitter.com/gitlabstatus/status/826591961444384768) — twitter.com
- [@gitlabstatus, emergency maintenance notice](https://twitter.com/gitlabstatus/status/826572933304827904) — twitter.com
- [Hacker News, "GitLab Database Incident – Live Report" (1,162 points, 598 comments)](https://news.ycombinator.com/item?id=13537052) — news.ycombinator.com
- [Hacker News, the postmortem thread (377 points)](https://news.ycombinator.com/item?id=13619714) — news.ycombinator.com