Periferiche SCSI e backup
Indice
- Introduzione
- SCSI: qualche dettaglio preliminare
- Un esempio completo
- Configurazione del Kernel
- Strumenti pronto uso
- Backup e gestione nastri
- Conclusioni
Introduzione
Comprendere a fondo l'importanza dei backup è
sicuramente una delle priorità per chiunque voglia
mettersi al riparo da perdite improvvise di dati
importanti.
Ma quando parliamo di backup, a cosa ci riferiamo
precisamente?
Spesso lo consideriamo come un mero accorgimento tecnico,
finalizzato allo storage dei dati...niente di più, niente
di meno.
Una considerazione del genere può trovare parziale
accoglimento in situazioni casalinghe, sicuramente non in
situazioni di produzione, dove invece tale discorso andrebbe
rivalutato alla stregua di una vera e propria pianificazione, di
tutti i dettagli più importanti.
Dato che parlare in maniera generalizzata non è lo scopo diretto di questo articolo ci soffermeremo solamente sui dettagli riguardanti la configurazione da adottare e l'hardware da utilizzare: Linux e le periferiche SCSI.
SCSI: qualche dettaglio preliminare
Prima di tutto è necessario fare alcune considerazioni in merito, per avere un quadro chiaro sin dall'inizio.
Cos'è lo SCSI e quali sono i motivi che ci
spingono ad utilizzarlo.
Quali accorgimenti adottare lato periferiche.
Quali accorgimenti adottare lato Sistema Operativo.
Lo SCSI (Small Computer Systems Interface) è una particolare interfaccia che garantisce la comunicazione tra il sistema operativo e le periferiche che supportano tale tecnologia (dischi fissi, CD-ROM e masterizzatori, periferiche di storage).
Nonostante i produttori Hardware abbiano fatto negli ultimi
anni degli sforzi enormi per migliorare la tecnologia EIDE, lo
SCSI rimane di fatto il sistema preferibile: elevato Throughput ,
affidabilità, resistenza nel tempo.
Esistono diverse tipologie di SCSI (SCSI-1, SCSI-2, FAST WIDE
ecc...) ognuna con peculiarità diverse; nel nostro caso
utilizzeremo lo SCSI Standard, cioè con collegamento FLAT
50 pin, nonostante il nostro controller supporti anche ULTRA WIDE
SCSI a 68 pin.
Sia per il controller (generalmente una scheda ISA o PCI), sia
per la periferica che intendiamo collegare, è necessario
eseguire una piccola configurazione tramite dei
`dip switch` o `jumpers` posti su entrambi i componenti atti a
garantirne il corretto funzionamento.
NOTA: si ricordi che generalmente l'identificazione del
controller è già impostata di fabbrica ( ID 7 ),
pertanto la configurazione di quest'ultimo non è
strettamente necessaria.
Vediamo quindi in cosa consiste questa configurazione.
Osservando attentamente la nostra periferica nella parte
posteriore, troviamo come nel caso dell'EIDE, una fila di
jumpers.
Da sinistra verso destra i jumpers che ci interessano
maggiormente sono i primi tre, che impostano l'ID univoco delle
periferica all'interno della catena SCSI, e gli ultimi due di
terminazione e di parità.
NOTA: la disposizione qui sopra riportata, è corretta
ma non è detto che sia quella adottata dalla propria
periferica. Pertanto consiglio di rifarsi sulle specifiche
rilasciate dal produttore.
Per quanto riguarda questi ultimi due ci basta sapere che la
terminazione si occupa di comunicare al controller quando la
catena va chiusa. Se sul nostro dispositivo di backup chiudessimo
con un ponticello questo jumper (e nel nostro esempio così
sarà), nessun'altra periferica a partire da questo punto
in poi potrà essere collegata.
La parità invece (che consiglio ove possibile di tenere
sempre chiusa), fornisce funzionalità avanzate di
controllo del BUS SCSI, quali controlli degli errori tra le
periferiche. L'unico dettaglio di rilievo in questa caso è
che se impostata, lo deve essere su tutta la catena. Nel caso in
cui non fossimo in condizioni di settarla su tutta la catena
allora essa deve rimanere aperta.
Discorso a parte invece per lo SCSI ID; bisogna porre
particolare attenzione per evitare dolorosi mal di testa.
Similmente all'EIDE, in cui non è possibile impostare due
periferiche master e/o slave sullo stesso canale, anche nello
SCSI due o più periferiche non possono avere lo stesso ID,
pena problemi e conflitti.
Per impostare correttamente l'ID vi rimando allo schemino qui
sotto.
# Leggenda : -> aperto | -> chiuso [ID] = [JUMPERS] -------------------- ID 0 = : : : ID 1 = | : : ID 2 = : | : ID 3 = | | : ID 4 = : : | ID 5 = | : | ID 6 = : | | ID 7 = | | | # Schema comprensivo di terminazione e parità utilizzato in questo articolo. [ID] - [JUMPERS] - [TERM.] - [PAR.] ----------------------------------------------------- ID 0 = : : : | |
Rimangono da considerare i dettagli rispetto al sistema
operativo utilizzato.
Il sistema SCSI in Linux è veramente ottimo sotto tutti i
punti di vista. Se si configurano correttamente i parametri
Hardware visti sopra, possiamo stare tranquilli che tutto
funzionarà in maniera efficiente. L'unico consiglio in
relazione a questo aspetto è quello estendibile a
qualsiasi periferica: assicurarsi che l'Hardware sia
supportato.
Un esempio completo
Come al solito, per rendere tutto il discorso più
eloquente, ipotizzeremo di dover configurare, su una macchina con
funzionalità di mailserver e webserver, una semplice
sistema di backup automatizzato.
Per non dilungarci troppo nel discorso partiremo in una
situazione di sistema già installato e con i vari
applicativi di servizio configurati. Non faremo per il momento
riferimento a nessuna distribuzione specifica, dettaglio
ininfluente, mentre utilizzeremo un Kernel Linux, ne troppo
datato, ne troppo recente: 2.4.18
Parlando dal punto di vista Hardware, la scelta del controller è ricaduta sull' INITIO CI-2500, periferica di ottima fattura perfettamente supportata dal Kernel, e da un dispositivo a nastri HP serie SURESTORE.
Configurazione del Kernel
Prima di tutto è nostro compito assicurarci che il
Kernel installato sulla macchina sia compilato per il supporto
SCSI e di conseguenza supporti il nostro controller.
Oggi giorno, la stragrande maggioranza delle distribuzioni Linux,
vengono rilasciate con Kernel precompilati che supportano
moltissime periferiche come modulo. Questo ci induce a pensare
che potremmo evitare di ricompilare il Kernel e caricare, se
possibile, solamente il modulo SCSI associato, semplicemente
attraverso il comando:
[root: ~]# modprobe 9100UW
Tuttavia dato che l'esempio ipotizza una macchina di
produzione affronteremo il caso della ricompilazione.
Scarichiamo i sorgenti del Kernel, e prepariamoci a
ricompilare:
[root: ~]# cd /usr/src/ [root: ~]# wget -c ftp://ftp.kernel.org/pub/linux/kernel/v2.4/linux-2.4.18.tar.gz [root: ~]# tar xzvf linux-2.4.18.tar.gz [root: ~]# cd linux-2.4.18 [root: ~]# make config `oppure` make menuconfig `oppure` make xconfig
Ciò che interessa a noi è il supporto SCSI in generale e ovviamente quello specifico per la periferica in nostro possesso; pertanto selezioniamo la scheda "SCSI Support" e procediamo in questa maniera:
----> Scheda GENERALE [ y ] [ ] [ ] ::: SCSI Support ... [ y ] [ ] [ ] ::: SCSI Tape Support ... [ y ] [ ] [ ] ::: Verbose SCSI error reporting (kernel size +=12) ----> Scheda SCSI low-level-drivers, selezioniamo il nostro controller [ y ] [ ] [ ] ::: INITIO 9100U(W) support
Di fatto abbiamo attivato il sistema SCSI e il supporto per i
dispositivi a nastro. Inoltre è stato incluso il driver
per il solo controller a nostra disposizione, sperando di rendere
il kernel più snello.
Come si evince dal nome, l'opzione `Verbose SCSI error reporting,
stampa tutti i messaggi in maniera prolissa, utile non solo nel
caso di problemi legati al controller, ma anche durante la
comunicazione tra le periferiche. E' consigliabile pertanto
abilitarla!
Conclusa la fase di scelta dei driver da includere possiamo provvedere alla compilazione:
[root: ~]# make dep && make bzImage [root: ~]# make modules && make modules_install ... [root: ~]# cd i386/boot/ [root: ~]# cp bzImage /boot/vmlinuz-2.4.18
Aggiorniamo il nostro lilo.conf e riavviamo il sistema per caricare il Kernel appena compilato:
[root: ~]# vi /etc/lilo.conf ... image=/boot/vmlinuz-2.4.18 label=Linux SCSI Support read-only root=/dev/hda1 ... :wq [root: ~]# /sbin/lilo -t # Se non riscontriamo errori [root: ~]# /sbin/lilo [root: ~]# reboot
Ora possiamo verificare che il nostro lavoro abbia portato i frutti sperati. Il filesystem `/proc` ci riserva la risposta:
[root: ~]# cat /proc/ioports ... e800-e8ff : Initio Corporation e800-e8ff : i91u ... [root: ~]# cat /proc/scsi/scsi Attached devices: Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: HP Model: HP35470A Rev: 1009 Type: Sequential-Access ANSI SCSI revision: 02
Il procedimento forse più ostico, e che può
presentare problemi, si è concluso con un trionfo :),
d'ora in poi potremmo riferirci alla nostra periferica
richiamandola con il suo nome corretto: /dev/st0 o
/dev/nst0
A questo punto possiamo parlare del funzionamento e di come
iniziare da subito ad eseguire backup; tutto questo sarà
argomento del prossimo punto.
Strumenti pronto uso
Vediamo quali strumenti utilizzare per eseguire i nostri
backup, e per gestire al meglio i nastri.
In merito al primo punto, il buon vecchio `tar` la fa da padrone;
grazie alla sua semplicità sarà possibile gestire
tutto il processo facilmente.
Per la gestione della periferica, l'indicizzazione degli archivi
e la gestione dei nastri passeremo al settacio il pacchetto
`mt-st`, che per molti potrebbe suonare nuovo.
Prima di continuare, una piccola nota di percorso: una ricerca
in rete mi ha permesso di scoprire un altro interessante
pacchetto con la quale gestire la periferica: `dds2tar`.
Benchè le funzionalità di `mt-st` siano più
che sufficenti, a prima vista pare che `dds2tar` sia più
specializzato per questo genere di compito.
E' possibile scaricarlo sottoforma di sorgenti al seguente
indirizzo:
ftp://ftp.uni-duesseldorf.de/pub/unix/apollo/
oppure come pacchetto precomplilato, sul sito della propria
distribuzione.
Backup e gestione nastri
All'inizio dell'articolo avevamo ipotizzato di lavorare su una
macchina che forniva servizi Web e di posta elettronica.
Vediamo quindi come eseguire i backup di tutti i siti internet in
hosting, e le mailbox degli utenti:
[root: ~]# tar cvf /dev/st0 /home/website/ /var/spool/mail/
Potremmo ad esempio schedulare tramite cron questa semplice
riga ed eseguire in automatico il backup.
E se a questo punto volessimo estrarre i dati salvati ? Niente di
più semplice!
[root: ~]# tar xvf /dev/st0
In questa sede trattiamo degli esempi generali, il nostro interesse principale è quello di prendere confidenza con i suddetti strumenti, ma ovviamente nessuno ci vieta di provare soluzioni più eleganti e complesse; come sottolineato all'inizio dell'articolo, i backup sono prima di tutto pianificazione.
Pensate ad esempio a diversi DB MySQL, e la necessità di salvarli all'interno dei nastri. Potrebbe essere sufficente crearsi uno script, che esegua il dump completo delle tabelle, all'interno del nostro filesystem, e successivamente attraverso un cronjob, salvare i dati definitivamente su nastro.
#!/bin/sh # # Nome: backup.sh # # Descrizione: # Un semplice script di backup per i nostri dati # comprese le tabelle mysql. # BACKUPFILE="/etc/ /home/websites/ /var/spool/mail" MYSQLDESTFS="/etc/mysql/data" DEVICE="/dev/st0" DATA=`date` SENDTO="beppebz (at) tin (dot) it" echo "Dump delle tabelle MySQL..." echo " ----> DATABASE DB1" mysqldump --opt -u root -ppasswd db1 > $MYSQLDESTFS/db1.sql echo " ----> DATABASE DB2" mysqldump --opt -u root -ppasswd db2 > $MYSQLDESTFS/db2.sql echo "Dump DATABASE completato: inizio il trasporto dei dati sul nastro" tar cvf $DEVICE $BACKUPFILE echo "Spedisco il messaggio di conferma" mailx -s "Backup del $DATA effettuato" $SENDTO echo "Done.. have a nice day :)"
Un altro esempio potrebbe essere quello di eseguire il dump
dei dati di altre macchine tramite NFS: è sufficente
sincronizzare gli orari attraverso il protocollo NTP, e al
momento che riteniamo più opportuno, salvare i dati
prelevandoli dalla directory remota.
Esistono sicuramente alternative migliori e mirate per fare
questo, ma in tutti casi ove le neccessità non siano
particolari, potrebbe essere una soluzione da considerare.
A questo punto è d'uopo sottolineare che le periferiche trattate in quest'articolo sono ad accesso sequenziale (come ci suggerisce il nostro sistema):
Type: Sequential-Access
A onor del vero i nastri non richiedono formattazione alcuna,
l'estrazione dei dati non richiede il mount della periferica
(come invece accadrebbe ad esempio utilizzando un CD-ROM) e
l'estrazione o la lettura degli archivi richiede che il nastro
venga previa posizionato sull'archivio interessato.
Per certi versi, l'impossibilità di montare la periferica
e quindi di trattare i dati in essa contenuti come se facessero
parte integrante del filesystem, risulta un po scomodo.
Per fortuna questi compiti sono affidati a `mt-st`, che oltre ad
essere semplice nel suo utilizzo, è accompagnato da
un'ottima documentazione.
Vediamo comunque qualche esempio:
// Riavvolgimento del nastro [root: ~]# mt -f /dev/st0 rewind // Riavvolgimento con espulsione [root: ~]# mt -f /dev/st0 rewoffl // Stampa lo stato dell'unita [root: ~]# mt -f /dev/st0 status // Cancella l'intero contenuto [root: ~]# mt -f /dev/st0 erase // Quattro archivi sul nastro. Intendiamo leggere ed estrarre il terzo archivio. // Successivamente leggeremo il secondo. [root: ~]# mt -f /dev/nst0 rewind [root: ~]# mt -f /dev/nst0 fsf 2 [root: ~]# tar tvf /dev/nst0 [root: ~]# tar xvf /dev/nst0 [root: ~]# mt -f /dev/nst0 bsf 1 [root: ~]# tar xvf /dev/nst0
Conclusioni
Nel corso di questo breve viaggio ho cercato di porvi difronte ad un panorama generale riguardante i backup e le periferiche SCSI. La vastità degli argomenti non mi permette di entrare in merito alle singole situazioni; il compito per tutti è quello di ampliare i semplici esempi proposti adeguandoli alle proprie necessità.
Ultimo aggiornamento: 04/01/2004 - 00:17:30
Pagina elaborata in 0.0189049243927 secondi