Una soluzione Open Source per un'infrastruttura di backup centralizzato: Bareos e IBM TS3500

Full text

SPR Reti e Sistemi Informativi
Una soluzione Open Source
per un’infrastruttura di
backup centralizzato:
Bareos e IBM TS3500
Autori:
Dott. Giorgio Bartoccioni, Dott. Roberto Muzi
2017R00001
Consiglio Nazionale delle Ricerche
Roma, Maggio 2017

Una soluzione Open Source per un’infrastruttura
di backup centralizzato:
Bareos e IBM TS3500©
Autori:
Dott. Giorgio Bartoccioni – SPR Reti e Sistemi Informativi,Piazzale Aldo Moro, 7 - 00185 Roma, Italy
Email: giorgio.bartoccioni@cnr.it
Dott. Roberto Muzi – SPR Reti e Sistemi Informativi,Piazzale Aldo Moro, 7 - 00185 Roma, Italy
Email: roberto.muzi@cnr.it
Revisori:
Ing. Silvio Scipioni – SPR Reti e Sistemi Informativi,Piazzale Aldo Moro, 7 - 00185 Roma, Italy
Email: silvio.scipioni@cnr.it
Ing. Roberto Puccinelli – SPR Reti e Sistemi Informativi,Piazzale Aldo Moro, 7 - 00185 Roma, Italy
Email: roberto.puccinelli@cnr.it
Consiglio Nazionale delle Ricerche, SPR Reti e Sistemi Informativi
Piazzale Aldo Moro, 7 - 00185 Roma, Italy
tel. 06 49933688 - fax 0649932562 - email segreteria@cnr.it

Abstract
Nell’ambito del progetto per la realizzazione dell’infrastruttura di Disaster Recovery del Consiglio
Nazionale delle Ricerche (
CNR
), si è studiata e implementata una soluzione di backup centralizzato,
scalabile e efciente. Questo documento fornisce una guida alla sua installazione e congurazione. In
particolare è stato impiegato hardware IBM di livello Enterprise e software Open Source di comprovata
afdabilità con licenza AGPLv3: Bareos. La sala macchine della Sede centrale del
CNR
è infatti un
ambiente in continua evoluzione e diversicato per tipologia, quantità di macchine e servizi gestiti.
In un ambiente così complesso, è apparsa chiara la necessità di adottare una soluzione essibile per
la gestione dei backup. Il sistema implementato viene oggi utilizzato quotidianamente in produzione
per la gestione dei backup di circa sessanta macchine che erogano servizi essenziali per il corretto
funzionamento dell’Ente. Esso risulta quindi robusto, scalabile ed economico.
Parole chiave
Bareos
Backup
Director
Data restore
Fibre Channel
FD
IBM TS3500
MT
MTX
Open Source
SD
iii

Sommario
1. Bareos 1
1.1. Checos’è ................................................. 1
1.2. Installazione ............................................... 1
2. Concetti fondamentali 3
2.1. BackupFull................................................ 3
2.2. BackupIncrementale.......................................... 3
2.3. BackupDifferenziale .......................................... 3
2.4. Retentionperiod............................................. 3
3. Setup hardware 5
3.1. Componenti principali e collegamenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Nastri:mxemtx............................................. 7
3.3. Esempiodioperazioni ......................................... 8
4. Configurazione di Bareos 9
4.1. Dovecercare............................................... 9
4.2. Checosacercare............................................. 10
4.3. Denizione Autochanger sull’SD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.4. DenizioneDevicesull’SD....................................... 12
4.5. Denizione Storage sul Director . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.6. DenizionePool............................................. 12
4.7. DenizioneSchedule.......................................... 14
4.8. DenizioneJobdefseJob ....................................... 15
4.9. DenizioneMessages.......................................... 17
4.10.Avviodeiservizi............................................. 18
4.10.1. Preparazionedeinastri .................................... 18
4.11. EsecuzioneprimoJob ......................................... 19
5. Aggiungiamo un client 23
5.1. Sulserver................................................. 23
5.2. Sulclient ................................................. 23
5.3. Torniamosulserver........................................... 24
5.4. BackupdiDatabase........................................... 26
5.5. Rimuovereunclient .......................................... 27
6. Restore 29
7. Notifiche 33
8. ACL 37
A. Breviario Bareos 39
A.1. Chesuccede?............................................... 39
A.2. Backup................................................... 39
A.3. Ripristino ................................................. 39
A.4. Jobs..................................................... 39
A.4.1. StatodiunJob.......................................... 40
A.5. Tapes.................................................... 40
v

vi
Una soluzione Open Source per un’infrastruttura di backup centralizzato:
Bareos e IBM TS3500
B. Breviario mt e mtx [3]41
B.1. Display status of the tape/drive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
B.2. Rewindsthetape ............................................ 41
B.3. Ejectthetape............................................... 41
B.4. Erase the tape (rewind the tape and, if applicable, unload the tape) . . . . . . . . . . . . . . 41
B.5. Retensioning a magnetic tape cartridge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
B.6. Writes n EOF marks in the current position of tape . . . . . . . . . . . . . . . . . . . . . . . . 41
B.7. Forward space count les i.e. jumps n EOF marks . . . . . . . . . . . . . . . . . . . . . . . . 42
B.8. Backward space count les i.e. rewinds n EOF marks . . . . . . . . . . . . . . . . . . . . . . 42
B.9. To backup directory (tar format) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
B.10. To restore directory (tar format) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
B.11. List or check tape contents (tar format) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
B.12. Backup partition with dump or ufsdump . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
B.13. Start writing at the beginning of the tape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
B.14.Startwritingafterthelasttar ..................................... 43
B.15. Start writing after tar number 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
C. Relabeling 45
CNR SPR Reti e Sistemi Informativi

Una soluzione Open Source per un’infrastruttura di backup centralizzato:
Bareos e IBM TS3500 vii
Elenco abbreviazioni e acronimi
ACL Access Control List
DDirector
FD File Daemon
SD Storage Daemon
GUI Graphical User Interface
EOF End Of File
CNR Consiglio Nazionale delle Ricerche
CNR SPR Reti e Sistemi Informativi

Introduzione
In informatica con il termine backup si indica la replicazione, su un qualunque supporto di memorizza-
zione, di materiale informativo archiviato nella memoria di massa dei computer, al ne di prevenire la
perdita denitiva dei dati in caso di eventi malevoli, accidentali o intenzionali.
Nel documento Linee Guida Per Il Disaster Recovery Delle Pubbliche Amministrazioni dell’Agenzia
per l’Italia digitale, 2013, si legge alla “App. A: Politiche di backup”: “Predisporre le misure idonee ad
impedire la distruzione o il danneggiamento dei dati di un’Amministrazione e, comunque, rendere
possibile il loro ripristino in tempi brevi senza che questo comporti delle conseguenze negative sotto il
prolo economico, legale, o puramente di immagine, è compito obbligatorio per l’Amministrazione
stessa.”
Si vedrà quindi come, anche dal punto di vista legislativo, sia di fondamentale importanza la predi-
sposizione di un sistema di backup solido e facilmente scalabile, che consenta di soddisfare le esigenze
sempre crescenti della gestione informatica di grandi organizzazioni come la P.A.
In questo lavoro inizialmente si richiameranno i concetti fondamentali dei metodi di backup: reposi-
tory completi, incrementali e differenziali.
La scelta per il sistema di Backup da utilizzare è caduta su Bareos. Bareos è strutturato come una suite
di programmi che consente all’amministratore di sistema di gestire facilmente il backup, il ripristino e
la verica dei dati di un computer e può gestire vari tipi di supporti, come nastri e dischi.
L’Hardware utilizzato per il backup e l’archiviazione è un sistema IBM TS3500 Tape Library, capace
di memorizzare no a 1750TB di dati. Può gestire, utilizzando driver hardware distinti, librerie virtuali
a cui è assegnato un gruppo specico di nastri, i quali vengono visti dall’utente come se fossero un
dispositivo di storage hardware indipendente. É possibile comunicare con la tape library con i comandi
di sistema mt e mtx.
Bareos è composto da tre applicazioni principali:
•Director (D): il server vero e proprio;
•
Storage Daemon (
SD
): si occupa della gestione dei dispositivi di memorizzazione dei dati, come
dischi e tapes;
•File Daemon (FD): il sistema che permette lo scambio di dati tra server e client.
La gestione del server è possibile sia da interfaccia web, che da CLI (bconsole).
La congurazione di Bareos costituisce la parte centrale di questo lavoro nel corso del quale verranno
illustrati tutti i passi necessari per implementare un sistema di backup completo: denizione delle
impostazioni di
D
,
SD
e
FD
; impostazione dei dispositivi sull’
SD
; denizione dei pool; degli schedule e
dei job.
Si passerà, quindi, al procedimento di installazione dei client da impostare sui sistemi da memorizzare
sul dispositivo di backup. Per ogni macchina da gestire andrà installato sul client l’
FD
, che si occuperà
di comunicare con il server Bareos: su questo, per ogni client, sarà possibile ssare il relativo job, che
richiamerà lo scheduler e il pool desiderati.
Seguirà un capitolo dedicato alla modalità di restore di un sistema.
A complemento del lavoro si esaminerà la gestione delle notiche e delle Access Control List (
ACL
)
del sistema.
In Appendice A un Breviario, contenente i comandi di uso più comune di Bareos.
In Appendice B i comandi di uso più comune per comunicare con il tape: mt e mtx.
ix

Capitolo 1
Bareos
1.1. Che cos’è
Bareos è un fork del progetto Bacula, un software di backup conosciuto ed afdabile. Nel 2010 Bareos si
allontana da Bacula rimanendo 100% open source e incorporando diverse caratteristiche disponibili
solo nella versione Enterprise di Bacula. I sorgenti, licenziati AGPLv3, sono pubblicati su GitHub.
Sono disponibili repository per l’installazione sulle principali distribuzioni Linux. Per gli aggiornamenti
è necessario acquistare le opportune subscription.
1.2. Installazione
Bareos necessita di un database in cui memorizzare il Catalog. Il primo passo è pertanto l’installazione del
database, MySQL o PostgreSQL. Per questo documento si è scelto di installare Postgresql da repository:
 
# yum install postgresql-server
postgresql-setup initdb
systemctl start postgresql
 
Aggiungiamo quindi il repository di Bareos:
 
# wget -O /etc/yum.repos.d/bareos.repo \
http://download.bareos.org/bareos/release/latest/CentOS_7/bareos.repo
# yum update
 
e procediamo installando i pacchetti necessari:
 
# yum install jansson bareos \
bareos-database-postgresql \
bareos-webui \
bareos-storage-tape
 
Utilizzando gli appositi script, inizializziamo il database di Bareos:
 
# su postgres -c /usr/lib/bareos/scripts/create_bareos_database
# su postgres -c /usr/lib/bareos/scripts/make_bareos_tables
# su postgres -c /usr/lib/bareos/scripts/grant_bareos_privileges
 
In ultimo conguriamo l’accesso alla WEBUI editando l’apposito le:
 
# vim /etc/bareos/bareos-dir.d/console/admin.conf
Console {
Name = "admin"
Password = "UNAPASSWORD"
Profile = "webui-admin"
}
 
A questo punto il server è installato, ma occorre congurarlo per adattarlo alle proprie esigenze. Prima
di procedere con la congurazione è necessario familiarizzare con alcuni concetti fondamentali che
saranno esposti nel capitolo 2.
1

Capitolo 2
Concetti fondamentali
Nel presente capitolo sono brevemente descritti alcuni concetti semplici ma fondamentali, che è
necessario fare propri per una corretta amministrazione di Bareos.
2.1. Backup Full
È Il tipo più semplice di backup: viene creata un’intera copia del FileSet, ovvero dei le del client.
Questo è l’unico Backup completamente autosufciente, nel senso che non richiede che siano stati
eseguiti Backup precedenti. La controindicazione sta nel fatto che, ovviamente, è il tipo di Backup
che occupa più spazio sullo storage. Il problema può essere minimizzato comprimendo i backup
creati. Utilizzare questa impostazione diminuirà lo spazio occupato, ma aumenterà i tempi di backup e
l’impegno di CPU dell’
SD
. Possiamo quindi utilizzare questa piccola miglioria, ma dobbiamo studiare
attentamente anche tipologie di Backup meno stressanti per lo storage.
2.2. Backup Incrementale
Il Backup incrementale, richiede l’esecuzione preliminare di un backup Full. Se questo non esiste, Bareos
provvederà a crearlo. Il Backup incrementale crea una copia soltanto delle differenze riscontrate rispetto
all’ultimo Job di un dato FileSet. In questo modo, partendo da un solo Backup Full, ad ogni backup
incrementale, saranno salvate esclusivamente le differenze rispetto al precedente Backup Incrementale.
Ciò implica che, per il ripristino, avremo bisogno di tutti i backup a ritroso no ad un Backup Full
valido. Naturalmente, così facendo, impegneremo al minimo il lesystem in merito ad un solo backup,
ma saremo obbligati, nel caso in cui il numero di backup salga molto in fretta, a mantenerne un gran
numero sullo storage.
2.3. Backup Differenziale
Il terzo metodo, il Backup differenziale, funziona in modo molto simile al precedente con la differenza
che, dato un Backup Full, verranno salvate le differenze tra questo backup e la situazione corrente. In
questo modo, qualsiasi Backup differenziale avrà bisogno soltanto del Backup Full a cui fa riferimento
senza necessitare di tutti gli eventuali step intermedi. Tale soluzione appare dunque intermedia: abbiamo
infatti un uso dello storage non signicativo e avremo il vincolo di mantenere un elevato numero di
Backup. E’ evidente che non esiste un’unica soluzione ottimale, valida in ogni caso: ogni situazione
deve essere valutata attentamente per capire quando sarà il momento di intervenire con un Backup
completo, con una sequenza di incrementali o con una serie di differenziali.
2.4. Retention period
Esistono tre parametri principali che deniscono per quanto tempo Bareos conserverà i le sottoposti a
backup. L’insieme di questi parametri inuenza il Retention Period. I parametri sono:
•File Retention Period,
•Job Retention Period,
•Volume Retention Period
3

4
Una soluzione Open Source per un’infrastruttura di backup centralizzato:
Bareos e IBM TS3500
Tutti i valori di Retention si riferiscono al mantenimento degli oggetti nel database del Catalog e
non vanno confusi con il tempo per il quale i dati rimarranno in un Volume. Bareos rimuoverà i
le esclusivamente sovrascrivendo il Volume.
Il
File Retention Period
: se un le è presente nel Catalog, è possibile ricercarlo e ripristinarlo singolar-
mente. Se al parametro è assegnato un valore troppo alto, il database del Catalog potrebbe crescere
troppo.
Il
Job Retention Period
: ogni le salvato è accoppiato a un Job. Se un le viene eliminato dal Catalog è
possibile ripristinare l’intero Job ma non i singoli le. Normalmente quando un Job viene eliminato dal
Catalog, vengono eliminati anche i relativi File.
Il
Volume Retention Period
: è il tempo minimo prima che un Volume venga sovrascritto. Quando un
volume viene sovrascritto si perdono ovviamente tutti i job e i le associati ad esso.
Per non far crescere troppo le dimensioni del Catalog, ovvero del db, si consiglia di impostare a
yes
il
parametro
Auto Prune
per i Client, consentendo la rimozione dei le (solo) dal Catalog allo scadere del
File Retention Period.
CNR SPR Reti e Sistemi Informativi

Capitolo 3
Setup hardware
3.1. Componenti principali e collegamenti
L’
IBM TS3500 Tape Library
è una libreria automatica altamente scalabile per backup e archiviazione
su sistemi aperti e mainframe, in ambienti di medie e grandi dimensioni. Con l’
Advanced Library
Management System
è possibile istanziare delle librerie virtuali, ognuna con nastri e driver assegnati,
partizionando la libreria secondo le necessità. Ciò consente l’utilizzo dell’hardware con software diffe-
renti e quindi l’impiego in ambiti diversi. Dall’interfaccia web, come mostrato in gura 3.1, è possibile
eseguire tutte le operazioni necessarie al partizionamento sopra accennato e l’assegnazione dei nastri
alle librerie virtuali.
Figura 3.1.: Advanced Library Management System
Nel caso in esame la TS3500 è stata partizionata in tre librerie logiche:
•TSM
: con due driver assegnati, verrà utilizzata per le operazioni di backup eseguite dal software
proprietario IBM Spectrum Protect di cui non si tratta in questo documento;
•Lib01: con un solo driver assegnato;
•Lib02: con un solo driver assegnato.
Bareos verrà congurato per utilizzare esclusivamente la Lib01.
Il server
bareos-prod-2.src.cnr.it
(una IBM HS22) e la libreria IBM TS3500 sono collegati alle due
Fabric della SAN Fiber Channel mediante due switch FC IBM 6510 sui quali è stata denita un’apposita
zona.
In gura 3.2 è mostrato il setup dell’infrastruttura.
5

6
Una soluzione Open Source per un’infrastruttura di backup centralizzato:
Bareos e IBM TS3500
Figura 3.2.: Schema di collegamento FC
Non occorre compilare e installare il driver
IBM lin_tape
, necessario per l’implementazione di IBM
Spectrum Protect, in quanto la libreria verrà controllata con gli strumenti standard di Linux:
mt
e
mtx
. Il
server è collegato alla TS3500 da un doppio path FC ma, vista l’impossibilità di utilizzare il
multipath
,
occorre prestare particolare attenzione ai dispositivi creati dal kernel Linux sul server: riavviando il
server, potrebbe infatti cambiare il nome del dispositivo associato alla libreria. Per tale motivo, nelle
congurazioni di Bareos è necessario riferirsi al drive e alla libreria con l’identicativo univoco che è
possibile trovare nella folder /dev/tape/by-id sul server.
Verichiamo quanto appena detto con un semplice riavvio del server:
PRIMA DEL RIAVVIO:
 
# ll /dev/tape/by-id
totale 0
scsi-1IBM_03584L22_0000078A50660402 -> ../../sg7
scsi-350050760440ad903 -> ../../st1
scsi-350050760440ad903-nst -> ../../nst0
# lsscsi -g|grep IBM
[0:0:5:0] tape IBM 03592E08 470E /dev/st0 /dev/sg1
[0:0:5:1] mediumx IBM 03584L22 E220 /dev/sch0 /dev/sg2
[3:0:6:0] tape IBM 03592E08 470E /dev/st1 /dev/sg6
[3:0:6:1] mediumx IBM 03584L22 E220 /dev/sch1 /dev/sg7
 
DOPO IL RIAVVIO:
 
# ll /dev/tape/by-id
totale 0
scsi-1IBM_03584L22_0000078A50660402 -> ../../sg2
scsi-350050760440ad903 -> ../../st1
scsi-350050760440ad903-nst -> ../../nst0
# lsscsi -g|grep IBM
[0:0:5:0] tape IBM 03592E08 470E /dev/st0 /dev/sg1
[0:0:5:1] mediumx IBM 03584L22 E220 /dev/sch0 /dev/sg2
[3:0:6:0] tape IBM 03592E08 470E /dev/st1 /dev/sg6
[3:0:6:1] mediumx IBM 03584L22 E220 /dev/sch1 /dev/sg7
 
Bisogna notare che il
mediumx
(ovvero il changer) viene visto prima come
/dev/sg7
e poi come
/dev/sg2.
CNR SPR Reti e Sistemi Informativi

Una soluzione Open Source per un’infrastruttura di backup centralizzato:
Bareos e IBM TS3500 7
Per ovviare al problema occorrerà, come accennato, denire l’autochanger con l’id relativo che è
possibile trovare, come accennato, nella folder /dev/tape/by-id.
In questo caso otteniamo l’id: scsi-1IBM_03584L22_0000078A50660402
3.2. Nastri: mx e mtx
Il modo più efciente per memorizzare i dati sottoposti a operazioni di backup è senz’altro l’uso dei
nastri. Tra i principali vantaggi: il loro costo per GigaByte è inferiore a quello dei dischi; non ci sono parti
in costante movimento e possono essere rimossi e portati offsite per maggior sicurezza.
Su ogni nastro è possibile immagazzinare, in maniera sequenziale, un certo numero di le, tipicamente
in formato
tar
. I le scritti su nastro sono separati da un
tape file mark
. Per le unità a nastro, nei
sistemi Linux, vengono creati alcuni dispositivi come quelli in tabella 3.1
Tabella 3.1.: device e dispositivi
Linux Dev dispositivo
/dev/sg2 changer
/dev/nst0 tape device (non rewind)
/dev/st0 tape device (rewind)
Il dispositivo
/dev/nst0
è il
no rewind
che indica di non riavvolgere il nastro dopo una operazione di
scrittura. Bareos utilizzerà proprio questo dispositivo. Nei sistemi Linux, si utilizza il comando
mt
per
controllare le unità a nastro e mtx per controllare gli autochanger, ovvero le librerie.
La sintassi è:
mt -f /tape/device/name operation
In appendice Bè riportato un piccolo elenco di comandi per mt e mtx. In realtà Bareos gestisce le unità a
nastro con un suo apposito script:
mtx-changer
. Una volta congurato Bareos con la corretta denizione
della unità a nastro e della libreria, è possibile utilizzare il comando che accetta la seguente sintassi:
path-to-this-script/mtx-changer %c %o %S %a %d
con le seguenti corrispondenze:
Opzione signicato
%c changer-device
%o command
%S slot
%a archive-device
%d drive-index
I “commands” utilizzabili sono:
Comando signicato
unload unload a given slot
load load a given slot
loaded which slot is loaded?
list list Volume names (requires barcode reader)
slots how many slots total?
listall list all info
Attenzione: gli Slots sono numerati da 1 mentre i Drives da 0
CNR SPR Reti e Sistemi Informativi

8
Una soluzione Open Source per un’infrastruttura di backup centralizzato:
Bareos e IBM TS3500
3.3. Esempio di operazioni
Di seguito si riportano alcuni esempi di operazioni con lo script mtx-changer.
Lista dei nastri
 
# /usr/lib/bareos/scripts/mtx-changer /dev/sg2 list
 
Caricamento di un nastro
Vogliamo caricare un nastro dallo slot 2 (Storage Element 2) nel driver:
 
# /usr/lib/bareos/scripts/mtx-changer /dev/sg2 load 2 /dev/nst0 0
Loading media from Storage Element 2 into drive 0...done
# mtx -f /dev/sg2 status
Storage Changer /dev/sg2:1 Drives, 313 Slots ( 255 Import/Export )
Data Transfer Element 0:Full (Storage Element 2 Loaded):VolumeTag = F00031JC
Storage Element 1:Full :VolumeTag=F00030JC
Storage Element 2:Empty:VolumeTag=
Storage Element 3:Full :VolumeTag=F00032JC
Storage Element 4:Full :VolumeTag=F00033JC
Storage Element 5:Full :VolumeTag=F00034JC
.......
 
Espulsione di nastro
 
# /usr/lib/bareos/scripts/mtx-changer /dev/sg2 unload 2 /dev/nst0 0
Unloading drive 0 into Storage Element 2...done
# mtx -f /dev/sg2 status
Storage Changer /dev/sg2:1 Drives, 313 Slots ( 255 Import/Export )
Data Transfer Element 0:Empty
Storage Element 1:Full :VolumeTag=F00030JC
Storage Element 2:Full :VolumeTag=F00031JC
Storage Element 3:Full :VolumeTag=F00032JC
Storage Element 4:Full :VolumeTag=F00033JC
Storage Element 5:Full :VolumeTag=F00034JC
.....
 
CNR SPR Reti e Sistemi Informativi

Capitolo 4
Configurazione di Bareos
Bareos si compone di tre demoni: il
Director
, l’
SD
e l’
FD
. È inoltre presente una console a linea di
comando (bconsole) e una Graphical User Interface (GUI) web.
Figura 4.1.: Componenti di Bareos
Il Director costituisce il server vero e proprio, l’
FD
è, in termini pratici, il client che verrà installato
anche sui server da tenere sotto backup (oltre che sul Director stesso). L’
SD
, inne, si occupa della
gestione dei media su cui memorizzare i backup (disco o tape principalmente).
4.1. Dove cercare
A partire dalla versione in esame, la 16.2, Bareos ha adottato una nuova organizzazione per i le di
congurazione: al posto di un unico lunghissimo le, troviamo una struttura di folder divise per risorse.
I le di congurazione si trovano in /etc/bareos.
 
# ll /etc/bareos
totale 8
drwxr-x---. 15 bareos bareos 196 13 gen 10.09 bareos-dir.d
drwxr-x---. 3 bareos bareos 20 13 gen 10.09 bareos-dir-export
drwxr-x---. 5 root bareos 52 13 gen 10.09 bareos-fd.d
drwxr-x---. 8 bareos bareos 98 13 gen 10.09 bareos-sd.d
-rw-r-----. 1 root bareos 236 13 gen 10.09 bconsole.conf
-rw-r--r--. 1 root root 1501 17 ott 17.44 mtx-changer.conf
drwxr-xr-x. 5 bareos bareos 51 13 gen 10.09 tray-monitor.d
 
9

10
Una soluzione Open Source per un’infrastruttura di backup centralizzato:
Bareos e IBM TS3500
4.2. Che cosa cercare
Sul server sarà installato il Director, un
SD
e un
FD
. Appare chiaro che avremo almeno tre folder:bareos-
fd.d,bareos-sd.d e bareos-dir.d. Di seguito è riportato, per comodità, l’albero delle folder con l’indicazione
di massima delle rispettive funzioni.
In bareos-fd.d troviamo la congurazione dell’FD locale:
bareos-fd.d
client.........................................................Congurazione dell’FD locale
myself.conf
director ......................................... Congurazione del Director per l’FD locale
bareos-dir.conf
bareos-mon.conf
messages
Standard.conf
In bareos-sd.d troviamo le congurazioni dell’SD locale:
bareos-sd.d
autochanger
autochanger-0.conf ........................................Congurazione della TS3500
device
FileStorage.conf
Lib01.conf ........................................Congurazione del drive della TS3500
director ......................................... Congurazione del Director per l’SD locale
bareos-dir.conf
bareos-mon.conf
messages
Standard.conf
ndmp
storage
bareos-sd.conf
CNR SPR Reti e Sistemi Informativi

Una soluzione Open Source per un’infrastruttura di backup centralizzato:
Bareos e IBM TS3500 11
Inne, in bareos-dir.d, troviamo le congurazioni relative al Director locale:
bareos-dir.d
catalog
MyCatalog.conf
client...........................................................Congurazione client (CHI)
bareos-fd.conf
console
admin.conf
admin.conf.example
bareos-mon.conf
counter
director
bareos-dir.conf
fileset.......................................................Congurazione Fileset (COSA)
Catalog.conf
LinuxAll.conf
SelfTest.conf
Windows All Drives.conf
job
backup-bareos-fd.conf
BackupCatalog.conf
RestoreFiles.conf
jobdefs
DefaultJob.conf
messages
Daemon.conf
Standard.conf
pool ........................................................ Congurazione dei pool (DOVE)
Differential.conf
Full.conf
Incremental.conf
Scratch.conf
profile
operator.conf
webui-admin.conf
schedule...........................................Congurazione schedulazioni (QUANDO)
WeeklyCycleAfterBackup.conf
WeeklyCycle.conf
storage............................................................Congurazione degli SD
File.conf
Tape.conf
4.3. Definizione Autochanger sull’SD
Nel caso in esame l’SD è installato sulla stessa macchina del Director.
Come primo passo occorre denire, nell’SD, sia l’autochanger che il tape-driver.
Editiamo il le /etc/bareos/bareos-sd.d/autochanger/autochanger-0.conf indicando il device:
 
Autochanger {
Name = "autochanger-0"
Changer Device = /dev/tape/by-id/scsi-1IBM_03584L22_0000078A50660402
Device = Lib01
Changer Command = "/usr/lib/bareos/scripts/mtx-changer %c %o %S %a %d"
}
 
CNR SPR Reti e Sistemi Informativi

12
Una soluzione Open Source per un’infrastruttura di backup centralizzato:
Bareos e IBM TS3500
4.4. Definizione Device sull’SD
Editiamo il le /etc/bareos/bareos-sd.d/device/Lib01.conf:
 
Device {
Name = "Lib01"
DeviceType = tape
DriveIndex = 0
ArchiveDevice = /dev/tape/by-id/scsi-350050760440ad903-nst
MediaType = "3592"
Check Labels = yes
AutoChanger = yes # default: no
AutomaticMount = yes # default: no
MaximumFileSize = 10GB # default: 1000000000 (1GB)
}
 
4.5. Definizione Storage sul Director
Dal momento che sono deniti unicamente l’
SD
locale e il tipo File, occorre denire anche il tipo Tape
(sempre per l’SD locale).
Modichiamo il le /etc/bareos/bareos-dir.d/storage/Tape.conf
 
Storage {
Name = Tape
Address = bareos-prod-02.src.cnr.it
Password = "PASSWORD"
Device = autochanger-0
Media Type = "3592"
Autochanger = yes
}
 
ATTENZIONE: è necessario utilizzare il FQDN per l’Address dell’SD !!!
4.6. Definizione Pool
Di default vengono deniti quattro Pool: Full, Differential, Incremental e Scratch.
Pool Full
 
Pool {
Name = Full
Pool Type = Backup
Recycle = yes # Bareos can automatically recycle Volumes
AutoPrune = yes # Prune expired volumes
Volume Retention = 365 days # How long should the Full Backups be kept?
Maximum Volume Bytes = 50G # Limit Volume size to something reasonable
Maximum Volumes = 100 # Limit number of Volumes in Pool
Label Format = "Full-" # Volumes will be labeled "Full-<volume-id>"
}
 
CNR SPR Reti e Sistemi Informativi

Una soluzione Open Source per un’infrastruttura di backup centralizzato:
Bareos e IBM TS3500 13
Pool Differential
 
Pool {
Name = Differential
Pool Type = Backup
Recycle = yes # Bareos can automatically recycle Volumes
AutoPrune = yes # Prune expired volumes
Volume Retention = 90 days # How long should the Differential Backups be kept?
Maximum Volume Bytes = 10G # Limit Volume size to something reasonable
Maximum Volumes = 100 # Limit number of Volumes in Pool
Label Format = "Differential-" # Volumes will be labeled "Differential-<volume-id>"
}
 
Pool Incremential
 
Pool {
Name = Incremental
Pool Type = Backup
Recycle = yes # Bareos can automatically recycle Volumes
AutoPrune = yes # Prune expired volumes
Volume Retention = 30 days # How long should the Incremental Backups be kept?
Maximum Volume Bytes = 1G # Limit Volume size to something reasonable
Maximum Volumes = 100 # Limit number of Volumes in Pool
Label Format = "Incremental-" # Volumes will be labeled "Incremental-<volume-id>"
}
 
Pool Scratch:
 
Pool {
Name = Scratch
Pool Type = Scratch
}
 
ATTENZIONE:
Lo
Scratch Pool
è
univoco
per l’intero sistema Bareos anche se fossero deniti più
SD
con dispositivi e nastri differenti. Sarà poi cura di Bareos assegnare, di volta in volta, i nastri al Pool
appropriato.
I Pool appena descritti si riferiscono al backup su le e sono deniti con parametri generici. Dovendo
effettuare backup su Tape e dovendo impostare policy di Retention differenti, conviene riscrivere
completamente le congurazioni per adattare i Pool alle nostre esigenze. Non usiamo il pool Differential
ma esclusivamente i Full e gli Incremental. Inoltre i nastri sono già dotati della label di fabbrica e pertanto
non è necessario assegnarne un’altra.
Pool Tape-Full
 
Pool {
Name = Tape-Full
Pool Type = Backup
Recycle = yes
AutoPrune = yes
Volume Retention = 365 days
Maximum Volumes = 10
}
 
CNR SPR Reti e Sistemi Informativi

14
Una soluzione Open Source per un’infrastruttura di backup centralizzato:
Bareos e IBM TS3500
Pool Tape-Incremental
 
Pool {
Name = Tape-Incremental
Pool Type = Backup
Recycle = yes
AutoPrune = yes
Volume Retention = 30 days
Maximum Volumes = 5
}
 
4.7. Definizione Schedule
Di default sono deniti due Schedule:
Schedule WeeklyCycle.conf
 
Schedule {
Name = "WeeklyCycle"
Run = Full 1st sat at 21:00
Run = Differential 2nd-5th sat at 21:00
Run = Incremental mon-fri at 21:00
}
 
Schedule WeeklyCycleAfterBackup.conf
 
Schedule {
Name = "WeeklyCycleAfterBackup"
Description = "This schedule does the catalog. It starts after the WeeklyCycle."
Run = Full mon-fri at 21:10
}
 
Li rideniamo in questo modo per evitare il sovrapporsi di operazioni di backup di livello Full e
Incremental:
Schedule TapeWeeklyCycle.conf
 
Schedule {
Name = "TapeWeeklyCycle"
Run = Full 1st sat at 21:00
Run = Full 3rd sat at 21:00
Run = Incremental mon-fri at 21:00
}
 
Schedule TapeWeeklyCycleAfterBackup.conf
 
Schedule {
Name = "TapeWeeklyCycleAfterBackup"
Description = "This schedule does the catalog. It starts after the WeeklyCycle."
Run = Full mon-fri at 21:10
}
 
CNR SPR Reti e Sistemi Informativi

Una soluzione Open Source per un’infrastruttura di backup centralizzato:
Bareos e IBM TS3500 15
4.8. Definizione Jobdefs e Job
Di default è denito un
Jobdefs
e tre
Job
. Il primo è un template generico per un Job. I parametri
verranno poi sovrascritti dalle denizioni dei singoli Job.
jobdefs/DefaultJob.conf
 
JobDefs {
Name = "DefaultJob"
Type = Backup
Level = Incremental
Client = bareos-fd
FileSet = "SelfTest"
Schedule = "WeeklyCycle"
Storage = File
Messages = Standard
Pool = Incremental
Priority = 10
Write Bootstrap = "/var/lib/bareos/%c.bsr"
Full Backup Pool = Full
Differential Backup Pool = Differential
Incremental Backup Pool = Incremental
}
 
Ridenito così:
 
JobDefs {
Name = "DefaultJob"
Type = Backup
Level = Incremental
Client = bareos-fd
FileSet = "SelfTest"
Schedule = "TapeWeeklyCycle"
Storage = Tape
Messages = Standard
Pool = Tape-Incremental
Priority = 10
Write Bootstrap = "/var/lib/bareos/%c.bsr"
Full Backup Pool = Tape-Full
Incremental Backup Pool = Tape-Incremental
}
 
job/backup-bareos-fd.conf
 
Job {
Name = "backup-bareos-fd"
JobDefs = "DefaultJob"
Client = "bareos-fd"
}
 
che possiamo lasciare inalterato.
CNR SPR Reti e Sistemi Informativi

16
Una soluzione Open Source per un’infrastruttura di backup centralizzato:
Bareos e IBM TS3500
job/BackupCatalog.conf
 
Job {
Name = "BackupCatalog"
Description = "Backup the catalog database (after the nightly save)"
JobDefs = "DefaultJob"
Level = Full
FileSet="Catalog"
Schedule = "WeeklyCycleAfterBackup"
# This creates an ASCII copy of the catalog
# Arguments to make_catalog_backup.pl are:
# make_catalog_backup.pl <catalog-name>
RunBeforeJob = "/usr/lib/bareos/scripts/make_catalog_backup.pl MyCatalog"
# This deletes the copy of the catalog
RunAfterJob = "/usr/lib/bareos/scripts/delete_catalog_backup"
# This sends the bootstrap via mail for disaster recovery.
# Should be sent to another system, please change recipient accordingly
Write Bootstrap = "|/usr/bin/bsmtp -h localhost -f \"\(Bareos\) " -s \"Bootstrap for Job
%j\" root@localhost"
Priority = 11 # run after main backup
}
 
Ridenito così:
 
Job {
Name = "BackupCatalog"
Description = "Backup the catalog database (after the nightly save)"
JobDefs = "DefaultJob"
Level = Full
FileSet="Catalog"
Schedule = "TapeWeeklyCycleAfterBackup"
RunBeforeJob = "/usr/lib/bareos/scripts/make_catalog_backup.pl MyCatalog"
RunAfterJob = "/usr/lib/bareos/scripts/delete_catalog_backup"
Write Bootstrap = "|/usr/bin/bsmtp -h localhost -f \"\(Bareos\) \" -s \"Bootstrap for Job
%j\" giorgio.bartoccioni@cnr.it"
Priority = 11
}
 
Il Job di Restore è un job standard per eseguire il ripristino dei leset.
job/RestoreFiles.conf
 
Job {
Name = "RestoreFiles"
Description = "Standard Restore template. Only one such job is needed for all standard
Jobs/Clients/Storage ..."
Type = Restore
Client = bareos-fd
FileSet = "LinuxAll"
Storage = File
Pool = Incremental
Messages = Standard
Where = /tmp/bareos-restores
}
 
Lo rideniamo così:
CNR SPR Reti e Sistemi Informativi

Una soluzione Open Source per un’infrastruttura di backup centralizzato:
Bareos e IBM TS3500 17
 
Job {
Name = "RestoreFiles"
Description = "Standard Restore template.
Only one such job is needed for all standard Jobs/Clients/Storage ..."
Type = Restore
Client = bareos-fd
FileSet = "LinuxAll"
Storage = Tape
Pool = Tape-Incremental
Messages = Standard
Where = /tmp/bareos-restores
}
 
Per automatizzare le operazioni di ripristino può essere conveniente creare nuovi job di restore
personalizzati con il nome del client ed il relativo leset.
4.9. Definizione Messages
La congurazione dei Message denisce principalmente a chi inviare le mail prodotte dalle varie
operazioni. Le mail sono sufcientemente dettagliate, così da spiegare con chiarezza e precisione che
cosa sta succedendo.
Di default sono deniti due le:
messages/Daemon.conf
 
Messages {
Name = Daemon
Description = "Message delivery for daemon messages (no job)."
mailcommand = "/usr/bin/bsmtp -h localhost -f \"\(Bareos\) \<%r\>\" -s \"Bareos daemon
message\" %r"
mail = root@localhost = all, !skipped, !audit # (#02)
console = all, !skipped, !saved, !audit
append = "/var/log/bareos/bareos.log" = all, !skipped, !audit
append = "/var/log/bareos/bareos-audit.log" = audit
}
 
e
messages/Standard.conf
 
Messages {
Name = Standard
Description = "Reasonable message delivery -- send most everything to email address and
to the console."
operatorcommand = "/usr/bin/bsmtp -h localhost -f \"\(Bareos\) \<%r\>\" -s \"Bareos:
Intervention needed for %j\" %r"
mailcommand = "/usr/bin/bsmtp -h localhost -f \"\(Bareos\) \<%r\>\" -s \ "Bareos: %t %e
of %c %l\" %r"
operator = giorgio.bartoccioni@cnr.it = mount
mail = giorgio.bartoccioni@cnr.it = all, !skipped, !saved, !audit
console = all, !skipped, !saved, !audit
append = "/var/log/bareos/bareos.log" = all, !skipped, !saved, !audit
catalog = all, !skipped, !saved, !audit
}
 
In entrambi i le modichiamo root@localhost in qualcosa di appropriato.
CNR SPR Reti e Sistemi Informativi

18
Una soluzione Open Source per un’infrastruttura di backup centralizzato:
Bareos e IBM TS3500
4.10. Avvio dei servizi
Dopo aver modicato i le di congurazione avviamo i servizi:
 
# service bareos-sd start
# service bareos-dir start
# service bareos-fd start
 
4.10.1. Preparazione dei nastri
Una volta avviati i servizi dobbiamo informare Bareos di quanti e quali nastri disponiamo nella Tape.
Dalla versione 16.2 l’interfaccia web ha una apposita sezione per gestire l’autochanger ed è quindi
possibile eseguire le operazioni necessarie sia da bconsole che da WEBUI.
In bconsole, con il comando
update slots
, diciamo a Bareos di fare un inventario dei nastri disponibili
nella Tape. Ovviamente, essendo il primo avvio, Bareos ci informerà che nessuno dei nastri trovati è
presente nel Catalog.
 
# bconsole
Connecting to Director localhost:9101
1000 OK: bareos-dir Version: 16.2.4 (01 July 2016)
Enter a period to cancel a command.
*update slots
Automatically selected Catalog: MyCatalog
Using Catalog "MyCatalog"
Automatically selected Storage: Tape
Connecting to Storage daemon Tape at bareos-prod-02:9103 ...
3306 Issuing autochanger "slots" command.
Device "autochanger-0" has 313 slots.
Connecting to Storage daemon Tape at bareos-prod-02:9103 ...
3306 Issuing autochanger "list" command.
Volume "F00030JC" not found in catalog. Slot=1 InChanger set to zero.
Volume "F00031JC" not found in catalog. Slot=2 InChanger set to zero.
Volume "F00032JC" not found in catalog. Slot=3 InChanger set to zero.
Volume "F00033JC" not found in catalog. Slot=4 InChanger set to zero.
Volume "F00034JC" not found in catalog. Slot=5 InChanger set to zero.
Volume "F00035JC" not found in catalog. Slot=6 InChanger set to zero.
Volume "F00036JC" not found in catalog. Slot=7 InChanger set to zero.
Volume "F00037JC" not found in catalog. Slot=8 InChanger set to zero.
Volume "F00027JC" not found in catalog. Slot=9 InChanger set to zero.
Volume "F00028JC" not found in catalog. Slot=10 InChanger set to zero.
Volume "F00029JC" not found in catalog. Slot=11 InChanger set to zero.
Volume "F00021JC" not found in catalog. Slot=12 InChanger set to zero.
Volume "F00022JC" not found in catalog. Slot=13 InChanger set to zero.
Volume "F00023JC" not found in catalog. Slot=14 InChanger set to zero.
Volume "F00024JC" not found in catalog. Slot=15 InChanger set to zero.
Volume "F00025JC" not found in catalog. Slot=16 InChanger set to zero.
Volume "F00026JC" not found in catalog. Slot=17 InChanger set to zero.
*
 
Il passo successivo è quello di usare il comando
label barcodes
. Si può usare sia da command line
che dalla WEBUI. Occorre prestare attenzione perché può accadere che si debba eseguire il comando
più volte per scrivere le Label su tutti i nastri. Questi verranno aggiunti al
Pool Scratch
dal quale poi
verranno presi all’occorrenza e in maniera automatica.
CNR SPR Reti e Sistemi Informativi

Una soluzione Open Source per un’infrastruttura di backup centralizzato:
Bareos e IBM TS3500 19
Figura 4.2.: Scansione dei barcodes dalla WEBUI
4.11. Esecuzione primo Job
È ora possibile far girare un Job per accertare il corretto funzionamento della tape. Al termine dell’ope-
razione dovrebbe essere possibile ottenere un Success nella WEBUI.
Figura 4.3.: Esecuzione di un Job dalla WEBUI
CNR SPR Reti e Sistemi Informativi

20
Una soluzione Open Source per un’infrastruttura di backup centralizzato:
Bareos e IBM TS3500
Possiamo leggere un riepilogo del Job appena eseguito come nell’esempio sotto riportato.
Riepilogo del Job
 
2017-02-10 15:05:15 bareos-dir JobId 3: Bareos bareos-dir 16.2.4 (01Jul16):
Build OS: x86_64-redhat-linux-gnu redhat CentOS Linux release 7.0.1406 (Core)
JobId: 3
Job: backup-bareos-fd.2017-02-10_15.04.06_57
Backup Level: Full (upgraded from Incremental)
Client: "bareos-fd" 16.2.4 (01Jul16) x86_64-redhat-linux-gnu,redhat,CentOS Linux release
7.0.1406 (Core) ,CentOS_7,x86_64
FileSet: "SelfTest" 2017-02-10 12:31:36
Pool: "Tape-Full" (From Job FullPool override)
Catalog: "MyCatalog" (From Client resource)
Storage: "Tape" (From Job resource)
Scheduled time: 10-Feb-2017 15:04:06
Start time: 10-Feb-2017 15:04:08
End time: 10-Feb-2017 15:05:15
Elapsed time: 1 min 7 secs
Priority: 10
FD Files Written: 426
SD Files Written: 426
FD Bytes Written: 43,506,902 (43.50 MB)
SD Bytes Written: 43,550,904 (43.55 MB)
Rate: 649.4 KB/s
Software Compression: None
VSS: no
Encryption: no
Accurate: no
Volume name(s): F00030JC
Volume Session Id: 2
Volume Session Time: 1486727423
Last Volume Bytes: 43,596,417 (43.59 MB)
Non-fatal FD errors: 0
SD Errors: 0
FD termination status: OK
SD termination status: OK
Termination: Backup OK
 
È presente anche un log delle azioni svolte da Bareos (NB: l’ordine cronologico è inverso).
1. Bareos ci avverte che non sono presenti precedenti backup di tipo FULL,
2. espulsione del nastro dal drive Lib01,
3. scelta del nastro F00030JC dal Pool Scratch,
4. inizio backup con JobId=3,
5. caricamento del Nastro nel drive Lib01,
6. check dello stato dell’autochanger,
7. scrittura del nastro.
CNR SPR Reti e Sistemi Informativi

Una soluzione Open Source per un’infrastruttura di backup centralizzato:
Bareos e IBM TS3500 21
Log del Job
 
2017-02-10 15:05:13 bareos-sd JobId 3: Elapsed time=00:00:01, Transfer rate=43.55 M Bytes/second
2017-02-10 15:05:12 bareos-sd JobId 3: Wrote label to prelabeled Volume "F00030JC" on device "
Lib01"
(/dev/tape/by-id/scsi-350050760440ad903-nst)
2017-02-10 15:05:10 bareos-sd JobId 3: 3305 Autochanger "load slot 1, drive 0", status is OK.
2017-02-10 15:04:53 bareos-sd JobId 3: 3304 Issuing autochanger "load slot 1, drive 0" command.
2017-02-10 15:04:08 bareos-dir JobId 3: Start Backup JobId 3, Job=backup-bareos-fd.2017-02-10_15
.04.06_57
2017-02-10 15:04:08 bareos-dir JobId 3: Using Volume "F00030JC" from ’Scratch’ pool.
2017-02-10 15:04:08 bareos-dir JobId 3: Using Device "Lib01" to write.
2017-02-10 15:04:08 bareos-sd JobId 3: 3307 Issuing autochanger "unload slot 16, drive 0"
command.
2017-02-10 15:04:06 bareos-dir JobId 3: No prior Full backup Job record found.
 
CNR SPR Reti e Sistemi Informativi

Capitolo 5
Aggiungiamo un client
L’aggiunta di un client prevede l’esecuzione di operazioni sia sul server che sul client. Occorre denire:
CHI
,
COSA
,
QUANDO
e
DOVE
, corrispondenti a
CLIENT
,
FILESET
,
SCHEDULER
e
POOL
. Si possono poi
denire delle ACL per l’accesso riservato alla
Web-UI
, e dei
Retention period
appropriati alle politiche
aziendali o di legge.
5.1. Sul server
Occorre denire le risorse necessarie per gestire il backup del nuovo client: il client, il leset, i pool e il
job.
A partire dalla versione 16.2 Bareos mette a disposizione un apposito comando per la sola denizione
del client partendo dal nome e dall’FQDN. Accediamo quindi alla bconsole ed eseguiamo il comando
congure:
 
*configure add client name=alf4fp address=alf4fp.cedrc.cnr.it password=UNAPASSWORD
Exported resource file "/etc/bareos/bareos-dir-export/client/alf4fp/bareos-fd.d/director/bareos-
dir.conf":
Director {
Name = bareos-dir
Password = "[md5]ae1e74b9d9c077939fb6a4b6489ffad3"
}
Created resource config file "/etc/bareos/bareos-dir.d/client/alf4fp.conf":
Client {
Name = alf4fp
Address = alf4fp.cedrc.cnr.it
Password = UNAPASSWORD
}
 
Il comando crea il le di denizione del client sul server e un altro le con la denizione del director
(ovvero se stesso) da copiare sul client:
/etc/bareos/bareos-dir.d/client/alf4fp.conf
/etc/bareos/bareos-dir-export/client/alf4fp/bareos-fd.d/director/bareos-dir.conf
Eseguiamo un reload del director:
 
# bconsole
Connecting to Director localhost:9101
1000 OK: bareos-dir Version: 16.2.4 (01 July 2016)
Enter a period to cancel a command.
*reload
reloaded
 
5.2. Sul client
Installiamo il bareos-fd sul client. Per semplicità consideriamo solo l’installazione per SO CentOS 7.
 
# wget -O /etc/yum.repos.d/bareos.repo http://download.bareos.org/bareos/release/latest/
CentOS_7/bareos.repo
# yum update
# yum install bareos-filedaemon
 
23

24
Una soluzione Open Source per un’infrastruttura di backup centralizzato:
Bareos e IBM TS3500
Copiamo (o riscriviamo) il le creato sul server:
/etc/bareos/bareos-dir-export/client/alf4fp/bareos-fd.d/director/bareos-dir.conf
nella folder /etc/bareos/bareos-fd.d/director.
Quindi riavviamo il le-daemon:
 
# service bareos-fd restart
 
5.3. Torniamo sul server
Controlliamo che il client e il server possano comunicare correttamente:
 
# bconsole
Connecting to Director localhost:9101
1000 OK: bareos-dir Version: 16.2.4 (01 July 2016)
Enter a period to cancel a command.
*list clients
+----------+-----------+---------------+--------------+
| clientid | name | fileretention | jobretention |
+----------+-----------+---------------+--------------+
| 1 | bareos-fd | 5,184,000 | 15,552,000 |
| 2 | alf4fp | 0 | 0 |
+----------+-----------+---------------+--------------+
*
 
La macchina in oggetto è un server su cui gira Alfresco e sono pertanto da sottoporre a backup il
content-store, il database PostgreSQL, i le di congurazione e i le di log. Deniamo il
Job
e il
Fileset
.
Per quanto riguarda il database utilizziamo la direttiva
RunScript
per eseguire il dump e per eliminarlo
al termine delle operazioni. Il dump prodotto verrà poi incluso nel backup, come un qualunque altro
le.
CNR SPR Reti e Sistemi Informativi

Una soluzione Open Source per un’infrastruttura di backup centralizzato:
Bareos e IBM TS3500 25
 
# vim /etc/bareos/bareos-dir.d/fileset/alf4fp.conf
FileSet {
Name = "alf4fp"
Include {
Options {
signature = MD5
compression = gzip
}
# database dump file
File = "/opt/DUMP/postgresql_dump.sql"
File = "/DATA"
File = "/home/tomcat"
}
}
# vim /etc/bareos/bareos-dir.d/job/alf4fp.conf
Job {
Name = "alf4fp"
JobDefs = "DefaultJob"
Client = alf4fp
Level = Full
FileSet="alf4fp"
# This creates a dump of our database in the local filesystem on the client
RunScript {
FailJobOnError = Yes
RunsOnClient = Yes
RunsWhen = Before
Command = "sh -c ’PGPASSWORD=UNAPASSWORD /home/tomcat/alfresco-community/
postgresql/bin/pg_dump -U alfresco -f /opt/DUMP/postgresql_dump.sql alfresco
’"
}
# This deletes the dump in our local filesystem on the client
RunScript {
RunsOnSuccess = Yes
RunsOnClient = Yes
RunsWhen = After
Command = "rm /opt/DUMP/postgresql_dump.sql"
}
}
 
Lanciamo il Job per confermare le congurazioni:
CNR SPR Reti e Sistemi Informativi

26
Una soluzione Open Source per un’infrastruttura di backup centralizzato:
Bareos e IBM TS3500
 
# bconsole
Connecting to Director localhost:9101
1000 OK: bareos-dir Version: 16.2.4 (01 July 2016)
Enter a period to cancel a command.
*reload
reloaded
*run job=alf4fp.job
Using Catalog "MyCatalog"
Run Backup job
JobName: alf4fp
Level: Full
Client: alf4fp
Format: Native
FileSet: alf4fp
Pool: Tape-Full (From Job FullPool override)
Storage: Tape (From Job resource)
When: 2017-02-14 15:59:01
Priority: 10
OK to run? (yes/mod/no):
 
Una volta avviato il Job possiamo controllare i Messages, via email, bconsole o WEBUI, per assicurarci il
corretto funzionamento. Possiamo quindi procedere con l’aggiunta di ulteriori client.
5.4. Backup di Database
È possibile eseguire il backup di Postgresql e MySQL denendo un Job simile al seguente:
 
Job {
Name = "NOMEJOB"
JobDefs = "DefaultJob"
Client = "NOMECLIENT"
Level = Full
FileSet="NOMEFILESET"
RunScript {
FailJobOnError = Yes
RunsOnClient = Yes
RunsWhen = Before
Command = "sh -c ’XXX’"
}
RunScript {
RunsOnSuccess = Yes
RunsOnClient = Yes
RunsWhen = After
Command = "rm FILEYYY"
}
}
 
Sostituire a XXX il seguente comando per MySQL
mysqldump –user=root –password=PASSWORD –opt –all-databases >FILEYYY
oppure, per PostgreSQL:
PGPASSWORD=USERPASSWORD pg_dump -U DBUSER -f FILEYY DBNAME
Una volta che il dump è stato creato, il le generato può essere inserito nella denizione del Fileset.
CNR SPR Reti e Sistemi Informativi

Una soluzione Open Source per un’infrastruttura di backup centralizzato:
Bareos e IBM TS3500 27
5.5. Rimuovere un client
Non è al momento possibile rimuovere un client in maniera semplice e sicura. È però possibile disabili-
tare il client in maniera temporanea (no al riavvio del servizio bareos-dir) o in maniera permanente.
Nel primo caso occorre accedere alla bconsole ed eseguire il comando:
 
# bconsole
Connecting to Director localhost:9101
1000 OK: bareos-dir Version: 16.2.4 (01 July 2016)
Enter a period to cancel a command.
*disable client=NOMECLIENT
 
Nel secondo caso occorre inserire nel le di congurazione del client
/etc/bareos/bareos-dir.d/client/NOMECLIENT la direttiva Enabled=no
 
Client {
Name = NOMECLIENT
Address = CLIENTADDRESS
Password = "PASSWORD"
Enabled = no
}
 
È possibile generare una lista di client disabilitati mediante il comando bconsole
list clients disabled
oppure, al contrario, list clients enabled per avere una lista dei client abilitati.
CNR SPR Reti e Sistemi Informativi

Capitolo 6
Restore
La procedura di restore è, come di consueto, intuitiva. Si può procedere dall’interfaccia web
Bareos-WebUI
o da linea di comando con la
bconsole
. È possibile ripristinare sullo stesso client da cui è stato fatto il
backup o su un altro client (già denito in Bareos).
Verrà descritta la procedura dalla bconsole.
 
# bconsole
Connecting to Director localhost:9101
1000 OK: bareos-dir Version: 16.2.4 (01 July 2016)
Enter a period to cancel a command.
*
*restore all
First you select one or more JobIds that contain files
to be restored. You will be presented several methods
of specifying the JobIds. Then you will be allowed to
select which files from those JobIds are to be restored.
To select the JobIds, you have the following choices:
1: List last 20 Jobs run
2: List Jobs where a given File is saved
3: Enter list of comma separated JobIds to select
4: Enter SQL list command
5: Select the most recent backup for a client
6: Select backup for a client before a specified time
7: Enter a list of files to restore
8: Enter a list of files to restore before a specified time
9: Find the JobIds of the most recent backup for a client
10: Find the JobIds for a backup for a client before a specified time
11: Enter a list of directories to restore for found JobIds
12: Select full restore to a specified Job date
13: Cancel
Select item: (1-13):
 
Le opzioni sono numerose. Per gli scopi di questo documento selezioniamo la voce
7: Enter a list
of files to restore
. Quindi scegliamo il client tra quelli proposti dalla bconsole. A questo punto
occorre inserire il nome del le da ripristinare con il path completo.
29

30
Una soluzione Open Source per un’infrastruttura di backup centralizzato:
Bareos e IBM TS3500
 
Enter file names with paths, or < to enter a filename
containing a list of file names with paths, and terminate
them with a blank line.
Enter full filename:
Enter full filename: /home/giorgio/Scrivania/dl.png
Enter full filename:
Bootstrap records written to /var/lib/bareos/bareos-dir.restore.2.bsr
The job will require the following
Volume(s) Storage(s) SD Device(s)
===========================================================================
*F00034JC Tape autochanger-0
Volumes marked with "*" are online.
1 file selected to be restored.
Using Catalog "MyCatalog"
Run Restore job
JobName: RestoreFiles
Bootstrap: /var/lib/bareos/bareos-dir.restore.2.bsr
Where: /tmp/bareos-restores
Replace: Always
FileSet: LinuxAll
Backup Client: bartoccioni
Restore Client: bartoccioni
Format: Native
Storage: Tape
When: 2017-03-21 18:17:17
Catalog: MyCatalog
Priority: 10
Plugin Options: *None*
OK to run? (yes/mod/no): mod
 
Ci viene proposto il job standard per il restore ma è possibile modicarlo secondo le nostre esigenze. In
questo caso vogliamo modicare il Fileset.
 
Parameters to modify:
1: Level
2: Storage
3: Job
4: FileSet
5: Restore Client
6: Backup Format
7: When
8: Priority
9: Bootstrap
10: Where
11: File Relocation
12: Replace
13: JobId
14: Plugin Options
Select parameter to modify (1-14): 4
 
Avendo selezionato la voce numero 4, ci viene proposta una lista dei Fileset deniti:
CNR SPR Reti e Sistemi Informativi

Una soluzione Open Source per un’infrastruttura di backup centralizzato:
Bareos e IBM TS3500 31
 
The defined FileSet resources are:
1: Windows All Drives
2: webrainbow
3: smc
4: SelfTest
5: ovirt-engine
6: nfshosting
7: mydb
8: moodle-prod-db
9: mivar.rm.cnr.it
10: LinuxAll
11: jsiglanfs
12: issirfa-hosting
13: intermapper
14: gesportpolitica1
15: foreman
16: epasdb
17: dbserver1
18: dbos
19: db1
20: Catalog
21: bartoccioni
22: as12-alfservizipdr
23: as12-alfselezioni
24: as11-alfproto
25: as11-alfgestdoc
26: alf4fp
Select FileSet resource (1-26): 21
Run Restore job
JobName: RestoreFiles
Bootstrap: /var/lib/bareos/bareos-dir.restore.2.bsr
Where: /tmp/bareos-restores
Replace: Always
FileSet: bartoccioni
Backup Client: bartoccioni
Restore Client: bartoccioni
Format: Native
Storage: Tape
When: 2017-03-21 18:17:17
Catalog: MyCatalog
Priority: 10
Plugin Options: *None*
OK to run? (yes/mod/no): yes
Job queued. JobId=623
 
A questo punto il job è in coda e, una volta terminato, controlliamo il risultato vericando l’effettivo
ripristino del le. Ovviamente è possibile controllare lo stato del job con il comando, sempre da bconsole,
status jobid=XXX
dove XXX è l’id del job. Verichiamo con md5sum se il le è stato correttamente
ripristinato:
 
# ll /tmp/bareos-restores/home/giorgio/Scrivania/dl.png
-rw-rw-r-- 1 giorgio giorgio 24349 mar 15 14:25 bareos-restores/home/giorgio/Scrivania/dl.png
# md5sum /tmp/bareos-restores/home/giorgio/Scrivania/dl.png
af17c259d73e0939082e7ba0a8df99a2 /tmp/bareos-restores/home/giorgio/Scrivania/dl.png
root@ruc:/tmp# md5sum /home/giorgio/Scrivania/dl.png
af17c259d73e0939082e7ba0a8df99a2 /home/giorgio/Scrivania/dl.png
 
Al termine dell’operazione, con il comando
message
da bconsole, abbiamo inoltre un dettaglio del
processo.
CNR SPR Reti e Sistemi Informativi

32
Una soluzione Open Source per un’infrastruttura di backup centralizzato:
Bareos e IBM TS3500
In casi particolari (i.e.: Continuos Integration) può sorgere la necessità di automatizzare il ripristino
di leset sullo stesso client o su client differenti. Il problema può essere risolto denendo i client e
inserendo in crontab, sul director, il comando:
0 8 * * * ( echo restore client=CLIENT1 select current all done restoreclient=CLIENT2 yes |
/usr/sbin/bconsole ) > /tmp/restore.log 2>&1
Ogni giorno, alle 8 di mattina, viene eseguito il ripristino dell’ultimo backup disponibile di CLIENT1 su
CLIENT2.
CNR SPR Reti e Sistemi Informativi

Capitolo 7
Notifiche
Il sistema di notiche di Bareos è potente e articolato ma semplice da comprendere e congurare.
Nella folder
/etc/bareos/bareos-dir.d/messages
si trovano i le necessari alla denizione di tutte le
notiche del sistema con la possibilità di impostarle anche per il singolo Job.
In una nuova installazione di Bareos vengono denite due notiche di base:
Daemon.conf
, per
notiche generiche del servizio, e
Standard.conf
, richiamata nel template
JobDefs
con la sintassi
Messages=Standard.
È possibile copiare e modicare il le
Standard.conf
per ridenire notiche relative a particolari
Job. Potremmo per esempio decidere di inviare un semplice report a un certo indirizzo e inviare gli
errori a un altro indirizzo. Una volta modicata la denizione, possiamo assegnarla al rispettivo Job
semplicemente inserendo, nella denizione del Job, la stringa Messages=NomeNotifica.
Per specicare dove e quando inviare le notiche, occorre denire una o più
destination
utilizzando
una delle due sintassi:
•destination = message-type1,message-type2,...
•destination = address = message-type1,message-type2,...
La seconda sintassi è ovviamente necessaria per quelle
destination
che necessitano di un indirizzo.
Nel caso di invio tramite posta elettronica, Bareos utilizzerà il proprio comando
bsmtp
per il quale sono
disponibili le seguenti variabili:
•%% = %
•%c = Client’s name
•%e = Job Exit code (OK, Error, ...)
•%h = Client address
•%i = Job Id
•%j = Unique Job name
•%l = Job level
•%n = Job name
•%r = Recipients
•%s = Since time
•%t = Job type (e.g. Backup, ...)
•%v = Read Volume name (Only on director side)
•%V = Write Volume name (Only on director side)
Nella tabella seguente una descrizione delle destination:
33

34
Una soluzione Open Source per un’infrastruttura di backup centralizzato:
Bareos e IBM TS3500
Destination Description
director
Messages are sent to the current director that started the
job.
le
Messages are sent to a lename specied in the address
eld, where the le is overwritten if already exists.
append
Messages are sent to a lename specied in the address
eld, where the messages are appended to the le if already
exists.
syslog Send the messages to syslog; the address eld is ignored.
mail
Messages are sent to the comma-separated email addres-
ses specied by the address eld. An email is sent on every
job run, so a lot of messages can be generated during the
night.
mail on error
Same as mail destination, except that messages are only
sent when the job terminates with an error condition.
mail on success
Same as mail destination, except that messages are only
sent when the job terminates normally.
operator
Same as mail destination, except that each messages is sent
as received, generating one email per message.
console Messages are sent to the Bacula console.
stdout Messages are sent to stdout.
stderr Messages are sent to stderr.
catalog
Messages are sent to catalog database, which are written
to the Log table with a timestamp of message generation,
which can be used to log reporting programs.
Per ogni destination possiamo specicare i message-type come da tabella seguente:
Message-Type Description
info Information messages.
warning Warning messages.
error Error messages, which don’t cause the Job to terminate.
fatal Fatal error messages, which cause the Job to terminate.
terminate Messages generated when the daemon shuts down.
notsaved
Messages generated when the les are not saved, usually
because they cannot be accessed.
skipped
Messages generated when the les are skipped, usually
because of an incremental backup or le exclusion list.
mount
Messages generated on volume mounts from storage
daemon.
restored Messages generated for each restored le.
all All messages.
security
Security related messages usually an unauthorized
connection attempts.
alert Alert messages.
volmgmt Volume management messages.
Nel listato seguente è mostrata la denizione della notica standard:
CNR SPR Reti e Sistemi Informativi

Una soluzione Open Source per un’infrastruttura di backup centralizzato:
Bareos e IBM TS3500 35
Denizione della notica Standard.conf
 
Messages {
Name = Standard
Description = "Reasonable message delivery send most everything to email address and to
the console"
operatorcommand = "/usr/bin/bsmtp -h localhost -f \"\(Bareos\) \<%r\>\" -s \"Bareos:
Intervention needed for %j\" %r"
mailcommand = "/usr/bin/bsmtp -h localhost -f \"\(Bareos\) \<%r\>\" -s \"Bareos: %t %e of
%c %l\" %r"
operator = root@localhost = mount
mail = root@localhost = all, !skipped, !saved, !audit
console = all, !skipped, !saved, !audit
append = "/var/log/bareos/bareos.log" = all, !skipped, !saved, !audit
catalog = all, !skipped, !saved, !audit
}
 
Analizzando la denizione troviamo prima di tutto il nome e la descrizione, quindi i comandi necessari
all’invio dei messaggi relativi all’operatore e per il generico invio di email e, in ultimo, diverse desti-
nazioni (console, append e catalog) con i relativi Message-Type. Modicando le denizioni possiamo
personalizzare i messaggi e gli invii.
CNR SPR Reti e Sistemi Informativi

Capitolo 8
ACL
Al crescere del numero di client, potrebbe sorgere l’esigenza di rafnare i meccanismi di accesso
attraverso la denizione di adeguate regole. Bareos, dalla versione 16.2, mette a disposizione una nuova
implementazione delle
ACL
con le quali è possibile denire in maniera dettagliata proprio le regole di
accesso.
In questo documento si descrive l’uso delle
ACL
per la sola
Web-UI
. Ipotizziamo di voler concedere
ad un utente la possibilità di controllare l’esecuzione dei job, di backup o ripristino, relativi ad un certo
set di client. Sul server dove è in esecuzione il bareos-director occorre creare due nuovi le:
•/etc/bareos/bareos-dir.d/console/nomeutente.conf
•/etc/bareos/bareos-dir.d/prole/webui-nomeutente.conf
Il primo denisce un nuovo utente associando ad esso un certo prolo. Il secondo dettaglia il prolo.
Nel listato 8è mostrato il le di denizione dell’utente. Occorre semplicemente valorizzare: nome,
password e prolo associato all’utente.
File nomeutente.conf
 
Console {
Name = nomeutente
Password = "password"
Profile = "webui-nomeutente"
}
 
Nel listato 8è mostrato il prolo assegnato all’utente. Per limitare le azioni possibili ai soli client associati
all’utente (in questo esempio
client1
) occorre specicare soprattutto i parametri
Job ACL
e
Client ACL
.
File webui-nomeutente.conf
 
Profile {
Name = "webui-nomeutente"
CommandACL = !.bvfs_clear_cache, !.exit, !.sql, !configure, !create, !delete, !purge, !
sqlquery, !umount, !unmount, *all*
Job ACL = "Restore_client1", "client1"
Catalog ACL = *all*
Pool ACL = *all*
Client ACL = "client1"
FileSet ACL = *all*
Where ACL = *all*
}
 
Eseguendo un reload dalla bconsole e accedendo alla Web-UI, è ora possibile eseguire il login con il
nomeutente e la password deniti e accedere ai job relativi al solo client client1.
Per maggiori dettagli si rimanda alla documentazione [2].
37

Appendice A
Breviario Bareos
A.1. Che succede?
Quali le verranno inseriti nel backup? show lesets I=Included, E=Excluded
Che cosa sta facendo il server? status dir
Qual è lo stato del Job? status jobid=xx
Qual è lo stato del client? status client
Qual è lo stato dello storage? status storage
Novità? messages
A.2. Backup
Avviare un backup run . . . scegliere il Job
A.3. Ripristino
Ripristino dell’ultima versione di un le dopo averlo eliminato:
•Utilizzare il comando restore.
•Scegliere l’opzione 5 (Select the most recent backup for a client).
•cd / ls / dir / mark / markdir / unmark / unmarkdir / lsmark / estimate / pwd / count / nd
•done
A.4. Jobs
Ultimo job list jobs
Statistiche sull’ultimo job list jobtotal
Di quali le è stato effettuato il backup? list les jobid=xx
39

40
Una soluzione Open Source per un’infrastruttura di backup centralizzato:
Bareos e IBM TS3500
A.4.1. Stato di un Job
Stato signicato
T Terminated normally
C Created but not yet running
R Running
B Blocked
E Terminated in Error
e Non-fatal error
f Fatal error
D Verify Differences
A Canceled by the user
F Waiting on the File daemon
S Waiting on the Storage daemon
m Waiting for a new Volume to be mounted
M Waiting for a Mount
s Waiting for Storage resource
j Waiting for Job resource
c Waiting for Client resource
d Wating for Maximum jobs
t Waiting for Start Time
p Waiting for higher priority job to nish
A.5. Tapes
Which tapes are in the pool? list media
Remove a tape delete media
Which pools are dened? list pools
Which tapes are/were used for a certain job? list jobmedia
Assign a tape to a certain pool add
Change parameters of a tape update volume
CNR SPR Reti e Sistemi Informativi

Appendice B
Breviario mt e mtx [3]
B.1. Display status of the tape/drive
 
mt status
mt -f /dev/st0 status
 
B.2. Rewinds the tape
 
mt rew
mt rewind
mt -f /dev/mt/0 rewind
mt -f /dev/st0 rewind
 
B.3. Eject the tape
 
mt off
mt offline
mt eject
mt -f /dev/mt/0 off
mt -f /dev/st0 eject
 
B.4. Erase the tape (rewind the tape and, if applicable, unload the tape)
 
mt erase
mt -f /dev/st0 erase #Linux
mt -f /dev/rmt/0 erase #Unix
 
B.5. Retensioning a magnetic tape cartridge
If errors occur when a tape is being read, you can retension the tape, clean the tape drive, and then try
again as follows:
 
mt retension
mt -f /dev/rmt/1 retension #Unix
mt -f /dev/st0 retension #Linux
 
B.6. Writes n EOF marks in the current position of tape
 
mt eof
mt weof
mt -f /dev/st0 eof
 
41

42
Una soluzione Open Source per un’infrastruttura di backup centralizzato:
Bareos e IBM TS3500
B.7. Forward space count files i.e. jumps n EOF marks
The tape is positioned on the rst block of the next le i.e. tape will position on rst block of the eld
(see g.01):
 
mt fsf
mt -f /dev/rmt/0 fsf
mt -f /dev/rmt/1 fsf 1 #go 1 forward file/tape (see fig.01)
 
B.8. Backward space count files i.e. rewinds n EOF marks
The tape is positioned on the rst block of the next le i.e. tape positions after EOF mark (see g.01):
 
mt bsf
mt -f /dev/rmt/1 bsf
mt -f /dev/rmt/1 bsf 1 #go 1 backward file/tape (see fig.01)
 
Here is a list of the tape position commands:
•fsf Forward space count les. The tape is positioned on the rst block of the next le.
•fsfm Forward space count les. The tape is positioned on the last block of the previous le.
•bsf Backward space count les. The tape is positioned on the last block of the previous le.
•bsfm Backward space count les. The tape is positioned on the rst block of the next le.
•asf
The tape is positioned at the beginning of the count le. Positioning is done by rst rewinding
the tape and then spacing forward over count lemarks.
•fsr Forward space count records.
•bsr Backward space count records.
•fss (SCSI tapes) Forward space count setmarks.
•bss (SCSI tapes) Backward space count setmarks.
B.9. To backup directory (tar format)
 
tar cvf /dev/rmt/0n /etc
tar cvf /dev/st0 /etc
 
B.10. To restore directory (tar format)
 
tar xvf /dev/rmt/0n -C /path/to/restore
tar xvf /dev/st0 -C /tmp
 
B.11. List or check tape contents (tar format)
 
mt -f /dev/st0 rewind; dd if=/dev/st0 of=-
## tar format ##
tar tvf {DEVICE} {Directory-FileName}
tar tvf /dev/st0
tar tvf /dev/st0 desktop
tar tvf /dev/rmt/0 foo > list.txt
 
CNR SPR Reti e Sistemi Informativi

Una soluzione Open Source per un’infrastruttura di backup centralizzato:
Bareos e IBM TS3500 43
B.12. Backup partition with dump or ufsdump
 
## Linux backup /home partition ##
dump 0uf /dev/nst0 /dev/sda5
dump 0uf /dev/nst0 /home
restore rf /dev/nst0
## Restore interactive from the 6th backup on the tape media ##
restore isf 6 /dev/nst0
 
B.13. Start writing at the beginning of the tape
 
## This will overwrite all data on tape ##
mt -f /dev/st1 rewind
### Backup home ##
tar cvf /dev/st1 /home
## Offline and unload tape ##
mt -f /dev/st0 offline
 
To restore from the beginning of the tape:
 
mt -f /dev/st0 rewind
tar xvf /dev/st0
mt -f /dev/st0 offline
 
B.14. Start writing after the last tar
 
## This will kee all data written so far ##
mt -f /dev/st1 eom
### Backup home ##
tar cvf /dev/st1 /home
## Unload ##
mt -f /dev/st0 offline
 
B.15. Start writing after tar number 2
 
## To wrtite after tar number 2 (should be 2+1)
mt -f /dev/st0 asf 3
tar cvf /dev/st0 /usr
 
To restore tar from tar number 2:
 
mt -f /dev/st0 asf 3
tar xvf /dev/st0
mt -f /dev/st0 offline
 
CNR SPR Reti e Sistemi Informativi

Appendice C
Relabeling
In alcuni casi può essere utile assegnare una nuova
label
ad un Volume ad esempio nel caso di riutilizzo
di nastri già labellati, a cui vogliamo però assegnare una label corrispondente al codice a barre di fabbrica.
Non è semplice eseguire l’operazione da Bareos ma si possono utilizzare i comandi mt e mtx-changer
(di Bareos). L’operazione consiste nel sovrascrivere, all’interno del nastro, la vecchia label con un End
Of File (
EOF
) mediante il comando mt e quindi, da Bareos, assegnare una nuova label con il comando
label barcodes.
Ipotizziamo di voler modicare la label del nastro nello slot 1, eseguiremmo le seguenti operazioni:
 
# /usr/lib/bareos/scripts/mtx-changer /dev/sg6 load 1 /dev/st0 0
# mt -f /dev/st0 rewind
# mt -f /dev/st0 weof
# mt -f /dev/st0 rewind
# /usr/lib/bareos/scripts/mtx-changer /dev/sg6 unload 1 /dev/st0 0
 
Quindi, dalla bconsole:
 
*label barcodes pool=UNPOOL storage=UNOSTORAGE slot=1
 
Sostituire a UNPOOL il Poll al quale si vuole aggiungere il Volume e a UNOSTORAGE lo storage che
gestisce la Tape.
45

Bibliografia
[1]
Agid. Linee guida per il disaster recovery delle pubbliche amministrazioni, ai sensi del c.3, lettera
b) dell’art. 50bis del Codice dell’Amministrazione Digitale, Aggiornamento 2013. Available on line.
URL: http://www.agid.gov.it/sites/default/files/linee\_guida/linee-guida-dr.pdf.
[2]
Bareos. Bareos
®
; Backup Archiving REcovery Open Sourced Main Reference. Available on line.
URL: http://doc.bareos.org/master/html/bareos-manual-main-reference.html.
[3]
Vivek Gite. 15 Useful Linux and Unix Tape Managements Commands For Sysadmins. Available on line.
URL: https://www.cyberciti.biz/hardware/unix-linux-basic-tape-management-commands/.
[4]
IBM. IBM Spectrum Protect. Available on line. URL:
http://www-03.ibm.com/software/products/
it/spectrum-protect.
[5]
IBM. IBM TS3500 Tape Library. Available on line. URL:
http: //www - 03.ibm.com/systems/it /
storage/tape/ts3500/.
47

48
Una soluzione Open Source per un’infrastruttura di backup centralizzato:
Bareos e IBM TS3500
CNR SPR Reti e Sistemi Informativi