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]" <sqlranger.mvp@mvps.org> wrote in message
news:eXBlSfqhEHA.3016@tk2msftngp13.phx.gbl...
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
Leer las respuestas