Restore

Sui backup si spendono fiumi di parole, eppure, non sempre è possibile eseguire un restore.

Questa volta è toccato a GitLab (qui la loro analisi post mortem), in attesa della prossima vittima.

Nell’incidente un tecnico ha cancellato dei dati di produzione il cui recupero si è rivelato impossibile nonostante i backup multipli, le sincronizzazioni, le repliche, gli snapshot, gli avvitamenti carpiati doppi con le supercazzole prematurate incrociate multiple.

Fare tanti backup non serve a nulla se non si può fare nessun restore. Sembra un’ovvietà, ma la realtà dei fatti dimostra che non sia un concetto così ovvio.

Ho visto strategie di backup assurdamente complesse eseguite con metodi tanto cervellotici quanto fragili, concepiti principalmente perché il SysAdmin potesse dimostrare a se stesso quanto fosse bravo a complicarsi la vita e ad uscirne più o meno indenne. Enfasi su meno.

Ho avuto anche un cliente il cui team IT si era inventato un turno a rotazione settimanale di 30 minuti di straordinario (pagati!) per poter concludere il backup prima dell’inizio del normale orario di lavoro.

Nel 90% dei casi il backup deve servire a due cose principali: recupero di un singolo dato in un punto del tempo ragionevole e recupero dell’intero server in un punto del tempo ragionevole.

Sono due necessità molto semplici la cui soluzione è semplice se si utilizzano gli strumenti adatti e, soprattutto, se si verificano i backup e le procedure.

Eventi come quelli di GitLab succedono perché si pensa più al backup che al restore.

La virtualizzazione e i software adatti (Veeam) hanno semplificato di molto il ripristino di un intero server o anche di un’intera infrastruttura.

Ho eseguito più volte il ripristino da zero attraverso Veeam B&R con a disposizione solamente un PC, le copie su un disco USB, un server piallato, un indirizzo di posta elettronica e una connessione a Internet. Si può fare perché è possibile scaricare da Internet le versioni gratuite sia di VMware ESXi sia di Veeam Backup & Replication e avere tutto l’occorrente per ripristinare l’infrastruttura.

Questo è un buon esercizio da fare ogni tanto quando, ad esempio, si scarta un vecchio server. Sono questi i momenti in cui si possono scrivere con tranquillità le procedure di ripristino e ci si allena per quando (quando, non se) il letame raggiunge il ventilatore.

In tema, spesso per rendersi la vita inutilmente complicata si inventano storage di backup assurdi, come device iSCSI montati con dedupliche prematurate o RAID esotici. Tutte queste cose in caso di disaster potrebbero non essere immediatamente disponibili, richiedere software specifici e allungare i tempi di ripristino.

KISS: Keep it simple, stupid!

Un consiglio: non escludete nulla dal backup, salvate sempre tutto. Gli storage a bassa performance per i backup costano poco, nel febbraio 2017 un hard disk Western Digital Red da 4 Tb costa € 160, uno da 6 Tb € 250 e uno da 8 Tb € 360. Quanto costa rifare un server da zero?

C’è una tendenza a non voler salvare un server perché “non è critico”, magari fa solo da printer server… Poi se si blocca si perde una settimana a ricostruire il server con tutti i driver e le configurazioni. Salvate sempre tutto. Magari i server meno importanti possono essere salvati una volta la settimana o una volta al mese, ma se gli utenti li utilizzano, devono essere salvati.

Un discorso diverso meritano i server online, dove non sempre è possibile avere una copia immagine del sistema, ma è solo possibile copiare dei file su un host remoto.

Anche qui vale la regola della semplicità e della linearità: tutti i dati in pochi posti, non sparsi per il file system, in modo che lo script di backup salvi automaticamente ogni nuovo dato.

In questo caso, il ripristino da crash del sistema operativo deve passare per forza dalla reinstallazione del software e il conseguente ripristino dei dati. Su Linux è un po’ più facile ripristinare utenti e gruppi con le relative password perché si tratta di tre file di testo; idem dicasi per le configurazioni dei programmi, tutte generalmente su file di testo oppure su file di testo e database SQL.

Anche per i server in hosting vale la regola della facilità del ripristino, in questo caso va aggiunta l’eventualità che si interrompa il servizio del fornitore. Quindi se il fornitore di hosting fornisce un servizio di backup presso le sue strutture, meglio avere anche una seconda copia altrove. Molto banalmente: se in caso di contenzioso il fornitore decide di chiudere o sospendere l’account, deve essere sempre possibile ripristinare il servizio altrove partendo dai backup.

Per ricordare l’incidente di GitLab controlliamo tutti che i nostri backup siano ripristinabili.