OVH down, incendio datacenter 🔥

matteocontrini dovreste sapere l'overkill che @francescotonini sta studiando per il backup di FibraClick da settimane (non che adesso non ne abbiamo, ma non siamo soddisfatti perché in casi come questo non vogliamo perdere più di un'ora di dati o giù di lì)

Visto il livello di interessi/curiosità/conoscenze di questo forum sarebbe super-interessante se una volta messo a regime faceste un post/pagina wiki su come funziona l'infrastruttura dietro FibraClick, con magari qualche consiglio di "best practice" da cui prensere ispirazione. Chiaro, sensa mettere a nudo ogni vulnerabilità, ma una piccola overview su come funzionano i backup per me sarebbe molto interessante (replicazione a livello di db? snapshot a livello di file o di blocchi? quali tecnologie di deduplicazione? quali policy di controllo consistenza/qualità dei backup...)

rsync incrementale ogni 5/15 (in base al carico) minuti per i file e master/slave live-replication per il db non credo sia battibile

mpanella le altre opzioni le intendevo per tutto quello che non è database, magari in più di rsync si può fare una retention delle vecchie versioni (ma in uno scenario disaster recovery in effetti me ne basta una e buona, a meno che il disaster non sia un rm -rf /data/* 5 secondi prima del backup ).

Per i db io ora faccio un pg_dump giornaliero, ma sono ben consapevole che se il DB crescesse troppo diventerebbe abbastanza proibitivo, e dovrei capire come usare le impostazioni di replicazione/ridondanza interne di postgres.

(Non so, incendio-backup sono indissolubilmente legati, ma forse sto andando un po' OT)

lore20 dovrei capire come usare le impostazioni di replicazione/ridondanza interne di postgres.

Sono una boiata da implementare. 15 minuti compreso il tempo di lettura della wiki.

mpanella a meno che non mantieni WAL segment a sufficienza per fare point-in-time recovery.

Beh non è esageratamente oneroso da fare per quello...

lore20 Visto il livello di interessi/curiosità/conoscenze di questo forum sarebbe super-interessante se una volta messo a regime faceste un post/pagina wiki su come funziona l'infrastruttura dietro FibraClick, con magari qualche consiglio di "best practice" da cui prensere ispirazione. Chiaro, sensa mettere a nudo ogni vulnerabilità, ma una piccola overview su come funzionano i backup per me sarebbe molto interessante (replicazione a livello di db? snapshot a livello di file o di blocchi? quali tecnologie di deduplicazione? quali policy di controllo consistenza/qualità dei backup...)

In questo periodo la nostra infrastruttura è tutto un work in progress perché stiamo rivedendo un po' tutto (spostiamo cose tra server, rivediamo il sistema di backup, pianifichiamo cose per sostituire Cloudflare, valutiamo Docker per PHP, ecc.), però a un certo punto potremmo scrivere un po' di com'è l'infrastruttura consapevoli però che sicuramente ci sono cose che non vanno quindi potremmo prenderci insulti per qualche cosa

Se potessi metterei pubblica anche tutta la configurazione del sistema anti-DDoS L7 che stiamo preparando, ma non è il caso...

Sui backup quoto:

mpanella OT: Block-level snapshot e database non vanno tanto d'accordo

Si usano tool specifici che fanno una copia consistente a livello di database. Altrimenti poi ti trovi un backup corrotto, oppure l'SQL generato viola vincoli di integrità referenziale e devi pastrocchiare a mano per farlo funzionare.

Purtroppo per il forum siamo vincolati a MySQL che è un po' tricky da backupare, ora andiamo di mysql_dump eseguito periodicamente (+restic per renderlo incrementale) perché comunque impiega pochi secondi, però locka l'intero database finché non ha finito per garantire un backup consistente (se non ricordo male, se ne occupa Francesco dei backup). Ci sono soluzioni migliori che raccolgono i "log" di quello che è stato scritto nel frattempo, e poi aggiornano il dump considerando questi log. E su questo stiamo lavorando, in modo da avere backup incrementali mooolto frequenti + un dump full ogni X ore e un backup "fallback" con il sistema vecchio ogni tanto, giusto perché non si sa mai... Il tutto caricato off-site verso più destinazioni a prova di incendi multipli contemporanei. Non abbiamo ancora un piano per la verifica della correttezza dei backup, faccio solo un restore manuale ogni tanto in locale.

Per i file che non sono database, usiamo restic, incrementale ogni 3 ore se non sbaglio, con retention sempre meno frequente più si va indietro (uguale rispetto al db).

Per il database PostgreSQL di TrackBot usiamo il db managed di DigitalOcean che ha il suo point-in-time recovery, e facciamo anche un dump con pg_dump ogni X ore (non mi ricordo la X).

...quando ho iniziato il messaggio l'idea non era spiegare tutto, ma poi ho spiegato tutto

matteocontrini Prima linea per cavolate applicative, ultima in caso di problemi infrastrutturali (sarebbero dovuti morire tutti e tre i nodi del cluster per dover andare a riprendere da tape i backup).

---EDIT---
In realtà le cavolate applicative ci preoccupavano poco e niente, visto che su quel cluster giravano i db di un'installazione Openstack. Una cavolata applicativa avrebbe avuto riflessi poco simpatici anche e soprattutto per le VM utente, il db sarebbe stato l'ultimo dei problemi

Video aggiornamento da Octave Klaba

Spiega anche un po’ cosa sanno fino ad ora riguardo le cause. I VVFF hanno visto con le termocamere che gli UPS n. 7 e 8 avevano preso fuoco. OVH aveva effettuato manutenzione sull’UPS n. 7 la mattina prima dell’incendio.

Matthew18_ Mi hai anticipato stavo cercando di capire cosa dicesse tra il suo bellissimo frenglish e l’audio terribile super compresso