Porque debemos de hacer un respaldo de las bases de datos



 


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

Comments (0)