Ayuda con Estrategia de backup

Hola Morena

Log Shipping es un metodo de tener una base de
datos "lista" para cuando se cae el servidor principal,
esto cuando se carece de CLUSTER, que NO es tu caso.

Como se supone que "NUNCA" tendras una caida "total", esto
es que dejes de procesar, porque cuentas con un cluster,
entonces lo mas recomendable es hacer un BACKUP COMPLETO,
todas las mañanas y hacer un BACKUP de transacciones
cada "x" tiempo (como dices, dependera del numero de
transacciones que tengas).

¿Donde hacerlo?

El disco es mucha mas rapido que una cinta, yo lo haria en
DISCO para posteriormente, mandarlo como "permanente" a
una cinta (respaldo vitalicio, fuera del lugar donde se
enecuentra fisicamente el servidor de datos).

Saludos

Hola:
Comparto con Isais que la mejor estrategia suele ser a Disco y luego a
Tape.
Cual frecuencia? Depende de cuanto puedas perder en caso de un desastre.
En algunas empresas 15 minutos es demasiado (en un Banco), en otras 1 semana
es razonable (tienda de respuestos).
Aunque es posible usar un Log Shipping como intermediario, normalmente
no es necesario y no veo ventajas en desempeno, ya que Log Shipping mismo
hace un respaldo.
La ventaja de Log Shipping seria tener un servidor "tibio" listo para
reemplazar al cluster si este fallara (los 2). Me parece atractivo en tu
solucion si esta geograficamente alejado del cluster, para darle tolerancia
a fallas para riesgos como: Incendio, Inundacion, Terremotos, etc. Los
cuales el cluster no protege.
Saludos,

Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda

"Morena" wrote in message
news:#Y$

Tengo que diseñar e implementar la estrategia de bk para la base de datos

en

Sql Server 2000 Enterprise(SP3) que tenemos en la empresa.

El escenario que tengo es el siguiente:

Tenemos un Cluster activo-pasivo con dos nodos, en los discos se encuetra
almacenada la base de datos (en un arreglo de discos los archivos .mdf y

en

otro los .ldf). Cada servidor tiene Windows 2003 Server Enterprise.
Tenemos un dispositivos de cinta para hacer backups (PowerVault 122T, LTO,
100/200GB) el cual está conectado nada más a uno de los servidores. Solo
unos de los servidores que conforman el cluster tiene tarjeta controladora
para la cinta.

He leído los BOL y algunas recomendaciones en el Internet que hablan sobre
estrategias de backup similares a la siguiente:
1. Crear un Full Backup Domingo de 2:00 am a 3:00am
2. Crear un Backup diferencial cada noche a las 11:00pm
3. Crear Backup del Log de Transacciones cada hora (algunos recomiendan

cada

media hora).
Obviamente esto depende del número de transaccions que se generen, del
tiempo de caída que podamos soportar y de la pérdida de datos que pueda
considerarse como aceptable.

Esta estrategia de backup en principio parece ser la adecuada para

nosotros.

La duda viene sobre todo en cómo utilizar las cintas para el backup y cuál
es la solución más eficiente. He leído por ahí que es mucho más rápido y
eficiente utilizar discos que cintas(tanto para el backup como para el
recovery). Habla de cuestiones lógicas como que el acceso en tapes es
secuencial y en discos no, por ejemplo.

El asunto es que la idea de utilizar las cintas es para poder tener esos
respaldos almacenados en un banco. Se me planteó en un principio la idea

de

crear primero los backups en disco y luego hacer un "backup de los

backups"

en cinta, en un tiempo diferente al de los backups en disco. Esta parece

una

buena solución. Mi duda en este punto es ¿cuál sería la frecuencia
recomendada para hacer los backups en cinta?

También se me planteó otra cuestión y es la de utilizar el log shippin

para

pasar los datos a otro servidor y hacer los backups desde ese otro

servidor.

No entiendo bien como sería esta estrategia, pues hasta donde tengo
entendido, el servidor origen envia al destino backups de log de
transacciones, el servidor destino los baja los recobra y los almacena

para

mantener actualizada su base de datos. Es decir que estoy creando una

copia

de la misma base de datos en otra base de datos. Esta solución no me

parece

puesto que según mis lecturas se utiliza más que todo como una solución en
caso que el servidor principal se caiga, pero nosotros tenemos el clúster.
La idea de esto supongo que es utilizar el servidor destino como el

backup,

pero no logro formarme en mi cabeza cómo podría ser entonces una

estrategia

adecuada que me permita realizar backups sin que al recobrarlos pierda
demasiados datos (la perdida debe ser mínima y debería ser hasta el punto

de

falla). Tambien no me cabe en la cabeza como entraría en este modelo el

uso

de las cintas.

Mis disculpas por extenderme tanto pero quise poner lo mas amplio posible

el

escenario. Les agradesco mucho todos los aportes.

Morena

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

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 $$$).

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.
Si realizaramos los backups en cinta cada día, ¿en que consiste entonces
esta estrategia? ¿vamos a tener una infinita cantidad de cintas con backup
almacenadas fuera de nuestras intalaciones? 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.

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