...di 28 c'e' ne uno...
Il backup e' bello, il backup e' buono, ma bisogna farlo e bisogna anche provarlo. E soprattutto, bisogna averlo, perche' se lo fai e poi lo butti via non e' che ti serva ad un gran che.
Quando il mondo era piu' giovane ed il backup veniva fatto su quelle cose magiche e misteriose chiamate NASTRI, che oggi se ne parli ti guardano come se tu fossi un marziano arrivato ... da marte appunto. Oeh', giovini, non avete mai visto Guerre Stellari? Anche i piani della morte nera erano su NASTRI, una tecnologia che produce astronavi piu' veloci della luce che usa i nastri come sistema di memoria di massa. Vabbe'.
Comunque sia, quando si usavano i nastri per il backup, di solito quello che si faceva era fare molteplici copie e tenerle per diverso tempo. C'erano i nastri del backup giornaliero, poi c'erano quelli del backup settimanale e poi di quello mensile. Cosi' si poteva andare indietro nel tempo e recuperare le cose in diversi momenti, se qualche cosa era stata zappata via la settimana precedente, si andava a cercare sul backup di 2 settimane prima e cosi' via. Il che significava TANTI nastri ed organizzati bene.
Ficcare dentro i nastri del giorno prima invece di quelli della settimana prima significava vivere nel terrore per una settimana che qualcuno venisse a chiedere un restore proprio di quel giorno... cosa che capitava semiregolarmente (come Murphy insegna).
Ovviamente i nastri costavano un botto ed usavano tanto spazio che avrebbe potuto essere usato per altre cose. Ma se vuoi una certa sicurezza dei dati...
Oggi... Oggi e' tutto "cloud". Il che significa che anche i backup sono "nelle nuvole". Il che puo' essere un bene o un male. Dipende da come lo si vede.
Dalla parte "bene", fare i backup adesso significa, nella maggioranza dei casi, mettere la spunta in una casellina che dice "fai uno snapshot della macchina ogni X ore" e non pensarci piu'.
Dall'altra parte, che sarebbe "male", significa che quando devi andare a fare un restore devi studiarti la documentazione per scoprire: dove stracazzo si trova il tuo snapshot, come stracazzo si adopera e se riesci a trovare il singolo file che devi restorare o ti tocca ripristinare tutta la macchina prima, con connesso consumo di tempo, caffe' e madonne assortite.
Oh, e bisogna anche fare caso a quanto spazio occupano questi "snapshot", prima di vedersi recapitare una fattura astronomica per "spazio di archivio".
E questo ci porta a parlare dell'argomento del giorno: la ritenzione. Che no, non e' una parolaccia e non ha a che fare con il bere troppa acqua, ma con il fatto che i dati "poco utili", siano essi vecchi backup o vecchi log, devono essere tenuti per un certo tempo, ma poi possono essere eliminati perche' sono inutili ed occupano spazio inutilmente.
Ora, ognuno ha i propri sistemi per gestirsi la ritenzione dei dati, c'e' chi costruisce un mostruoso script/programma che invia dozzine di "reminder" e sposta roba dentro e fuori da archivi, cold-storage, warm-storage, so-so-storage prima di buttare il tutto nel tritarifiuti, chi si gestisce le cose a mano (se sono poche)... e chi, nella maggioranza dei casi, se ne frega finche' qualche cosa non scoppia.
E parlando di scoppia, parliamo di $contiESconti, una azienda che gestiva "voucher" e "buoni sconto" vari.
Questa gente aveva un sistema basato su un sito web che pareva progettato da qualcuno troppo abituato a lavorare in Fortran. Per prima cosa, ogni volta che veniva fatta una modifica su una tabella del database, la tabella veniva copiata e la data del giorno veniva aggiunta al nome della tabella. Il programma era fatto in maniera tale da usare l'ultima tabella disponibile. Il che significa che nel database si trovavano ennemila tabelle "Utenti_XXXXYYZZ", ennemila tabelle "Prodotti_XXXXYYZZ", ennemila... ok, avete capito.
Una volta al mese, un qualche povero tapino doveva preparare la "fatturazione", che serviva per mandare le varie fatture ai clienti e beccare la grana. Una attivita' estremamente importante quindi. Attivita' che consisteva nel far girare uno script, che si passava a ramazza il database e produceva un mastodontico file .csv, che poi doveva essere elaborato con Excel per essere "tagliato" a pezzi, ogni singolo pezzo doveva poi essere manipolato per aggiungere o togliere costi, sconti e roba varia. Poi tutto il marasma veniva scaricato dentro una particolare directory dove un altro script lo rimaneggiava e produceva ennemila fatture da inviare ai clienti.
Come si puo' intuire, questa procedura era lunga, laboriosa e portata ad incasinamenti, soprattutto nella fase finale che tendeva anche ad incatastarsi parecchio. Il guaio e' che una volta iniziata, l'unico modo per ripetere l'intera cosa era ripristinare il database al momento PRIMA dell'inizio dell'intera faccenda, perche' la fase di "ramazza" alterava anche i dati all'interno del sistema producendo altre millemila tabelle con nomi astrusi.
Ecco quindi che qualcuno, dotato di molto cervello, aveva suggerito a $contiESconti di utilizzare una "ritenzione" dei backup di almeno 30 giorni, in modo da poter ritornare ai dati del mese precedente nel caso vi fossero dei problemi.
Arriviamo ad un bel giorno quando $contiESconti apre un ticket esagitato per chiedere un ripristino del database all'ultimo giorno di 2 mesi prima. Il nostro CL butta un'occhio alla mail e risponde tutto tranquillo che il periodo di ritenzione e' di 30 giorni e quindi non e' possibile fare il ripristino, e chiude il ticket piu' veloce di Lucky Luke.
30 secondi dopo comincia a suonare il telefono ovviamente. Ed a questo punto cominciano i dolori. Dolori perche' $contiESconti insiste che, se la "ritenzione" e' di 30 giorni, ed e' il 1o di Marzo, i dati del 30 e 31 Gennaio dovrebbero essere ancora disponibili (essendo Febbraio solo di 28 giorni). E la matematica gli da' ragione.
Tuttavia non posso fare a meno di notare che lo snapshot non e' piu' li'. In effetti... NON CI SONO SNAPSHOT DI SORTA per $contiESconti. Che cappero succede? Chiaramente le geremiadi attraggono l'attenzione di $DB, se non le geremiadi le ripetute mail inviate a tutti quelli che potevano essere contattati.
Ed e' a questo punto che mi metto a guardare il mastodontico script di "backup" (o presunto tale) e scovo l'arcano:
Lo script dovrebbe fare un calcolo $dataultimobackup=$datadelgiorno - $giorniritenzione, ma apparentemente il CL che ha scritto questa cosa non era molto bravo con le funzioni di gestione delle date, per cui ha deciso di tagliare corto e fare $dataultimobackup=$primodelmese. Attenzione $primodelmese, non $primodelmeseprecedente. Il che significa che al primo del mese tutto quello che e' piu' vecchio e' fritto. E quindi la ritenzione e' di un mese fino alla fine del mese e poi diventa zero.
Ed ecco perche' fare il backup e' solo il primo passo, bisogna anche provarlo poi.
Davide
23/04/2019 15:56
) con un'unità di backup in grado di gestire quelle cartucce.
