Periferiche SCSI e backup: un esempio completo.

Nel corso di questo articolo verranno introdotti i concetti di base della tecnologia SCSI ed il loro utilizzo per la configurazione di un sistema di backup su DAT.

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, ma 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: GNU/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 dal lato periferiche. Quali accorgimenti adottare dal lato Sistema Operativo.

Leggi anche: Tape backup software per sistemi Linux. Lo SCSI (Small Computer System 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 "jumper" 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 jumper. Da sinistra verso destra i jumper 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 si consiglia di controllare le 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 sarà così), 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 impostarla su tutta la catena allora essa deve rimanere aperta. Discorso a parte invece per lo SCSI ID, a cui 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.

# Legenda : -> 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 funzionerà 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, un semplice sistema di backup automatizzato. Per non dilungarci troppo nel discorso partiremo da 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 come kernel Linux la versione 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.

Oggigiorno, la stragrande maggioranza delle distribuzioni Linux viene rilasciata 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 xconfig (oppure "make menuconfig") 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:

----> Sezione "GENERALE" [ y ] [ ] [ ] ::: SCSI Support ... [ y ] [ ] [ ] ::: SCSI Tape Support ... [ y ] [ ] [ ] ::: Verbose SCSI error reporting (kernel size +=12) ----> Sezione "SCSI low-level-drivers", selezioniamo il nostro controller [ y ] [ ] [ ] ::: INITIO 9100U(W) support

Dovremmo aver attivato il sistema SCSI ed 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. È 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 boot loader e riavviamo il sistema per caricare il kernel appena compilato. Ecco l'esempio di lilo.conf:

[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

Dopo il riavvio 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 setaccio 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 il 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.

È possibile scaricarlo sottoforma di sorgenti al seguente indirizzo:
ftp://ftp.uni-duesseldorf.de/pub/unix/apollo/
oppure come pacchetto precompilato, direttamente 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" # Ovviamente nello script vero e proprio # l'indirizzo va inserito correttamente # ovvero con i caratteri @ e "." 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.

Ad 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 prima 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 di fronte ad un panorama 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à.

A Small Fix for dds2tar.

According to the man page, dds2tar should be able to use an index file generated with an unpatched tar (using -Rv or -Rvv). But my tests showed that this is not the case.

I have therefore fixed the index parsing code of dds2tar to make it work with index files generated by an unpatched tar.


Update: This fix has already been incorporated in Debian woody.

Resources

• dds2tar @ Debian
• Debian Bug Report #119692
• Dr. Weule's dds2tar page

Se ti è piaciuto l'articolo , iscriviti al feed cliccando sull'immagine sottostante per tenerti sempre aggiornato sui nuovi contenuti del blog: