Porque debemos de hacer un respaldo de las bases de datos

Por: Servando Canales

 

Una gran mayoría de nuestros casos es tratar de corregir corrupción en bases de datos (Exchange, SQL Server, etc); causadas por problemas de HW, borrado de archivos por equivocación, antivirus, etc.

 

Cuando preguntamos a los clientes por el respaldo nos encontramos que :

-         el respaldo es muy viejo

-         el respaldo falla porque nunca se probó

-         no se tiene respaldo

-         los respaldos estan incompletos

-         el respaldo estaba en el mismo disco que falló

-         etc

 

Nos damos cuenta que muy pocos clientes realmente cuentan con una estrategia de respaldos efectiva.

Cuando creo que el área de tecnología (nosotros) deberíamos pensar más en los usuarios y por la empresa en la que trabajamos, que a final de cuentas son nuestros clientes.

 

Un ejemplo:

1. Problemas de integridad de información.

La base de datos se corrompió debido a una falla de HW, no se tuvo respaldo, se logro salvar el 75% de la información.

Donde queda el 25% restante?

El usuario final (area operativa) tiene que volverlo a actualizar en la base de datos, hacer que los datos verifiquen con la información que se tenga y al final no se sabe o es dificil saber si toda la información que se actualizó despues de la falla es la correcta.

Ademas de todas las horas “perdidas” tratando de recuperar la información correspondiente.

 

El comentario del ingeniero de tecnología:

“Reparamos la base de datos, o extraigamos la informacion que se pueda, el usuario operativo se encargara de hacer que los datos hagan match con el resto de la información.

 

 

Muchas veces no pensamos en la criticidad de la información. Existen bases de datos las cuales son vitales para cualquier negocio. Pero, qué pasa si no se puede recuperar la información?

-         La compañía pierde dinero

-         Malas decisiones tomadas

-         Despidos

 

Cierta perdida de información es tolerable en algunos ambientes, siempre y cuando sean controladas.

La mejor solución para todo esto es:

Respaldos, respaldos y respaldos. (recuerda hacer pruebas J).

 

La clave de esto es:

Hablen con el área operativa, creen un “Service Level Agreement (SLA)” entre ustedes y ellos.

De aquí pueden sacar:

-         Que tan importante son los datos para su negocio

-         Cuanta información es factible “perder” (desde el ultimo buen backup hasta el momento de la falla)

-         Que servicios se van a prestar y como

-         Cuánto dinero pierdo mientras el servicio esta detenido.

-         Expectativas del cliente

-         Cual es el tiempo aceptable con el servicio abajo?

-         Que tipos de respaldos se van a hacer (full, transaccional, diferencial, log shipping, mirroring, etc)

-         Con que frecuencia se deben sacar respaldos

-         Costos

-         Etc.

 

 

Adjunto alguna información útil como referencia:

Info de SLAs:

http://www.backupdirect.net/library-online-backup-sla-expectation-setting.htm

 

Asi como tambien implementar:

Service Management Functions - Problem Management

Service Management Functions - Incident Management

Service Management Functions - Service Level Management

 

Designing a Backup and Restore Strategy

Backing Up and Restoring Databases

Welcome to the SQL Server Disaster Recovery and Availability Forum