Tales from the Machine Room


Home Page | Comments | Articles | Faq | Documents | Search | Archive | Tales from the Machine Room | Contribute | Login/Register

Questions, questions, questions...

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 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.

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', 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

Previous Next

Comments are added when and more important if I have the time to review them and after removing Spam, Crap, Phishing and the like. So don't hold your breath. And if your comment doesn't appear, is probably becuase it wasn't worth it.

7 messages this document does not accept new posts
Mauro P By Mauro P - posted 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 By Guido - posted 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 By Anonymous coward - posted 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 By ringo - posted 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 By Messer Franz - posted 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 By spacexplorer - posted 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 By Uomo col banjo - posted 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 messages this document does not accept new posts

Previous Next


This site is made by me with blood, sweat and gunpowder, if you want to republish or redistribute any part of it, please drop me (or the author of the article if is not me) a mail.


This site was composed with VIM, now is composed with VIM and the (in)famous CMS FdT.

This site isn't optimized for vision with any specific browser, nor it requires special fonts or resolution.
You're free to see it as you wish.

Web Interoperability Pleadge Support This Project
Powered By Gojira