Storie dalla Sala Macchine


Home Page | Commenti | Articoli | Faq | Documenti | Ricerca | Archivio | Storie dalla Sala Macchine | Contribuire | Imposta lingua:en it | Login/Register


Domande domande domande...

E' un mercoledi' come tanti altri, il che significa noioso e piovoso, quando una mail turba la pace della mia casella di posta. E' di SL, quello di $noiguardiamolavostrarobba, quello che voleva fare tutto da solo per risparmiare (tempo e soldi, soprattutto soldi) ed ha finito con lo spendere molto di piu' tempo e molti ma molti piu' soldi di quanto possa fare piacere a chiunque, il quale e' preoccupato perche' durante il recente Grande MacelloRilascio, il backup che aveva fatto del database si e' rivelato totalmente inutile.

Ho come la vaga impressione che il backup stesse occupando troppo tempo e sia stato semplicemente interrotto a meta', dal cui la sua inutilita' quando hanno cercato di fare un restore, ma sto' divagando.

In ogni caso, adesso SL si sta domandando (e domandandolo a me ovviamente) quale sarebbe il miglior modo di fare un backup "funzionante" come lo definisce lui, che consenta un ripristino dei dati in caso di catastrofe e richieda poco, anzi pochissimo, anzi niente tempo per essere generato ed usato e se posso fare un esempio di comando da usare.

Qualche cosa mi fa pensare che SL stia cercando di aggirare le limitazioni che lui stesso ha richiesto al suo contratto di assistenza facendo domande apparentemente innocue ed innocenti.

Dopo averci pensato un po' decido di rispondere con una risposta abbastanza generica che non contenga ne' troppe imprecisioni ne' troppe informazioni dettagliate, suggerendogli di leggersi la documentazione e che prima di pensare a linee di comando e come fare le cose dovrebbe schiarirsi le idee sul cosa fare.

La faccenda ovviamente non si e' fermata li'. E dopo un po' DB e' balzato al comando ed ha proposto un bell'incontro faccia a faccia. Il che significa un bel meeting (<sarcasmo>quanto mi mancavano!</sarcasmo>) per discutere le "modalita' di ottimizzazione del sistema"... qualunque cosa voglia dire (tipo: far fare le cose a chi sa farle?). Partecipanti al pistolotto: DB ed IO da una parte, SL ed UL dall'altra. Qualche cosa mi fa pensare che adesso sappiamo anche chi e' il misterioso programmatroto responsabile di tutto il gran casotto.

SL - ...e quindi vorrei sapere come ottimizzare il backup.
IO - Il backup viene gia' fatto dal nostro sistema tutte le notti e trasferito off-site, se quello che vi serve e' una copia possiamo anche inviarvene una al mattino.
SL - Ma quel backup che voi fate contiene tutto il database! A me serve solo un backup del database $taldetali
IO - Possiamo schedulare un backup separato per quello.
SL - Ma mettiamo che io voglia farlo al momento, che parametri devo mettere? Per esempio i parametri --pippo e --pluto e' meglio metterli o no?
IO - A parte che non ho idea di che cosa facciano, ma in genere, se un parametro non e' di default e non si sa se serve o meno e' meglio non usarlo.
SL - Ma voi li usate?
IO - Non so nemmeno a che servono, dovrei guardare la documentazione, ma qualche cosa mi dice che no, non li usiamo.
SL - Ma per esempio, se io non faccio il backup compresso mi viene un backup di 7 Gb, che non so dove mettere, se pero' lo comprimo ci mette una vita, io vorrei fare una cosa veloce...
IO - "veloce" e "compresso" nella stessa frase non funzionano.
SL - Ma se io uso $unqualchetoolmaisentito lui mette automaticamente queste opzioni, perche'?
IO - Magari dovresti domandarlo a chi ha scritto il tool. Probabilmente perche' lui pensava servissero.
SL - Ma insomma, queste opzioni devo metterle o no?
IO - Come gia' detto, se le opzioni servono si mettono, se no non si mettono. Il punto e' che voi non avete ancora spiegato cosa volete farci con questo backup.
SL - Allora, io vorrei avere una copia del database sul nostro sistema di sviluppo per fare le prove e poi se qualche cosa va male durante un rilascio vorrei poter fare un rename e rimettere a posto il database! Come faccio?
IO - Per prima cosa, non potete fare un 'rename' del database perche' non funziona cosi', il database deve per forza essere ricostruito dal backup, per seconda cosa, tenere in sync due database e fare un backup "al momento" per un rilascio sono due problemi separati, nel primo caso si potrebbe usare un sistema di sincronismo o replicazione, ma stento a proporlo dato che il vostro database e' gia' abbastanza carico e nel secondo caso e' molto meglio non usare compressioni di sorta perche' aumenta il tempo richiesto. Quindi quei parametri di cui parlate vanno uno in conflitto con l'altro.
SL - Ma allora perche' $toolmaisentitoprima li mette sempre?
IO - Non lo so, domandatelo a chi lo ha scritto.
SL - E non potete fare voi uno script che noi possiamo usare per fare il backup?
IO - guardando DB hmmm?
DB - Questo e' sicuramente possibile ma si tratta di sviluppo e non e' coperto dal vostro contratto di assistenza.
SL - Ma e' uno script!

A questo punto hanno cominciato a cavillare di tempi, livelli e cose cosi' ed io mi sono limitato a guardarli e pensare che a volte, per risparmiare si finisce con lo spendere troppo.

Davide
28/05/2012 08:00

Precedente Successivo

I commenti sono aggiunti quando e soprattutto se ho il tempo di guardarli e dopo aver eliminato le cagate, spam, tentativi di phishing et similia. Quindi non trattenete il respiro.

7 messaggi this document does not accept new posts

Mauro P

Di Mauro P postato il 28/05/2012 08:51

"a volte, per risparmiare si finisce con lo spendere troppo."

Correggerei la frase con "a volte, per risparmiare, senza sapere cosa e come si vuole, si finisce con lo spendere troppo."

Oppure "GNURANT!"

Ciao DigD buon inizio di settimana e grazie per le storie.

-- Mamo

Guido

Di Guido postato il 28/05/2012 09:06

risposta abbastanza generica che non contenga ne' troppe imprecisioni ne' troppe informazioni dettagliate, suggerendogli di leggersi la documentazione

 

quindi sostanzialmente la risposta era RTFM... ;

-- salva un albero: mangia un castoro!

Anonymous coward

Di Anonymous coward postato il 28/05/2012 09:14



In ogni caso, adesso SL si sta domandando (e domandandolo a me ovviamente) quale sarebbe il miglior modo di fare un bacup "funzionante" come lo definisce lui, che consenta un ripristino dei dati in caso di catastrofe e richieda poco, anzi pochissimo, anzi niente tempo per essere generato ed usato e se posso fare un esempio di comando da usare.

il comando e':

backup --source /path/contenente/db --destination /path/destinazione/ --name nome/backup --speed faster-than-light --option miracle-on --mother-of-god please-help-me

purtroppo poi compare il messaggio di errore: Error! system unable to manage foolish user!

DB - Questo e' sicuramente possibile ma si tratta di sviluppo e non e' coperto dal vostro contratto di assistenza.

SL - Ma e' uno script!

cosa c'era nella testa di BigD: E allora fatevelo da soli, brutti stroxxi!

cosa c'era nella testa di DB: caro braccio-corto, la competenza si paga.

-- Anonymous coward

ringo

Di ringo postato il 28/05/2012 14:44

Fattura per uno script!

Tempo per fare lo script:___€ 1

Essere capaci di farlo_____€ 999

Totale_________________€ 1000

Iva 21%_______________ € 210

Da pagare sull'unghia____ € 1210

Consegna a 30 giorni dal saldo della presente.

-- ringo

Messer Franz

Di Messer Franz postato il 28/05/2012 19:53

cit>$toolmaisentito prima lo fa!

 

soluzione : informarsi su $toolmaisentitoprima , rintracciare l'autore , picchiarlo a morte.

passare a tool sucessivo.

 

procedere fino ad esaurimento tool su internet

morire per superlavoro (ammazzare stanca ) stanchi ma felici

-- Messer Franz

spacexplorer

Di spacexplorer postato il 28/05/2012 21:08

Ma guardi, allora, per aumentare la velocità servono degli SSD

molto grandi, FC o Infiniband, un bel po' di CPU e RAM, diciamo

sui 30.000-50.000€ chiavi in mano. Va bene?

In alternativa, per grossomodo la stessa cifra, si può riscrivere

la spa^H^H^Happlicazione attuale come si deve facendola poi

girare sullo stesso hw con un aumento prestazionale eguale o

superiore...

Dalle mie parti con discorsi simili si taglia ogni discussione :-\)

-- spacexplorer

Uomo col banjo

Di Uomo col banjo postato il 29/05/2012 09:08

Davide, posso segnalarti questa striscia di Dilbert?

 

http://dilbert.com/strips/comic/2012-05-25/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+DilbertDailyStrip+%28Dilbert+Daily+Strip%29s

Per future riunioni:

quale sarebbe il miglior modo di fare un bacup "funzionante" come lo definisce lui, che consenta un ripristino dei dati in caso di catastrofe e richieda poco, anzi pochissimo, anzi niente tempo per essere generato ed usato e se posso fare un esempio di comando da usare.

 

"Virtualizziamo il processo e mettiamolo sul cloud!"

-- Uomo col banjo

7 messaggi this document does not accept new posts

Precedente Successivo


Il presente sito e' frutto del sudore della mia fronte (e delle mie dita), se siete interessati a ripubblicare uno degli articoli, documenti o qualunque altra cosa presente in questo sito per cortesia datemene comunicazione (o all'autore dell'articolo se non sono io), cosi' il giorno che faccio delle aggiunte potro' avvisarvi e magari mandarvi il testo aggiornato.


Questo sito era composto con VIM, ora e' composto con VIM ed il famosissimo CMS FdT.

Questo sito non e' ottimizzato per la visione con nessun browser particolare, ne' richiede l'uso di font particolari o risoluzioni speciali. Siete liberi di vederlo come vi pare e piace, o come disse qualcuno: "Finalmente uno dei POCHI siti che ancora funzionano con IE5 dentro Windows 3.1".

Web Interoperability Pleadge Support This Project
Powered By Gojira