COMO DISEAR UN SISTEMA DE BACKUP PARA SU COMPAA

Espero que en este momento libre, el redactar el documento implique cumplir con la meta que propone el ttulo. Gracias a todos por los comentarios de los artculos anteriores. Conceptos Bsicos de backup Un backup est sujeto a los siguiente elementos: Tipo de backup Periodicidad del backup Pool de Rotacin

Tipos de Backups Es muy probable que muchos de ustedes ya conozcan que existen tres tipos bsicos de backup que son: a) Full Backup o Total Este tipo de backup quiere decir que se har un respaldo a Total: toda la informacin seleccionada. E el tipo de backup que consume ms a Es recursos desde el punto de vista de tiempo y almacenamiento, y aunque es el ms costoso, tambin es el ms confiable porque no depende si de s mismo. sino Sin embargo, a la hora de realizar una recuperacin, es mucho ms simple porque no debe recurrir a otros backups como referencia para restaurar la informacin.
Cintas de Rotacin Histrico

Full Backup 1 Full Backup Semanal 1 Full Backup Semanal 2 Full Backup Semanal 3

Full Backup 2

Full Backup Semanal 1

Full Backup Semanal 2

Full Backup Semanal 3

Full Backup 3

A B C

2 MB 1 MB 1 MB

A B

2 MB 1 MB

Cintas de Rotacin Semanal Si la informacin al final del mes no ha variado de tamao la cinta histrica es contendr 4MB

1 MB

aunque A y C cambiaron, en un estrategia de Full Backup se hace backup a todo es decir a los 4MB

Figura No. 1 - Esq Esquema de sistema de backup con Full Backup (Corts, 2011) ,

Ing. Fabian Leonardo Corts Torres (2011)

(Pgina 1 de 14)

b) Backup Incremental: Este tipo de backup necesita un punto de referencia el referencia, cual es a travs de un backup total, para que apartir de all se pueda establecer qu informacin ha cambiado y en qu proporcin y a esa informacin hacerle proporcin, backup, a la parte del archivo que cambi. Esta estrategia de backup es ms rpida a la hora de respaldar, pero es la ms lenta en recuperacin, porque el respaldar, sistema de backup debe armar toda la trayectoria del cambio y eso i implica buscar los medios, y a nivel de procesos esto implica tiempo. Para iniciar un s backup incremental, siempre primero se debi arrancar con un backup total.

Cintas de Rotacin Histrico

Un Full Backup siempre es el punto de partida

Full Backup 1
Backup Incremental Semanal 1 Backup Incremental Semanal 2 Backup Incremental Semanal 3

Full Backup 2

Full Backup Semanal 1

Full Backup Semanal 2

Full Backup Semanal 3

Full Backup 3

A B C

2 MB 1 MB 1 MB

A B

500 KB 100 KB

50 KB

Cintas de Rotacin Semanal Si la informacin al final del mes no ha variado de tamao la cinta histrica es contendr 4MB

Sentido para el backup Cuando se hizo el full backup se tom 4 MB La siguiente semana a A se le modific 500KB de su total y a B 100 KB Entonces el backup Incremental es de 600KB que es ms rpido que hacer a 4MB En la semana 2 el backp incremental es de 50KB Sentido para la recuperacin Para lograr restaurar se requiere el Full Backup 1, Incremental Semana 1 e Incremental Semana 2 La restauracin es ms lenta y se requiere toda la cadena para poder recuperar el archivo

Figura No. 2 - Esquem de sistema de backup con Backup Incremental (Corts, 2011) ma

c) Backup Diferencial: Es un tipo de backup que al igual que el anterior, requiere : e un backup total como punto de partida y a partir de all determinar qu informacin ha cambiado y a esa informacin en su totalidad hacerle respaldo. cambiado, A diferencia del incremental, hace backup de todo el achivo que ha c cambiado y no de la parte dentro del mismo que ha cambiado. Es un proceso de backup mucho ms rpido que el full backup, ms lento que el incremental, pero a nivel de restauracin es ms rpido que el incremental y ms lento que el backup total, porque depende menos medios para construir la cadena de l, depende recuperacin. Puede ser representado como sigue:

Ing. Fabian Leonardo Corts Torres (2011)

(Pgina 2 de 14)

Cintas de Rotacin Histrico

Un Full Backup siempre es el punto de partida

Full Backup 1
Backup Diferencial Semanal 1 Backup Diferencial Semanal 2 Backup Diferencial Semanal 3

Full Backup 2
Backup Diferencial Semanal 1 Backup Diferencial Semanal 2 Backup Diferencial Semanal 3

Full Backup 3

A B C

2 MB 1 MB 1 MB

A B

2 MB 1 MB

3 MB

Cintas de Rotacin Semanal Si la informacin al final del mes no ha variado de tamao la cinta histrica es contendr 4MB

Sentido para el backup Cuando se hizo el full backup se tom 4 MB La siguiente semana a A y B fue modificado el backup total en esa modificado, semana 1 es de 3 MB, en la semana 2 A aumento a 3 MB lo dems sigui igual, por ende el backup en esa semana es de 3 MB que es el nuevo tamao de A.

Sentido para la recuperacin Para lograr restaurar se requiere el Full Backup 1, Iel diferencial del punto a restaurar, no es necesario toda la secuencia secuencia.

La restauracin es ms rpida que el incremental y no se requiere toda la cadena para poder recuperar el archivo

Figura No. 3 - Esque uema de sistema de backup con Backup Diferencial (Corts, 2011)

Periodicidad del Backup: La periodicidad establece la frecuencia con la cual se va a hacer el backup de la informacin, y tcnicamente esto nos brinda el RPO (Recovery Point objective); es decir, cuando ocurra un evento qu tanto hacia atrs nos podemos devolver, cu es el , cul rango de tiempo que se acepta y en el cual no se hace backup y por el cual se puede perder informacin, pero que es aceptado desde punto de vista organizacional es , organizacional, decir es el periodo entre un backup y el siguiente. La variabilidad de la informacin y siguiente. su criticidad determinarn la combinacin de los tipos de backups que son neces necesarios para un proceso adecuado. S embargo a este respecto es necesario mencionar, por Sin experiencia, que ante problemas presupuestales son estos condicionantes los que presupuestales, dictan los tipos de backup que se deben seguir seguir. La combinacin de perdiodici nacin perdiodicidad y tipo de backup, determinan el RPO y RTO (Recovery Time Objective), este ltimo establece el tiempo que se demorar el sist sistema en recuperar la informacin, al igual que la estrategia, es decir, si el backup debe ser de Disco a Disco (D2D Disk To Disk de Disco a Cinta (D2T Disk To Tape o de Disco a Disk), Tape) Disco a Cinta (D2D2T), de acuerdo a las velocidades de recuperacin que se esperan. Siendo la D2D la ms rpida.

Figura No. 4 - sobre el RPO y el RTO en plataformas de backup (Hill Associates, 2007) Hill Tomada de http://wiki.hill.com/wiki/index.php?title=RTO

Ing. Fabian Leonardo Corts Torres (2011)

(Pgina 3 de 14)

En la grfica anterior se puede observar que el punto de falla delimita el RPO y el RTO; delimita el RPO es qu tanta informacin est dispuesta a perder la organizacin con base en su macin estrategia de backup, y el RTO es qu tan rpido podemos recuperar la informacin ategia hasta el punto RPO segn la tecnologa adquirida. La idea es que tanto el RPO como el tanto RTO sean perodos de tiemp cortos, pero esto implica dinero. odos tiempo Dependiendo de la periodicidad del backup y de su tipo, esto determinar los pools de rotacin los cuales bsicamente se clasifican: Pool de rotacin Pool histrico

Para entender de qu se trata los pools de rotacin se tuilizar este ejemplo: La estrategia de backup consiste en realizar un backup semanal del tipo full backup y al final de cada mes se guarda la informacin que qued en la cinta:
Cintas de Rotacin Histrico

Full Backup 1

Full Backup 2 Backup Semanal 1 Backup Semanal 2 Backup Semanal 3 Backup Semanal 1 Backup Semanal 2 Backup Semanal 3

Full Backup 3

Cintas de Rotacin Semanal

Cintas de Rotacin Semanal Se utiliza la cinta de rotacin para convertirse en histrica

Figura No. 5 Entendiendo los pool de rotacin e histrico (Corts, 2011) s,

La cinta del backup semanal 1 del mes 1, vuelve a ser utilizada en la primera semana del mes 2, la cinta semanal 2 del mes 2, vuelve a ser utilizada en la semana 2 del mes 2 la y as sucesivamente. Es decir el pool de rotacin como su nombre lo ind ivamente. decir, indica, rota ms rpido las cintas que el histrico o para entender mejor, reutiliza ms rpidamente las cintas que el histrico. Para efectos de entender, cada mes consta de aproximadamente 4 semanas, de las cada cuales 3 seran las semanas del pool de rotacin y una semana sera para el histrico histrico, que sera la ltima semana del mes. De acuerdo a lo anterior tenemos: Pool de rotacin = 3 medios o cintas Pool Histrico = 12 medios o cintas (una por mes)

Ing. Fabian Leonardo Corts Torres (2011)

(Pgina 4 de 14)

Es decir que bajo el ejemplo ante anterior utilizando una cinta para el backup si ahora backup, tenemos que determinar la inversin del primer ao en medios de almacenamiento en (supongamos cintas LTO 5 en este caso entonces se hablara de 15 Cintas y si su ongamos caso), Cintas, costo es de US$85 cada una, entonces la inversin para el primer ao e de 15x85 = 85 es US$1275. Para el siguiente ao en teora solo debera comprarse las del pool de rotacin histrico, es decir 12 cintas (porque ya se tiene el pool de rotacin) Si el costo se rotacin). mantiene, implica que hay que presupuestar en el ao 2, 12x85 = US$ US$1020. No sera necesario comprar cintas de rotacin, pero en la prctica uno compra al menos 3 4 para prevenir un dao fsico en la cinta actuales, y adicional compra cuando menos, 2 ao las cintas de limpieza. primer Normalmente, siempre la inversin en medios del primer ao es la ms costosa, porque es la que determina los pools. Queda a criterio de la organizacin la rotacin del pool histrico que efectivamente tamben se puede rotar, pero seguramente s su rotacin es anual y ms lenta, con el fin de minimizar costos y evitar quedar en inventario a los tres aos con tecnologa que genera costos de espacio fsico para ser ubicados en algn lugar dentro o fuera de la organizacin. Para el ejercicio anterior, el RPO es de 1 semana bajo un esquema de estrategia de full backup, es decir que si hay un problema en la semana tres, se perdera toda la semana ckup, y se tendra que recurrir al backup de la semana dos. El RTO depende de la tecnologa elegida y la cual se tratar ms adelante adelante.

Hasta este punto se tiene: 1. Tipos de backup y su impacto en el tiempo de backup y la recuperacin (RTO). 2. Periodicidad del backup y su impacto en el en RPO. 3. Pool de rotacin y su impacto en los costos de la solucin e inversiones iniciales y anuales.

Ahora se debe profundizar ms en el tema sobre la tecnologa y el rendimiento del la proceso de backup y la restauracin, como tambin de elementos de control exigidos por las auditoras.

Comprender la informacin que se tiene en la organizacin Caractersticas de la informacin y su impacto en el backup: 1. Informacin densa y muy pequea: Cuando se realiza un backup, no es lo mismo hacer backup de 1 GB de un solo archivo, que hacer bac up backup de miles de archivos de 1KB; el rendimiento en el primer caso es superior al del segundo caso. Esto mismo se traslada a escenarios corporativos donde en un sitio se alberga miles de archivos pequeos y se puede apreciar que cuando el proceso

Ing. Fabian Leonardo Corts Torres (2011)

(Pgina 5 de 14)

2.

3.

4.

5.

de backup llega a ese punto su rendimiento se ve afectado. Es importante tener en cuenta esto en el diseo. Informacin contenida en e equipos Linux o Unix: Con el caso de linux sucede un caso muy particular, me ha ocurrido con Backup Exec, NetBackup y Arc Server, y consiste en que se debe setear a full duplex tanto en el switch como en la tarjeta de red del servidor, no es recomendable lanzar el backup dejando todo lanzar en modo auto sensing. Informacin que est siendo utilizada: Esto implica que la solucin de backup debe tener presente que cuando el proceso de backup pase por un servidor que contenga informacin que se est utilizando, se le pueda hacer backup; llmese una base de datos o archivos de oficina que en ese momento estn abiertos. Informacin que est repetida: Muchas veces las empresas acuden a repositorio de archivos y es muy comn que interactuen all, pero con el riesgo que la informacin est repetida en el mismo lugar, por ende es importante que cuando se evale una solucin de backup se haga un estudio de deduplicacin, para determinar la cantidad de informacin. Escenarios de virtualizacin: Los escenarios de virtualizacin requieren de atencin especial, porque implica que si ya se tiene virtualizada la , infraestructura, se debe tener cuidado con el datastore y que ste tenga el suficiente espacio para los snapshot que genera el software de backup. No recomiendo, por ejemplo que el backup de mquinas virtuales aplique a ejemplo, Controladores de Dominio con tecnologa Microsoft, la razn crecen la razn?, continuamente y por ende el snapshot tambin, consumiendo el espacio libre en el datastore rpidamente y generando problemas a futuro. Hace backup de Hacer mquinas virtuales es un proceso que consume tiempo.

Comprender el sistema de backup como estrategia organizacional Un sistema de backup tiene diferentes cognotaciones desde el punto de vista organizacional y bsicamente enfoca sus esfuerzos en estos dos puntos en puntos: Es un componente de respaldo de la informacin en caso de prdida de la misma. Es para la operatividad del da a da. Es un componente fundamental en el plan de recuperacin de desastres (DRP). Es un componente que determina las reglas de juego de respaldo d informacin de para los usuarios; es decir define las polticas y para qu es el sistema de backup decir, dentro de la organizacin organizacin.

NOTA: Sea cual sea el enfoque o camino a seguir, es algo que es dictaminado por la organizacin y no por rea de IT. I ea Insisto, la tecnologa contribuye a los objetivos organizaciones y no la tecnologa establece qu debe hacer la organizacin. Es un error plantear una estrategia de backup sin que pase por la aprobacin de las directivas de r la organizacin, mediante un documento breve llamado Polticas de B nte Backup, y el cual auditora interna y externa exige.

Ing. Fabian Leonardo Corts Torres (2011)

(Pgina 6 de 14)

Sistema de backup como un componente operativo del da a da Para atacar este punto es importante conocer los siguientes elementos dentro de su organizacin: 1. Tipo de informacin que se maneja dentro de la organizacin En este punto ipo organizacin: es importante clasificar la informacin que posee la organizacin; es decir, si informacin est en bases de datos, documentos de oficina, aplicaciones, etc. Es vital conocer esto porque ms adelante determinar los tipos de agentes que se adelante requieren para suplir la necesidad de backup sin generar indisponibilidad en el servicio. 2. Ubicacin de la informacin en la arquitectura de hardware: Aqu el tema a hardware: tratar consiste en identificar en qu plataformas de hardware se encuentra la plataformas informacin del punto 1. Es importante, porque desde el punto de vista de rendimiento (relacin entre Velocidad y Tiempo = Ventana de backup), es muy diferente tenerla en un servidor normal tipo torre, rack, blade conectado directamente a la red de datos, a un equipo especializado de almacenamiento tipo SAN o NAS/SAN ya sea conectado con tecnologa SAS, iSCSI o Fiber Channel tecnologa entre otros. Esto determinar el diseo de la infraestructur de backup y de infraestructura algunas buenas prcticas que en mis aos de experiencia es recomendable tener presente. 3. Cantidad de informacin Como su nombre lo indica, es la cantidad de informacin: informacin en GB o TB, a la cual se le debe realizar el backup. Este dato es muy importante, porque finalmente cuando se est evaluando la tecnologa o est estrategia, determinar la ventana de backup requerida para lograr con xito el proceso de respaldo de informacin, como costos de almacenamiento alternos ceso y contratados con terceros, los costos de los pools de rotacin e hist terceros, histrico. 4. Ventana de backup: Este trmino quiere decir el tiempo con que cuenta la backup: organizacin para desempear el proceso de backup, sin que esto implique una afectacin de sus servicios. Normalmente siempre se especifica que esto debe hacerse en horas de la noche o en la madrugada, pero en la prctica puede realizarse en cualquier momento siempre que este proceso no afecte el momento, rendimiento de los servicios y genere problemas de operatividad. Al tener claro los puntos anteriores, se proceder a armar el rompeca rompecabezas que ayudar a identificar los requerimientos para desarrollar un proyecto de backup. Armando el rompecabezas de un proyecto de backup Cuando se enfrenta a un proyecto de backup, en el que se debe determinar el software y hardware que har el procedimiento, es importante tener claro las procedimiento, caractersticas de la informacin que se tiene y que se mencionaron con anterioridad. Esto debido a que los software de backup de hoy en da lo venden en dos lneas sto comerciales: representantes a) Por capacidad: Los partners o representantes comerciales de los fabricantes de sistemas de backup como Symantec, IBM, CA, HP, cuando ofrecen sus productos preguntan si desea adquirir el software de backup con opcin por almacenamiento, es decir que el cliente establece en conjunto con un estudio,

Ing. Fabian Leonardo Corts Torres (2011)

(Pgina 7 de 14)

la capacidad de almacenamiento total requerida que el software de backup debe tener como lmite. Para lograr este estudio se debe contar con una muy organizada bitcora de backup de la cual se hablar ms adelante. Por ejemplo si el backup de la empresa es de 600GB y su crecimiento anual es de un 10%, puede pensar en adquirir una solucin de backup por almacenamiento con capacidad mxima de 1 TB. Esto quiere decir, que cada proceso de backup que el operador efectue, como mximo podr hacer 1TB, sin mebargo tiene la ventaja que puede acceder a todos los agentes que requiera, incluso a agentes que no necesita. Por eso es importante identificar bien el tipo de informacin y la cantidad de la misma. Si por alguna razn la capacidad de la informacin aumenta, entonces es necesario que se licencie un nuevo Terabyte, y tonces normalmente los fabricantes bajo esta modalidad licencian de esta forma. b) Por agentes: Esta modalidad de compra, implica que se adquiere el software de backup para el servidor y adicional de forma individual se compra los agentes servidor, ndividual compran segn el tipo de informacin a hacerle backup. No es lo mismo hacer backup a un archivo de word que hacerle backup a una base de datos Oracle o MS SQL Server, ya que para eso se requieren agentes diferentes con costos difer diferentes. Los agentes vienen en varias clasificaciones como: a. Agente para archivos abiertos. b. Agente para bases de datos Oracle. c. Agente para Bases de datos Microsoft Exchange. d. Agente para backup a mquinas virtuales. e. Agente para Bases de datos Microsoft SQL Ser Server. f. Agentes para hacer backup del Directorio Activo de Microsoft. g. Etc, etc. Lo importante aqu, es que quien sea el lder del proyecto tenga un inventario preciso del tipo de informacin a la cual le desean hacer backup, porque as mismo se determinar la cantidad de los agentes requeridos y el costo de la solucin, y de esta manera poder comparar si es mejor comprar por almacenamiento o por agentes. macenamiento Desde el punto de vista prctico es ms escalable comprar por capacidad, porque mientras no se exceda de la cuota comprada, se puede utilizar todos los agentes, desde ese punto de vista es ms escalable que la opcin por agentes. Pero hay un desperdicio implcito, porque hay agentes que muy seguramente no se requieren. Caso IBM: Para el caso de IBM su esquema de licenciamiento involucra una mezcla de de Procesadores y Nmero de mquinas virtuales que finalmente genera una unidad de medida para determinar el costo Es algo un poco complejo de ver a simple vista, as costo. s que queda a su criterio el meterse con este mecani mecanismo de licencia.

Requerimientos que debe considerar en el software de backup Cuando se est evaluando el software de backup, se debe revisar que pueda hacer las siguientes funcionalidades o exigencias:

Ing. Fabian Leonardo Corts Torres (2011)

(Pgina 8 de 14)

1. Los software de backups poseen algo llamado Catlogo, que no es ms que la metabase de datos que almacena los proceso de backups y su informacin es informacin; decir, indica qu informacin hay en un medio y de qu fecha pertenece Debe pertenece. poderse recuperar la informacin de un medio an en ausencia del catlogo, ar an es decir, sin tenerlo tenerlo. 2. El software debe estar en capacidad de poder crear Jobs o tareas de backup de forma individual donde se pueda colocar los servidores y la informacin a respaldar, como la hora y el tipo de backup a realizar. 3. Debe poder realizar inventario, etiquetado de los medios y catalogacin de los mismos en conjunto con el tapelibrary. 4. Debe poder manejar cdigos de barra en caso de ser necesario barras necesario. 5. Debe generar reportes o logs de backup donde se pueda identificar la velocidad de backup por servidor, la cantidad de informacin a la que se hizo backup y cantidad backup, caso de errores, especificar en qu servidor ocurri y dnde. 6. Debe poder encriptar el backup de ser requerido por el usuario. 7. Debe poder comprimir la informacin para mejor mejorar rendimiento en el almacenamiento. 8. Debe poder personalizar la etiquetas que se le colocan a las cintas o al medio local de almacenamiento, para distinguir fcilmente un job de otro. 9. Debe permitir lanzar una limpieza al tape drive, con la respectiva cinta de al limpieza, y debe not notificar al operador de backup cundo debe hacerse. ndo 10. Debe mandar correos de n notificacin donde se informe inicio y fin de un job y job, si es posible de sus detalles. 11. Debe poderse instalar los agentes de distintas formas entre ellas, mandar de forma remota la instalacin d los agentes. de

Bsicamente un software de backup se resume un schedule, es una relacin entre:

Servidores

Hora de Inicio Compresin?

Da de Backup

Debe hacer deduplicacin?

SCHEDULE

Tipo de Backup

escribe? Sobre-escribe Localizacin de la cinta en el tape library

Figura No. 6 Componentes bsicos en un schedule de un backup (Corts, 2011)

Ing. Fabian Leonardo Corts Torres (2011)

(Pgina 9 de 14)

Rendimientos de las tecnologas Para la seleccin del sistema de backup a nivel del hardware, los escenarios de hoy en backup da utilizan estrategias de backup basadas en D2D, sin embargo si se hace esto a travs as de la red, el mejor desempeo sera enlace 10GibitEthernet, pero en la prctica eso es muy costoso y normalmente todo s trabaja a GigabitEthernet, as que existen dos se , conceptos que no deben ser confundidos: SAN como red aislada para el backup. SAN como medio de almacenamiento.

La SAN como red aislada permite tener una red (si se puede decir as si as), complemetamente independi independiente de la red de datos y servicios de la organizacin, lo cual permite un mejor rendimiento y la posibilidad de utilizar una gama de tecnologa tecnologas de conectividad. La SAN de almacenamiento es el equipo o el hardware que solo contiene discos para almacenar i informacin y puede crecer en Terabytes o Petabytes Petabytes, y es donde se aloja la informacin. Por ejemplo una Dell MD3000i es un claro ejemplo de una SAN de almacenamiento. Teniendo claro lo anterior, un sistema de backup convencional requiere normalmente los siguientes componentes bajo el esquema tradicional: guientes 1. Servidor de backup. 2. SAN de backup para albergar la informacin y hacer backup D2D. 3. SAN a nivel de red. 4. Tape Library Servidor de backup: Es el componente que contiene el software de backup del fabricante elegido. Su funcin no es almacenar informacin, a los sumo solo debe gido. preocuparse por el catlogo del software de backup. Debe ser un equipo con buen procesador (Quad-Core en adelante) y buena memoria RAM (12 GB en adelante) En Core adelante). las diferentes formas de conectar el servidor al tape library se puede hacer por Fiber conectar Channel que brinda una tasa estandar de 8Gbps, puede ser conectado por iSCSI que brinda en promedio 1Gbps, o puede ser por SAS que da hasta 6Gbps. Por ejemplo, en la grfica que sigue se puede ver un tipo de topologa:

SAN

C o n e x i n S A S , F ib e r C h a n n e l o iS C S I

S e r v id o r d e B a c k u p

T a p e L ib r a r y

S e rv id o r e s a R e s p a ld a r

Figura No. 7 Toploga Bsica para Backup (Corts, 2011) igura

Ing. Fabian Leonardo Corts Torres (2011)

(Pgina 10 de 14)

En este diseo el problema es que si el backup se hace a travs de la red de datos normal, lo mximo que se puede obtener es la velocidad de la misma generando un misma, cuello de botella independiente de la manera en la que cual conecte la SAN y el conecten TapeLibrary al servidor. Si definitivamente el mejor escenario es el anterior, entonces se debe tratar de comprar el servidor con el nmero de tarjetas de red necesario, para ubica ubicarlas en las distintas redes a las cuales debe llegar para hacer backup. La idea finalmente, es que el tape library pueda aprovechar la velocidad de las tecnologa actuales como FiberChannel y SAS que son de mejor desempeo que iSCSI SAS, iSCSI.
R ED L A N D A T O S

S e rvid ore s a R e s pa lda r

C o ne x in Fib er C ha n ne l o iSC S I

S e rvid or d e B ac ku p
R ED SA N

C on e xi n S A S , F ib e r C ha n ne l o iS C S I C o ne x in Fib er C ha n ne l o iSC S I

T a pe Lib rary

SA N

Figura No. 8 Toploga Mejorada para Backup (Corts, 2011)

El propsito es evitar cuellos de botella, pero esto implica costos de inversin, as que todo depende del presupuesto y el alcance del proyecto. Se cual sea el caso, l ideal de lo la estrategia de backup es q el backup se enve a disco primero, y desde all se pase a que cinta. Esto ltimo puede hacerse en cualquier momento del da ya que no afectara las sto aplicaciones y la red.

TapeLibrary: Algunos lo llaman el robot de backup, para referirse al componente que backup, enva la informacin de disco a cinta, y generalmente se presentan: StandAlone = Equipo con un tape drive TapeLibrary = Equipo con uno o ms tapedrives y con slots para albergar ms de una cinta.

Un tapedrive es donde se introduce la cinta para su lectura o escritura, segn sea el e caso. Vienen en diferentes marcas como Exabyte, Quantum, IBM, etc, de acuerdo a la ienen tecnologa de Tape se utiliza las cintas con sus respectivas capacidades de utilizan almacenamiento, las cuales son seleccionadas de acuerdo al tamao de l informacin , la a la cual se desea hacer backup. El tape debe poder conectarse ya sea por backup. FiberChannel, iSCSI o SAS, y poder ser administrado a travs de un panel frontal o va red (debe tener una interface va red) red).

Ing. Fabian Leonardo Corts Torres (2011)

(Pgina 11 de 14)

Cuando se adquiere la solucin de backup, debe asegurarse de que existe plena compatibilidad con el tape y debe poderse administrar a travs de l. El tape library permite alojar ms de una cinta y programar a consideracin los procesos de backup sin recurrir a c cambios diarios de cinta, hacindolo ms automtico. Un tape library puede tener ms de un tapedrive o slot para leer y escribir la cinta, ayudando al paralelismo en proceso de backup y por ende a un mejor desempeo en la ventana de backup. La tecnologa del tape library determina hasta qu punto se qu pueden leer tecnologas de medios antecesoras y la velocidad de lectura y escritura a cinta. Asi que cuando piense en elegir el tape library mire: Cuntos tape drive requiere. Cuntos slots para albergar cintas necesita. Con qu tecnologa lo va a conectar (FC, iSCSI, SAS). Posibilidad de administrar va red. Qu tecnologa antecesoras soporta si es necesario. Tasa de lectura y escritura en la cinta. Qu tipo de garanta tiene el producto. El tipo de soporte.

SAN: Unidad de almacenamiento, donde el backup reside para finalmente ser pasado a cinta. Dado que la finalidad es almacenamiento de informacin no requiere discos de informacin, alto desempeo, por lo que se puede hablar de discos SATA de 10KRPM o de discos SATA de 7.2 KRPM, la cuestin all es disminuir costos y no utilizar disco de alto disminuir desempeo para una tarea de solo almacenamiento. La SAN se dimensiona segn los requerimientos o los paquetes mnimos que venden los fabricantes, como EMC. Debe poderse conectar al tapelibrary directamente por SAS, iSCSI o FC. La recomendacin es que cuando se adquiera una, se puede tener la CSI , flexibilidad en almacenamiento sin perjudicar la disponibilidad del servicio. xibilidad A este respecto, fabricantes como DELL, EMC2, IBM, HP, tienen soluciones combinadas abricantes que integran SAN y NAS al tiempo, sin embargo para este caso se recomienda una solucin en SAN nativa con LUNs que no superen los 10TB, por cuestiones de recuperabilidad o restauracin de la in egridad de la LUN en caso de un dao. integridad

Control del proceso de backup Auditora (ente supervisor de las buenas prcticas y controles) hace las siguientes ente recomendaciones en el control del proceso de backup. La intencin es asegurar la recuperabilidad de la informacin en el momento en el cual se necesite, bien sea por operacin diaria o por un DRP, lo que implica que se deban tener en cuenta los tener siguientes elementos que garanticen que se puede hacer hacer:

Ing. Fabian Leonardo Corts Torres (2011)

(Pgina 12 de 14)

1. Bitcora de backups: Es un archivo que debe contener: a. Hora inicio y hora fin del backup. b. Tipo de backups utilizado en el da a da. c. Logs del backups y su ubicacin en otro servidor, en la bitcora debe haber los links apuntando a ese servidor. ndo d. Velocidad de backup por servidor. e. Cantidad de informacin grabada por servidor. f. Errores encontrados por servidor. contrados g. Total de cantidad de informacin de da. del h. Responsable de la revsin de los logs. i. Pruebas de restauracin y logs donde quede constancia de la misma donde misma, indicando si fue o no exitosa. 2. Custodia de medios: Contrato con un tercero que debe tener: a. El cliente debe acordar y tener el contrato actualizado de la prestacin de actualizado servicio. b. Debe quedar claro que el proveedor del servicio NO DEBE estar en capacida de extraer la informacin de los medios de almacenamiento que se le entreguen en custodia. c. Se debe definir la modalidad de custodia, si es por contenedor (un tamao contenedor de caja y lo que se pueda meter all, y sellada respectivamente) o si es por almacenamiento individual (cobran de forma individual cada medio). d. Debe estar claro los tiempos de respuesta y sus costos, incluso si la organizacin est por fuera del permetro geogrfico establecido como fuera estandar dentro de la cobertura del servicio. e. Debe existir una bitcora donde se estipule los simulacros donde se midieron los tiempos de respuesta contratados. f. El proveedor debe tener en custodia los medios en un sitio acordes a los estndaresinternacionales. g. El cliente debe establecer el personal y el lugar autorizado para la entrega y recepcin de medios. h. Se debe definir la periodicidad en la entrega de medios para con el proveedor.

La bitcora es revisada p el auditor en su momento, pero para e operador de da por el backup, es una herramienta que le ayuda a dimensionar el crecimiento de la informacin y los requerimientos a futuro. Normalmente la bitcora se hace en un archivo de excel y debe soportar las decisiones y nuevos rumbos de la plataforma. decisiones La custodia de ciertos medios con un proveedor externo con ubicacin geogrfica diferente al de la organizacin, permite garantizar hasta cierto punto el Plan de Recuperacin de Desastres (DRP). Es algo que las auditoras normalmente recomienda auditoras y revisan durante el proceso, como de los SLA (Service Level Agreement) establecidos dentro del contrato.

Ing. Fabian Leonardo Corts Torres (2011)

(Pgina 13 de 14)

Conclusiones El disear una plataforma de backup no es simplemente un cambio tecnolgico, es una proceso estratgico para la organizacin y establecido o condicionado por la organizacin, y no por el rea de TI. Todo debe estar contemplado en un documento formal que define las reglas y el fin del sistema y al cual se le llama Pol Polticas de Backup Organizacional, de acuerdo a ellas el sistema soporta las decisiones tom o madas. Tambin es importante no tener Todos los huevos en la misma canasta, es decir que los medios de almacenamiento no deben estar fsicamente y geogrficamente en el mismo lugar donde est localizada la organizacin, porque auditora revisa esta parte tanto la Auditora Interna como la Auditora Externa. La administracin de una plataforma de backup puede ser tan comple que requiere eja, de un recurso humano de edicado a su supervisin y especializado en el tema, es una tarea del da a da y debe se la segunda en efectuarse durante el mism er mo.

Cmo disear un sistema de backup para su compaa by Fabian Corts is licensed under a Creative Commons Reconocimiento Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported License.

Ing. Fabian Leonardo Corts Torres (2011)

(Pgina 14 de 14)