7. BC/DR mayhem@aipsi.org
Disservizio accettabile
RPO, Recovery Point Objective
the acceptable latency of data that will be recovered
RTO, Recovery Time Objective
the acceptable amount of time to restore the function
MTDL: The RPO must ensure that the Maximum
Tolerable Data Loss for each activity is not
exceeded.
MTPD: The RTO must ensure that the Maximum
Tolerable Period of Disruption for each activity is
not exceeded.
7
Thursday, 21 October, 2010
8. BC/DR mayhem@aipsi.org
Rischi
Elencare i rischi
dai quali ci si vuole proteggere
Classificarli per frequenza e gravità
guasti, perdite d’acqua, incendi, terremoti
8
Thursday, 21 October, 2010
10. BC/DR mayhem@aipsi.org
Quanto denaro investire
Definire il costo di ogni disservizio
Definire un budget da dedicare alle
contromisure per i diversi rischi
costo(incidente) > costo(contromisure) ?
10
Thursday, 21 October, 2010
11. BC/DR mayhem@aipsi.org
Cosa fare?
• Avoidance (evitare completamente)
• Reduction (mitigare)
• Sharing (transferire il rischio)
• Retention (accettare e mettere in conto)
11
Thursday, 21 October, 2010
14. BC/DR mayhem@aipsi.org
Gli elementi di una crisi
Una minaccia per l’organizzazione
Un evento imprevisto
Tempi di decisione brevissimi
14
Thursday, 21 October, 2010
18. BC/DR mayhem@aipsi.org
Seven Tiers of DR
Tier 0: No off-site data – Possibly no recovery
Tier 1: Data backup with no hot site
Tier 2: Data backup with a hot site
Tier 3: Electronic vaulting
Tier 4: Point-in-time copies
Tier 5: Transaction integrity
Tier 6: Zero or near-Zero data loss
Tier 7: Highly automated, business integrated solution
18
Thursday, 21 October, 2010
24. BC/DR mayhem@aipsi.org
Cluster / Array
Ridondare le risorse (HW/SW)
aiuta la Business Continuity
non preserva dalla perdita di dati
ma aiuta a prevenirla
24
Thursday, 21 October, 2010
26. BC/DR mayhem@aipsi.org
Replica di dati
Utilizzo di banda?
Se fosse il server a non essere disponibile?
26
Thursday, 21 October, 2010
27. BC/DR mayhem@aipsi.org
Replica di VM
Necessari banda e spazi adeguati
Basata su servizi di terze parti
27
Thursday, 21 October, 2010
28. BC/DR mayhem@aipsi.org
Replica di Storage
Ogni vendor ha la sua tecnologia
Grande resa a fronte di costi non banali
28
Thursday, 21 October, 2010
29. BC/DR mayhem@aipsi.org
Deduplication
I dati ridondanti vengono eliminati
Una sola copia di ogni dato,
utilizzo razionale degli storage
Viene mantenuto un indice completo
29
Thursday, 21 October, 2010
30. BC/DR mayhem@aipsi.org
Continuous data protection
CDP salva automaticamente le modifiche dei
dati, mantenendo diverse versioni del dato,
permettendo di ripristinare la situazione in
un particolare Point in Time (PiT).
30
Thursday, 21 October, 2010
33. BC/DR mayhem@aipsi.org
Come accedere ai dati?
Ho un sito di Disaster Recovery remoto
In caso di terremoto i miei dati saranno
ancora disponibili
Come faranno gli utenti ad accedere?
33
Thursday, 21 October, 2010
36. BC/DR mayhem@aipsi.org
Conclusioni
Un buon piano di BC/DR
può minimizzare l’impatto di un “danno”
sia in termini di tempo che di denaro
anche con investimenti “banali”
36
Thursday, 21 October, 2010
37. BC/DR mayhem@aipsi.org
Standard
ISO/IEC 27001:2005 (formerly BS 7799-2:2002)
Information Security Management System
ISO/IEC 27002:2005 (remunerated ISO17999:2005)
Information Security Management - Code of Practice
ISO/IEC 22399:2007
Guideline for incident preparedness and operational continuity
management
ISO/IEC 24762:2008
Guidelines for information and communications technology disaster
recovery services
37
Thursday, 21 October, 2010
39. Alessio L.R. Pennasilico
mayhem@aipsi.org
twitter: mayhemspp
FaceBook: alessio.pennasilico
Domande?
These slides are written by Alessio L.R. Pennasilico aka mayhem. They are subjected to Creative Commons Attribution-
ShareAlike 2.5 version; you can copy, modify or sell them. “Please” cite your source and use the same licence :)
Grazie per l’attenzione!
Thursday, 21 October, 2010