Tales from the Machine Room

B come Backup, F come ....

Si, perche' in ogni caso la percentuale di successo e' la stessa.

Il problema pero' e' che tale bellissimo database era ospitato su un certo server che un bel giorno decise di prendersi una luuuuuunga vacanza, praticamente infinita.

La nostra societa' decise pertanto di acquistare un nuovo server e di riportare su tale server i dati che erano stati religiosamente backuppati fin dalla notte dei tempi su nastro.

Non ho ancora capito perche' (no, l'ho capito: perche' sono sfigato), ma pare che SL abbia una qualche parentela con l'SL di tale societa', pertanto indovinate chi e' lo sfigato che dovra tentare l'operazione di revitalizzazione del suddetto database?

SL - ...quindi si tratta solo di andare la e ripristinare i dati dal nastro di backup. Un giochetto da ragazzi.
IO - Se e' tanto 'giochetto da ragazzi' perche' non lo fanno da loro?
SL - Perche' vorrebbero avere una persona competente che sappia quello che fa.
IO - (sentendo puzza di bruciato come non mai) Ma non si tratta semplicemente di infilare il nastro e schiacciare un tasto?
SL - Be', si... no...
IO - Si o no?
SL - Innanzitutto si tratta di installare il database, poi si tratta di ripristinare i dati.
IO - Che database?
SL - Oracle.
IO - E ce l'hanno la licenza di Oracle?
SL - Hummm....

Eccolo! Lo sapevo io... Comunque, dopo un interminabile manfrina sul fatto che 'le licenze verranno acquistate al piu presto' (sic), decidiamo che andro la a vedere.

Eccomi quindi a consulto in questo posto... una mansarda con vista sulla stazione centrale di Amsterdam. E con me ci sono SL2, cioe' l'SL di $societa e CL, che sarebbe il facente-funzioni di BOFH se avesse una vaga idea di quello che sta facendo.

Dopo una mezz'oretta per installare Oracle siamo alla fase 'backup'.

IO - Ok, adesso si tratta di ripristinare i dati, dove sono i nastri?
CL - Eccolo (mi mette in mano un DDS-4).

Io osservo un po' il nastro che mi pare un po' vecchiotto, comunque lo schiaffo dentro e provo un bel tar tvf /dev/st0.

girvim scsi: [ID 107833 kern.notice] /pci@8,700000/scsi@6,1/st@3,0 (st0):
girvim Variable record length I/O
girvim glm: [ID 655122 kern.warning] WARNING: ID[SUNWpd.check_intcode.6006]
girvim scsi: [ID 107833 kern.warning] WARNING: /pci@8,700000/scsi@6,1 (glm1):
girvim Resetting scsi bus, data overrun: got too much data from target from (3,0)
girvim scsi: [ID 107833 kern.warning] WARNING: /pci@8,700000/scsi@6,1 (glm1):
girvim Target 3 reducing sync. transfer rate
girvim glm: [ID 923092 kern.warning] WARNING: ID[SUNWpd.glm.sync_wide_backoff.6014]
girvim scsi: [ID 107833 kern.warning] WARNING: /pci@8,700000/scsi@6,1/st@3,0 (st0):
girvim SCSI transport failed: reason 'reset': giving up

A questo punto guardo SL2 e CL che non hanno capito un gran che di quello che ho detto, ma hanno intuito che la fase di ripristino dei dati non sara' molto semplice...

IO - Ok, passiamo al nastro successivo!
CL - Quale nastro successivo?
IO - Be', mi pare che questo particolare nastro non sia molto contento di essere ripristinato, pertanto si tratta di prendere il nastro prima di questo.

CL ed SL2 si guardano...

CL - Ma non c'e' nessun'altro nastro...
IO - ??Come sarebbe a dire???
CL - Abbiamo sempre usato quel nastro per fare i backup.
IO - ??? Un solo nastro ??? Giorno dopo giorno dopo giorno? E non fate mai una specie di 'rotazione'?
CL - No. Dato che facciamo sempre un backup completo non ci e' sembrato necessario. Voglio dire, tanto si ripristina sempre dall'ultima volta e cosi' non perdiamo tempo a cambiare i nastri dato che il nastro e' sempre dentro.

...oddio...

IO - Hemmm... e... da quando e' che lo usate questo povero nastro?
SL2- Da quando abbiamo comperato il server, circa sei anni fa.
IO - Voi non avete mai provato un restore he?
CL - No, perche'?

Ok... Chi glielo dice?

Davide
06/01/2009

previous next