# Ένας μηχανικός διέγραψε τη βάση δεδομένων παραγωγής του GitLab. 300 gigabytes.

Published: 2026-09-10

31 Ιανουαρίου 2017, 23:27 UTC: ένας μηχανικός της GitLab, προσπαθώντας να επιδιορθώσει ένα χαλασμένο αντίγραφο στο τέλος μιας κουραστικής νύχτας, αφαιρεί τον κατάλογο δεδομένων PostgreSQL στο db1 αντί για το db2. Το db1 είναι το κύριο. Περίπου 300 GB της βάσης δεδομένων του GitLab.com εξαφανίζονται σε ένα ή δύο δευτερόλεπτα, και από τους πέντε μηχανισμούς αντιγράφων ασφαλείας και αναπαραγωγής, κανένας δεν λειτουργεί. Μεταθανάτια αναφορά: η χρονολογική σειρά από την αύξηση των ανεπιθύμητων μηνυμάτων έως το λάθος όνομα κεντρικού υπολογιστή, γιατί το pg\_basebackup φαινόταν κολλημένο, γιατί το pg\_dump αποτύγχανε σιωπηλά (δυαδικά αρχεία 9.2 σε βάση δεδομένων 9.6, μηνύματα ηλεκτρονικού ταχυδρομείου αποτυχίας που αναπηδούσαν από το DMARC), η αποκατάσταση 18 ωρών από ένα στιγμιότυπο staging 6 ωρών που μεταδιδόταν ζωντανά στο YouTube, και ποιος πραγματικά φταίει. Ετυμηγορία για την απόκριση: SHIP IT.

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

## Τι καλύπτει αυτό το βίντεο

- 31 Ιανουαρίου 2017: rm -Rvf στον κατάλογο δεδομένων του πρωτεύοντος· ~300 GB αφαιρέθηκαν, 4,5 GB έμειναν
- 5 από 5 εφεδρικά αντίγραφα αποτυγχάνουν: άδειο S3 bucket (αναντιστοιχία έκδοσης pg\_dump), καθόλου στιγμιότυπα Azure στη βάση δεδομένων, διαγραμμένο αντίγραφο, καθημερινή αντιγραφή LVM χωρίς webhooks
- 1 Φεβρουαρίου, 18:00 UTC: Το GitLab.com επανήλθε από ένα χειροκίνητο στιγμιότυπο 6 ωρών· ζωντανό έγγραφο, ζωντανή ροή, αναίτια μεταθανάτια αναφορά με λίστα επιδιορθώσεων

## Μεταφρασμένη μεταγραφή

Μεταφράστηκε από την πρωτότυπη αγγλική αφήγηση. Ο διαθέσιμος ήχος και οι υπότιτλοι ελέγχονται από το YouTube.

0:00 Ένας μηχανικός στην GitLab τρέχει rm -rf στον λάθος διακομιστή βάσης δεδομένων, και τριακόσια gigabytes του GitLab.com εξαφανίζονται σε ένα ή δύο δευτερόλεπτα, περίπου όσο χρειάζεται για να διαβάσει κανείς ένα όνομα κεντρικού υπολογιστή. 31 Ιανουαρίου 2017, 11:27 μ.μ. UTC. Η GitLab αναρτά στο Twitter ότι διέγραψε κατά λάθος δεδομένα παραγωγής, ανοίγει τις σημειώσεις συμβάντων της στο διαδίκτυο και μεταδίδει ζωντανά την αποκατάσταση στο YouTube, τη δεύτερη ζωντανή ροή στην πλατφόρμα. Την επόμενη μέρα, γραπτώς: από πέντε τεχνικές αντιγράφων ασφαλείας,

0:25 καμία δεν λειτουργεί αξιόπιστα. Πώς συμβαίνει, γιατί είναι δυνατόν, και ποιος πραγματικά φταίει. Αυτό είναι το The Daily Diff, μεταθανάτια αναφορά. 5:20 μ.μ.: ένας μηχανικός δημιουργεί στιγμιότυπο παραγωγής για να δοκιμάσει έναν εξισορροπιστή φορτίου στο staging. 7 μ.μ.: spam "σφυροκοπά" τη βάση δεδομένων, συν μια εργασία που διαγράφει οριστικά έναν υπάλληλο της GitLab, τον οποίο αναφέρθηκε από έναν τρολ για κατάχρηση. 11 μ.μ.: το αντίγραφο έχει μείνει τόσο πίσω που ο πρωτεύων έχει ήδη απορρίψει

0:48 το αρχείο καταγραφής που χρειάζεται· η μόνη λύση είναι να διαγράψετε το αντίγραφο και να αντιγράψετε τον πρωτεύοντα ξανά. Το pg\_basebackup κολλάει χωρίς έξοδο. Περιμένει στην πραγματικότητα, σιωπηλά, για τον πρωτεύοντα· κανείς δεν το γνωρίζει αυτό, και το εγχειρίδιο λειτουργίας δεν το αναφέρει. Ο μηχανικός, που σκόπευε να αποχωρήσει στις έντεκα, αποφασίζει ότι ο κενός κατάλογος δεδομένων είναι το πρόβλημα και τον αφαιρεί. Στο db1. Το πρωτεύον. Το αντιλαμβάνεται ένα ή δύο δευτερόλεπτα αργότερα· από περίπου τριακόσια gigabytes,

1:11 απομένουν 4,5. Τα αντίγραφα ασφαλείας. Ένα: pg\_dump σε S3, καθημερινά. Το bucket είναι άδειο. Η cron job τρέχει σε έναν διακομιστή εφαρμογών χωρίς βάση δεδομένων, οπότε το πακέτο επιλέγει δυαδικά αρχεία PostgreSQL 9.2 για μια βάση δεδομένων 9.6, αποτυγχάνει και στέλνει email την αποτυχία, η οποία αναπηδά λόγω έλλειψης DMARC. Δύο: Στιγμιότυπα δίσκου Azure, ενεργοποιημένα για τους διακομιστές αρχείων, όχι τις βάσεις δεδομένων.

1:32 Τρία: το αντίγραφο, διαγράφηκε επίτηδες πριν από μία ώρα. Τέσσερα: το καθημερινό στιγμιότυπο, 24 ωρών, με όλα τα webhooks αφαιρεμένα από τον συγχρονισμό staging. Πέντε: το χειροκίνητο στιγμιότυπο από τις 5:20, για μια άσχετη δοκιμή. Αυτό κερδίζει. Η επαναφορά σημαίνει αντιγραφή του δίσκου staging πίσω στην παραγωγή μέσω του φθηνού αποθηκευτικού χώρου της Azure στα εξήντα megabit ανά δευτερόλεπτο: δεκαοκτώ ώρες. Το GitLab.com επιστρέφει την 1η Φεβρουαρίου στις έξι μ.μ. UTC, έξι ώρες δεδομένων παλαιότερα.

1:58 git blame: δύο ονόματα κεντρικών υπολογιστών με διαφορά ενός χαρακτήρα, και πέντε συστήματα αντιγράφων ασφαλείας από τα οποία κανείς δεν έχει ποτέ κάνει επαναφορά. Όχι ο μηχανικός. Η μεταθανάτια αναφορά, υπογεγραμμένη από τον CEO, τον κρατά ανώνυμο, χρωματίζει την προτροπή παραγωγής κόκκινη και δίνει στην αντοχή των δεδομένων έναν ιδιοκτήτη, γιατί μέχρι τώρα δεν είχε κανένα. Ακτίνα έκρηξης: δεκαοκτώ ώρες κάτω, έξι ώρες δεδομένων χαμένα, περίπου πέντε χιλιάδες έργα, πέντε χιλιάδες σχόλια,

2:18 εφτακόσιοι νέοι χρήστες, και πέντε χιλιάδες άνθρωποι να παρακολουθούν μια γραμμή προόδου. Το Hacker News δίνει στο ζωντανό έγγραφο 1.162 πόντους και παραθέτει μία γραμμή πίσω σε αυτούς: από πέντε εφεδρικά αντίγραφα, κανένα. Ετυμηγορία, μεταθανάτια αναφορά: SHIP IT, για την απόκριση. Διαχειρίζονται το συμβάν δημόσια, κατηγορούν τη διαδικασία και δημοσιεύουν τη λίστα επιδιορθώσεων με αριθμούς ζητημάτων. Δράση Δευτέρας: επαναφορά αντιγράφου ασφαλείας. Αν δεν το έχετε επαναφέρει ποτέ, τότε δεν έχετε κανένα.

2:42 Στείλτε μου το συμβάν για το οποίο ακόμα δεν επιτρέπεται να μιλήσετε, στα σχόλια, ή στο the daily diff dot dev. Και αυτή είναι η διαφορά για σήμερα. Είμαι ο Νίκος από την Axrisi. Συγχωνεύστε υπεύθυνα.

## Πηγές

- [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