Il documento discute l'importanza del backup dei dati, in particolare per il sistema Domino, evidenziando le differenze tra il backup full e incrementale e i scenari ideal per la gestione dei dati. Vengono presentati obiettivi chiari per i backup, come il recupero di database e email, con esempi pratici tratti da diverse aziende. Inoltre, il documento fornisce informazioni sui concetti chiave di Tivoli Storage Manager e suggerisce best practices per la pianificazione e l'implementazione di backup efficaci.

1. Tivoli Storage Manager for
Domino
Michelangelo Gambacorta

2. Agenda 1/2
•
•
•
•
•
Perché parlare di backup?
Introduzione - casi tipo
Obiettivi del backup
Situazione ideale
Backup Full e Incrementale

3. Agenda 2/2
•
•
•
•
•
Confronto statistiche - vantaggi
Concetti TSM
Schedulazione backup
Installazione client
DAOS
3

4. Perché parlare di backup?
•Il backup è quella cosa che si “deve” fare
ma che non piace a nessuno ... e quando si
parla di backup di posta si sentono storie
che appartengono al genere “orror” ...
•“Non ho tempo, non c’è spazio, ho deciso
che tengo solo 15gg, tengo solo 7gg + 4
settimanali + 1 trim + 1 sem ... e comunque
non servono a nulla ... “
4

5. Introduzione - casi tipo
•Esempi e dati si riferiscono a tre realtà
tipo :
•A1: azienda con 70 utenti Domino, nel
settore dei servizi (SPA).
•A2: azienda con 110 utenti Domino,
settore alimentare.
•A3: azienda piccola di 35 utenti, servizi
(PR, quindi lavoro basato su mail)
5

6. Obiettivi del backup 1/2
•Cosa dovrebbe fare
•permettere il recupero del database e/o di
email, cartelle cancellate.
•Cosa non tratteremo
•l’archiviazione nel senso di copia storica
•Disaster Recovery
•Nota: nel caso in cui ci sia un cluster geografico, il DR
ha bisogno di un backup minimo.

7. Obiettivi del backup 2/2
•La richiesta più frequente è il recupero di
cartelle “misteriosamente scomparse”. Si è
vero i dati ci sono ancora ma ci potrebbero
volere giorni per ricomporla. E sulle cartelle
si basano certi flussi di lavoro.
•Scenario 1: backup 3 mesi
•Scenario 2: backup 6 mesi
•Scenario 3: backup 1 anno
7

8. Situazione ideale
•La situazione ideale è questa: si imposta il
backup, e senza intervento alcuno, ci si
scorda di doverlo gestire.
•Prerequisiti: cluster geografico e server in replica
geograficamente distanti in modo da essere in piedi in caso
di disastro. Server di backup presso uno dei componenti
del cluster.
8

9. Backup full vs incrementale
•Backup full
•richiede più spazio (costi alti di gestione)
•semplice da gestire
•non richiede transaction logs (minor costo)
•Il management lo preferisce (per rapidità di restore?)
•Backup incrementale
•molto meno spazio
•miglior flessibilità nei restore (PIT)
•richiede TL di tipo archive (vanno monitorati)
•dischi dedicati.
•Possibile ridurre i BF
9

10. Introduzione - casi tipo
utenti
posta nsf +
DAOS
(GB)
T. Log*
(GB/gg)
T. Log
(MB/gg user)
A1
(Servizi SPA)
70
19+16
=35
0,38
5,5
A2
(Alimentare)
110
85+121
=206
1,15
10
A3
(PR)
35
16+47
=61
1,13
33
* Database.RM.SinceStartup.M.Logged / Server.ElapsedTime
10

11. Confronto statistiche 1
•Scenario 1: ultimi 3 mesi
Occupazione
GB
Incrementale*
Full
4 Full + 1,5*DAOS + 120TL
90 Full + 90*DAOS
A1
(Servizi SPA)
145,6
3.150
A2
(Alimentare)
659,5
18.540
A3
(PR)
270,1
5.670
* Supponendo che utenti tengono in linea 6 mesi di posta.
4 Full in quanto faccio 1 Full / mese*3mesi + 1 mese (di attesa)
11

12. Confronto statistiche 2
•Scenario 2: ultimi 6 mesi
Occupazione
GB
Incrementale*
Full
4 Full + 2*DAOS + 230TL
180 Full + 180*DAOS
A1
(Servizi SPA)
195,4
6.300
A2
(Alimentare)
846,5
37.080
A3
(PR)
417,9
11.340
* Supponendo che utenti tengono in linea 6 mesi di posta.
4 Full in quanto faccio 1 Full ogni 2 mesi + 1 Full (di attesa 2 mesi)
12

13. Confronto statistiche 3
•Scenario 3: 1 anno
Occupazione
GB
Incrementale*
Full (6+6)
7 Full + 3*DAOS + 420TL
186 Full + 186*DAOS
A1
(Servizi SPA)
340,6
6.510
A2
(Alimentare)
1.441
38.316
A3
(PR)
727,6
11.718
13

14. Confronto statistiche 4
•In conclusione, l’occupazione sul server di
backup non supera valori che non siano
gestibili con dischi fissi (per incrementali).
Nel caso di cluster geografico (“DR ready”)
quindi si può valutare la possibilità di non
usare nastri e tenere tutto su dischi
(occupazione intorno a 2TB).
14

15. Confronto statistiche 4
• Considerazioni per valutare frequenza dei backup full
• almeno 2 nel periodo necessari
• se backup su dischi, velocità di restore sono elevate,
almeno 30MB/s = 1,8GB/min
• si stabilisce tempo max attesa per restore, si calcola
tempo tra 2 Full:
p.e.: attesa max 20min, 1,2GB di TL/gg
in 20 min restore di 1,8GB x 20 = 36GB
se produco 1,2GB di TL /gg, 36/1,2=30gg
Quindi facendo 1 Full al mese, una restore non richiede
più di 20min (più il tempo di restore del nsf dell’ordine di
qualche min)
15

16. Concetti TSM 1
•
•
•
•
•
•
Active file version
Inactive file version
retention
Node
Management class binding / rebinding
TSM for Domino
16

17. Concetti TSM 2
•Active file version
•E’ la copia più recente di un file che è presente sul TSM.
•Inactive file version
•Le versioni precedenti di un file presenti sul TSM.
•Se il file originale viene cancellato, diventano tutte inactive.
17

18. Concetti TSM 3
•Retention
•Si intende il mantenere una copia inactive
di un file nello storage.
•Si possono specificare sia il numero di versioni da tenere
che il numero di giorni minimo per cui vanno tenute
(importante) prima di essere cancellate (expired).
•Si devono stabilire periodi di retention per NSF , TL e
DAOS files leggermente maggiori del periodo di backup
18

19. Concetti TSM 4
•Management class
•racchiude i parametri di retention e si
usano per associare i file a seconda del tipo
con diversi periodi di retention.
•Per esempio, di un NSF mi interessano
varie versioni, da di un file di TL (*.txn) solo
una.
19

20. Concetti TSM 5
•NSF Management class
•Esempi: scenario 1 (3 mesi)
Per file attivi (db
esistenti)
versioni
retention x
inactive (gg)
Per file (nsf)
cancellati
4
1
120*
* vogliamo almeno 3 mesi, non al più 3 mesi
60
(decisione non tecnica)
20

21. Concetti TSM 6
•NSF Management class
•Esempi: scenario 2 (6 mesi*)
Per file attivi (db
esistenti)
versioni
retention x
inactive (gg)
* full ogni due mesi
Per file (nsf)
cancellati
4
1
240
60
(decisione non tecnica)
21

22. Concetti TSM 7
•TL Management class
•Esempi
Per file attivi (TL in
uso)
versioni
retention x
inactive (gg)
Per file (TL)
cancellati
1
1
1
periodo backup
(3+1mesi)
22

23. Concetti TSM 8
•DAOS Management class
•Esempi: scenario 1 (3 mesi)
Per file attivi
(esistenti)
Per file cancellati
(pruned)
versioni
N/A (1)
1
retention x
inactive (gg)
N/A (1)
60
23

24. Concetti TSM 9
•DAOS Management class
•Esempi: scenario 2 (6 mesi)
Per file attivi
(esistenti)
Per file cancellati
(pruned)
versioni
N/A (1)
1
retention x
inactive (gg)
N/A (1)
150
24

25. Concetti TSM 10
•TSM for Domino
•Tipi di backup:
•Selective (Full backup degli nsf)
•Incremental (DBIID cambiati)
•Archive log (Transaction log)
•
25

26. Concetti TSM 11
•TSM for Domino
•Selective
•si tratta di un backup incondizionato di tutto l’NSF
•da fare secondo la frequenza pianificata (1 ogni mese, 1
ogni 2mesi)
vedi slide per calcolo in base al tempo di restore
•Nota: dopo i Selective si consiglia di fare un inactivate
logs. I file di TL vengono messi in stato inactive quando tutti
gli nsf a cui si riferiscono sono inactive.
26

27. Concetti TSM 12
•TSM for Domino
•Incremental
•Si tratta di un backup di quei database per i
quali è cambiato il DBIID e non ancora c’è
una copia in TSM
•da fare 1 al giorno
•fin tanto non lo si fà, le modifiche sui TL
non sono utilizzabili per restore
27

28. Concetti TSM 13
•TSM for Domino
•Archive log
•Si tratta di un comando per fare backup dei
transaction log.
• dopo backup dei file dei log (*.txn) i file txn
vengono cancellati dal disco, ma le versioni
sul TSM non diventano inactive
•da fare 1 al giorno (almeno)
28

29. Concetti TSM 14
•TSM for Domino
•Varie ed eventuali
•TL - Archive
•DBIID - compact (-B -S 10)
•Restore con stesso replica id
29

30. Schedulazione backup
• Di norma la si fa con documenti Program
oppure con crontab
• Bisogna fare backup di DAOS con il client
standard Backup and Archive Client di
Tivoli Storage Manager
30

31. DAOS
• all’interno del periodo di purge non ci sono
problemi
• oltre il periodo di purge, potrebbero esserci
dei file di DAOS che mancano.
Si usa il comando
tell daosmgr listnlo -o missing.txt MISSING
restoreddatabasename.nsf
e poi si usa il comando
dsmc restore -filelist=missing.txt -inact
per fare il restore dei file daos
31

32. Installazione del client
•Cosa si installa
•per AIX,LinuxZ Win32, Win64 :
TSM for Mail v6.3.1
supporto per 8.0, 8.5, 9.0
•per Linux x86, x86_64, Solaris, zOS:
TSM for Mail v5.5.3
supporto per 7.0, 8.0, 8.5.x
•NOTA: manca supporto x Domino 9 su
32
Linux x86/x86_64

33. bibliografia e links
•
redbook sg244877 Tivoli Storage Management Concepts
•
TSM for Mail System requirements
http://www-01.ibm.com/support/docview.wss?uid=swg21219345
•
TSM V6.3 Information Center - documentation
http://pic.dhe.ibm.com/infocenter/tsminfo/v6r3/index.jsp
•
TSM V5.5 Information Center - documentation
http://publib.boulder.ibm.com/infocenter/tivihelp/v1r1/index.jsp
•
DAOS Backup and Restore
http://www-10.lotus.com/ldd/dominowiki.nsf/dx/daos-backup-and-restore
33

34. •Grazie per
l’attenzione :-)
• I miei riferimenti:
• Michelangelo Gambacorta
• mgambacorta@amiura.com
• Tel: 02 56814077

35. Grazie agli sponsor per aver reso
possibile i Dominopoint Days 2013!
Main Sponsor
Vad sponsor
Platinum sponsor
Gold sponsor