[Re:] SqlRanger [MVP .NET] Ayuda con estrategia de backup!!!

Con el permiso de Jesús te contesto en linea

"Morena" escribió en el mensaje
news:%

Tal parece que podríamos aplicar la estrategia de hacer backup en otros
servidor mediante una unidad de red y posteriormente en cinta. Ya que de
esta manera se estaría "ahorrando", digamos, una licencia de Sql Server
Enterprise (que debería tener con el Log Shipping).
Aunque sé que no se estaría protegiendo en el caso que el cluster fallara
(los dos servidores). Creo que ese punto tendría que discutirlo con el

grupo

de trabajo para ver hasta donde podríamos llegar en seguridad (y en $$$).

Si esto es así, lo que pasa es que como te viene a comentar Jesús, la copia
que no se restaura, no hay constancia de haberla hecho, lo más normal es que
si que esté, pero no está de más comprobar que eso es así, al menos de vez
en cuando.
La estrategia que yo suelo usar es hacer recuperaciones programadas
periódicas en los servidores de desarrollo, con esto consigo un doble
objetivo, por una parte tengo la BBDD de desarrollo absolutamente
actualizada con la de producción, por otra parte garantizo que funcionan mis
backups.

Solo tengo otras preguntas más respecto a la estrategia a seguir para los
backups en cinta, ¿Cuál creen que sería la frecuencia conveniente de
realizar los repaldos a cinta?. Nosotros esperamos que esas cintas salgan

de

las instalaciones hacia un banco cada determinado tiempo.

Esa pregunta es más de tu estrategia, si se diera fuego a la oficina o se
inundaran los servidores y las cintas ¿cuantos datos estarías dispuesta a
perder? la respuesta a esta pregunta es la respuesta a la tuya.

Si realizaramos los backups en cinta cada día, ¿en que consiste entonces
esta estrategia?

Tienes tres tipos de backups, completos, de diferencias y del log.
Dependiendo de la cantidad de información y del tiempo que se lleve tu copia
y las cintas (o robots) de que dispongas será una cosa u otra.
Si te cabe un completo, adelante, después programa los necesarios de tu log
de transacciones para que éste no crezca y tu BBDD vaya fina. Tienes un
articulo mio en la revista dotnetmania sobre la que significan los modelos
de recuperación y que estrategias pueden ser adecuadas.

¿vamos a tener una infinita cantidad de cintas con backup

almacenadas fuera de nuestras intalaciones?

Puedes llegar a una solución de compromiso, (en función de tu respuesta a la
pregunta 2). Yo almaceno de forma definitiva una copia al més y de forma
temporal una completa de cada sábado. Puedes llevar al banco cada dia una
cinta y traerte la del mismo dia de la semana anterior, excepto la de los
domingos que queda allí durante 4, después te vás trayendo las que quieras
reaprovechar, pero asegurandote de que vas a poder volver a una situación
más o menos antigua.
o ¿solo los respados del mes?

Realmente esta parte de las cintas y cómo planear la estrategia me

confunde

un poco. Si alguien puede comentar su experiencia sobre la estrategia
seguida para los respaldos en cinta, frecuencia, reutilización de cintas,
etc.

No me extraña, el tema no es precísamente técnico, pero si entra en nuestra
responsabilidad. Lo mejor es hacer la pregunta al que le duelan los datos.
¿cuantos datos estás dispuesto a perder si . hay un incendio,inundación
o terremoto.
hay
un fallo en algún sistema que a pesar de estar en alta disponiblidad falla
(imagina que la red manda 1000 voltios y quema todos tus equipos o peor, esa
sobrecarga te la proporciona tu dispositivo de baterias (o sai) ).

algún inutil borra la tabla de clientes (esto lo puedes prevenir de
infinidad de formas)

algún hacker borra datos.

algún programador actualiza todas las facturas como si fuesen de un
cliente...
y luego, tu pon solución a cada uno de las posibles catástrofes.

Tu manual quedará más cerrado cuanto más catástrofes tengas contempladas.
Después de eso decía el maestro Fernando Guerrero, que lo más importante es
saber hacerlo de memoria. Es decir. Se han roto los discos. Bueno pues esto
se ha ensayado en el equipo 10 veces y la rutina es Pepe llama al servicio
técnico que está en menos de 4 horas con el hardware para reparar, después
Pepe instala el sistema operativo y monta el cluster (X horas). Después
Morena recupera el backup (ha ido al banco entre tanto a por la cinta del
sábado y tiene en el local las copias diferenciales hasta el viernes y los
logs de transacciones hasta que cascó la SAN). y las instrucciones para
hacer esto las ha hecho 1000 veces, por lo que no tiene que pensar, se hace
de memoria.

Esto es bueno por que cuando sucede algo así, suele haber mucha presión,
mucho directivo sin poder ver sus hojas de excel y diciendo que esto va a
costar no se cuantos miles de millones de dolares a la empresa en
oportunidades y no se que cosas más, con esa presión si no se saben hacer
las cosas de memoria lo más normal es meter la pata..


En fin, siento tanto rollo y espero que te sirva


-
Miguel Egea Gómez
Microsoft SQL-Server MVP
Webmaster de PortalSql.Com
¿Te interesa participar en las reuniones
del grupo de Usuarios de SQL-Server y .NET
Se harán en levante de España, (Alicante o Murcia)?

Agradesco nuevamente todos sus comentarios. Realmente me han dado una luz
enorme.

Morena




"SqlRanger [MVP .NET]" wrote in message
news:
> Además de lo que han dicho Isaías y Javier quería yo también añadir

algo:

>
> La técnica Log Shipping es adecuada como sistema de copia de seguridad
> además de servir como servidor de reserva en caso de fallo del servidor

de

> producción. Que tengas un cluster no quiere decir que no pueda fallar,

no

> sólo pueden fallar los nodos, también podría fallar el sistema de
> almacenamiento aunque esté protegido con sistemas RAID.
>
> Log Shipping te permitiría recuperar la base de datos al momento del
fallo.
> Imagina por ejemplo que falla el RAID donde tienes los archivos de

datos,

> pero que tienes disponible el RAID donde está el registro de
transacciones.
> Podrías hacer una copia de seguridad de la cola del log con BACKUP LOG
WITH
> NOTRUNCATE y restaurarla en el servidor de reserva con RESTORE LOG WITH
> RECOVERY, teniendo así en el servidor de reserva la base de datos
recuperada
> al momento del fallo, luego podrías poner a funcionar el servidor de
reserva
> mientras arreglas el principal. Una vez que tienes corregido el problema
de
> hardware del servidor principal. Puedes llevarte la base de datos desde

el

> de reserva al de producción, o bien mediante detach-attach o bien

mediante

> copia de seguridad completa y por último volver a hacer funcionar el log
> shipping.
>
> Log Shipping además te permite reducir el tiempo que tu sistema está sin
> funcionar. El tiempo para conmutar desde el servidor de producción al de
> reserva es bastante pequeño: copia de seguridad de la cola del log +
> restauración en el de reserva.
>
> Log Shipping también te ayuda a reducir la cantidad de pérdida de
> información. Puedes definir un intervalo de copia de seguridad del log

muy

> pequeño, de pocos minutos, con lo que lo máximo que podrías perder en el
> peor de los casos son esos minutos de trabajo. Sin Log Shipping, tener
> intervalos pequeños de copias de seguridad del log es problemático,

porque

> la restauración se hace algo más compleja y lleva más tiempo al tener

que

> restaurar muchas copias del log lo que haría que el tiempo que el

sistema

> está sin funcionar fuera mayor.
>
> De lo que puede que no te proteja Log Shipping es de pérdidas de
información
> por errores de usuario como eliminación de tablas y cosas así. Si una
tabla
> se elimina de la base de datos de producción, al restaurarse
automáticamente
> la siguiente copia de seguridad del log en el servidor de reserva, la
tabla
> tampoco estará en el servidor de reserva.
>
> Además, nada te impide combinar una estrategia de copias de seguridad
> Completa + Diferencial con Log Shipping.
>
> Por otra parte me parece muy buena idea hacer copias de seguridad a

disco

y
> luego a cinta ya que esto puede programarse metiante jobs, son rápidas y
> fiables, siempre que el disco donde se hagan esas copias esté en otro
sitio
> que el servidor de producción, mediante una carpeta compartidad de red.

Si

> las copias en disco las hacemos donde están las bases de datos, se

podrían

> perder simultáneamente las bases de datos y las copias de seguridad: un
> desastre.
>
> Otra cuestión es la verificación de las copias de seguidad. Las copias

de

> seguirdad hay que verificarlas y la única forma de asegurarse que son
> correctas es restaurarlas, normalmente en otro servidor. La instrucción
> RESTORE DATABASE WITH VERIFY_ONLY no comprueba la integridad de la

copia,

> sólo que puede ser leída. No podría ocurrir nada peor que nos veamos
> obligados a restaurar una base de datos y que la copia de seguridad
> estuviera corrompida. Log Shipping es, en este sentido, un aliado,

puesto

> que va restaurando las copias de seguridad del log según se van creando.
>
>
> Por último decirte que sea cual sea la estrategia de seguridad elegida
> deberías documentarla perfectamente y no sólo documentar también, sin
duda,
> el proceso de restauración, sino probarlo, para determinar el tiempo que
tu
> sistema va a estar caído. Sin probarlo, no podrás saber cuanto tiempo
estará
> caído el sistema y por tanto no sabrás si tu estrategia de copias de
> seguridad es adecuada.
>
>
> Saludos:
>
> Jesús López
> MVP .NET
>
>
>