Il caso GitLab: il restore è importante tanto quanto il backup

by Diego Pierangeli on 3 febbraio 2017

Mercoledì mattina una parte del mondo degli sviluppatori si è svegliato con una brutta notizia: GitLab, una piattaforma di gestione del codice usata da molte aziende (ad esempio Codepen e Vaadin) ha avuto un problema nella gestione del suo database, perdendo tutte le operazioni fatte nelle ultime sei ore di martedì 31 gennaio. Ho trovato molto interessante il loro articolo con la descrizione di quello che è successo.

A parte il problema iniziale (attacco DDoS) e l’errore tecnico (delete della cartella /Data/ di Postgres fatto sul database sbagliato – andatevi a leggere perché è successo, non si dovrebbe mai lavorare fino a tardi 🙂 ) il problema vero a mio parere è avvenuto con le procedure di backup/restore che non hanno funzionato a dovere, ad esempio:

  • Snapshot del file system fatto solo ogni 24 ore.
  • Backup del database fatto solo ogni 24 ore, senza che i tecnici fossero informati sulla dislocazione del backup, e in più non funzionante con un file di backup di pochi byte a fronte di un database di 300GB.
  • Snapshot dei dischi non impostato in Azure.
  • Backup su Amazon S3 non funzionante (bucket vuoto).
  • Dump di postgres non funzionante a causa di un errore di versione.

Tutto questo ha obbligato i tecnici ad usare un altro tipo di backup risalente a 6 ore prima, perdendo quindi una parte dei dati.

Quello che secondo me si può imparare da questa disavventura (che in realtà può capitare ovunque e a chiunque) è che non è sufficiente impostare dei meccanismi di backup e restore, è necessario testarli e manutenerli, verificando che le procedure messe in atto funzionino bene e siano in grado di ripristinare i dati. Questo va fatto periodicamente, altimenti c’è il rischio che aggiornamenti o problemi tecnici impattino sulla capacità di recuperare i dati in caso di necessità.

Proprio per evitare problemi di questo genere la politica di backup di Instant Developer Cloud esegue snapshot orari dell’intero server che quindi possono essere ripristinati in sicurezza.

A voi è mai capitato di dover gestire una situazione come questa?

{ 1 comment… read it below or add one }

1 Francesco Apicella 4 febbraio 2017 alle 14:14

I dati possono essere ovunque ma la mia posizione è questa !!!!

Gli utenti si dividono in due categorie quelli che hanno perso i dati e quelli che ancora no, tu a quale categoria appartieni ?

Se appartieni alla prima suppongo che sei già organizzato altrimenti affrettati perchè perdere dei dati dopo un duro lavoro può essere davvero traumatico.

Leave a Comment

Previous post:

Next post: