Le sempre crescenti richieste in termini di memoria di massa richiedono la possibilita' di gestire in modo semplice e flessibile le attivita' di salvataggio e recupero di dati.

Le funzionalita' tipiche dei prodotti per la gestione dei backup/restore sono, tra le altre, l'attivazione a tempo dei salvataggi, la gestione di dispositivi fisici differenti (dai semplici tape a robot meccanici completi composti da librerie di nasti, piu' device, bracci meccanici, ...), la gestione di differenti modalita' di salvataggio (totale, incrementale, ...).

Tra i prodotti piu' completi e diffusi vi e' Legato NetWorker Save&Resore (NSR).

L'architettura di NSR e' molto orientata alla rete. I client sono i sistemi su cui avvengono i backup e debbono (si spera di rado) essere effettuati i restore, mentre il server e' il sistema di gestione dei backup. Gli storage node sono i sistemi su cui risiedono i supporti di backup (che possono essere normali DAT o interi jukebox di nastri). L'amministratore configura i vari tipi di salvataggio definendo l'origine, il tipo di backup e la destinazione.

NSR supporta sistemi eterogenei di vendor differenti. Dal punto di vista implementativo i vari comandi viaggiano in rete con richieste RPC.

I salvataggi possono essere integrali o incrementali. I salvataggi vengono effettuati su dispositivi di memorizzazione detti volumi. I volumi debbono avere una label per essere riconosciuti. Ogni salvataggio ed ogni oggetto salvato viene memorizzato su una base dati detta indice. Naturalmente le ricerche sugli oggetti contenuti negli indici risultano enormemente piu' veloci che un'eventuale ricerca sui dispositivi finali. Ad ogni salvataggio puo' essere definito un tempo di ritenzione. Ogni salvataggio ha un identificativo (save set ID). Il tempo di ritenzione e' relativo al supporto ed all'indice (possono essere tempi diversi). Quando tutti i salvataggi contenuti su un volume hanno superato il tempo di ritenzione il volume puo' essere riutilizzato ed i contenuti ricoperti. I salvataggi sono effettuati in gruppi che possono contenere client differenti e vengono schedulati internamente ad NSR.

Alcuni punti ovvi (ma non troppo a vedere diverse installazioni). I backup in rete richiedono un corretto capacity planning. Un backup su una rete con molto traffico e' un peccato mortale. Un backup su una rete geografica e' E' ugualmente ovvio che se un sistema e' uno storage node conviene effettuare i backup sui device locali.

La tabella seguente riporta alcuni comandi:

nwadmin	Tool grafico (X-Windows) di gestione del server
recover	Effettua il recover dei file
nsrwatch	Tool grafico (curses) di gestione (parziale) del server
nsrmm	Gestione volumi
mminfo	Gestione save set
nsrjb	Comandi di gestione del jukebox. Opzioni: -H effettua il reset HW del JB -I effettua l'inventario del JB -d VOL deposito volume -l VOL carico volume
save	Effettua il salvataggio (poco usato interattivamente, si preferisce usare la schedulazione)
scanner	Legge un volume e, per esempio, ne ricostruisce gli indici

Debbono essere attivi una serie di demoni che forniscono il servizio di backup sui server e sugli storage node. Tali servizi vengono generalmente attivati al bootstrap.

Le sessioni di restore vengono generalmente effettuate in modo interattivo con il comando recover. Ecco le principali opzioni:

        add [-q] [filename] - add `filename' to list of files to be recovered
        cd [dir] - change directory to dir
        changetime [date]  - change the time that you are browsing
        debug
        delete [filename] - delete `filename' from the recover list
        destination - print destination location for recovered files
        dir [/w] [filename...] - list filename
        exit - immediately exit program
        force - overwrite existing files
        help or `?' - print this list
        lf [-aAcCdfFgilLqrRsStu1] [filename...] - list filename type
        list [-c | -l]  - list the files marked for recover
        ll [-aAcCdfFgilLqrRsStu1] [filename...] - long list filename
        ls [-aAcCdfFgilLqrRsStu1] [filename...] - list filename
        noforce - do not overwrite existing files
        pwd - print current directory
        quit - immediately exit program
        recover - recover requested files
        relocate [dir] - specify new location for recovered files
        verbose - toggle verbose mode; feedback about what is going on
        versions [filename] - report on each version of file `filename
        volumes [filename] - report volumes needed to recover marked files 

Nel seguito e' riportata una sessione di esempio.

NSR si integra con il prodotto Oracle EBU (Enterprise Backup utility).

EBU utilizza un repository su cui mantiene la struttura dei DB su cui effettuare i salvataggi ed il completo elenco dei salvataggi effettuati. EBU si occupa di lanciare sulla base dati tutti i necessari comandi in modo da garantire un salvataggio consistente (eg. ALTER TABLESPACE SYSTEM BEGIN BACKUP). EBU consente di effettuare, senza alcun intervento da parte del DBA, i backup di una base dati Oracle a DB attivo. EBU consente di salvare in parallelo i diversi datafile che compongono una base dati ottenendo in tal modo la massima velocita' da supporti di backup multipli.

EBU utilizza i driver di NSR per lavorare sui dispositivi di backup (nastri o librerie). E' inoltre possibile schedulare da NSR i backup EBU.

L'installazione di Networker dipende dal sistema operativo ospite. Terminata l'installazione e' necessario inserire la licenza che rende operativo il prodotto.

Le licenze debbono essere installate per i server, per gli storage node, per un certo numero di client e per le eventuali opzioni utilizzate (eg. EBU).

Ecco una sessione di esempio!

# recover
recover: Current working directory is /BCK_mysql/
recover> dir
total 76
06/13/09  03:30 AM           <DIR>         BCK_mysql1
07/15/10  03:35 AM           <DIR>         BCK_mysql2
06/04/10  03:40 AM           <DIR>         BCK_mysql3
...
recover> cd BCK_mysql3
recover> changetime 12/25/2008
time changed to Thu Dec 25 23:59:59 2008
recover> dir
total 72
11/21/08  03:10 AM                      20 MySQLFullBckService3.20081121.sql.gz
11/22/08  05:01 PM                      20 MySQLFullBckService3.20081122.spegnimentoCED.sql.gz
11/22/08  03:10 AM                      20 MySQLFullBckService3.20081122.sql.gz
...
recover> add MySQLFullBckService3.20081122.sql.gz
1 file(s) marked for recovery
recover> list
/BCK_mysql/BCK_mysql3/MySQLFullBckService3.20081129.sql.gz @ Sat Dec  6 03:49:54 2008
1 file(s) marked for recovery
recover> versions
Versions of `/BCK_mysql/BCK_mysql3/':
   4 drwxr-xr-x root     root         4096 Jun 04 03:40  BCK_mysql3/
     save time:  Sun Jul 11 02:05:39 2010
      location:  Tot.1371 at jbL700_1
   4 drwxr-xr-x root     root         4096 Jun 04 03:40  BCK_mysql3/
     save time:  Sun Jun  6 01:35:20 2010
      location:  Diff.566 at jbL700_1
...
recover> relocate /tmp
recover> recover
Recovering 1 file from /BCK_mysql/BCK_mysql3/ into /tmp
Volumes needed (all near-line):
        Tot.1371 at STK@3.1.1
Total estimated disk space needed for recover is 64 MB.
Requesting 1 file(s), this may take a while...
42795:nsrndmp_recover:ssid'3346992368': Performing recover from Non-NDMP type of device
Apr 31 10:06:36 networker2 root: [ID 702911 local0.alert] NetWorker media: (waiting) waiting for LTO Ultrium-4 tape Nas.0005 (400072) on my_nsr
...
42617:nsrndmp_recover:ssid'3346992368': NDMP Service Log: RESTORE: Thu Apr 31 10:38:25 2008 : We have read 188604591 KB from the backup.
42617:nsrndmp_recover:ssid'3346992368': NDMP Service Log: RESTORE: RESTORE IS DONE
42942:nsrdsa_recover:ssid'3346992368': Reading data...DONE.
42927:nsrndmp_recover:ssid'3346992368': Successfully done
recover> 

	

Utilizzare i SSID (save set ID) per restore veloci e senza indici.

Attenzione ai carichi di rete. Su server di grosse dimensioni e' necessario disporre di uno storage node locale. E' inoltre spesso preferito utilizzare un backbone di rete dedicato ai backup.