Backup y sp_detach_db

Sí, sí Maxi, ... si yo estoy contigo también! De hecho, si relees el post
original, en él digo:

"Yo creo que no es la mejor forma de hacerlo pero no sé precisar qué
posibles
problemas puedan surgir. Pienso en cómo quedaran los logins, usuarios,
jobs,.."

Lo que pasa es que me gustaría encontrar argumentos palpables para poder
defender que ésta es la peor opción para hacer un backup.

Hasta el momento, las que ha aportado Alejandro no son suficientes razones
de peso para que finalmente se decida este método como "el método oficial de
backups".

Yo intento buscar argumentaciones para refutar esta teoría pero ... no las
encuentro. Por eso os pido ayuda y os agradezco el esfuerzo que destináis.

Un saludo


"Maxi" escribió en el mensaje
news:%

Luis, con el permiso de Ale. Cuando sacas a usuarios para hacer el backup
estas perdiendo disponibilidad de tu servidor, ademas, como haces para

sacar

los usuarios y asegurarte que nadie va entrar. Es mas yo ni le veo sentido
hacer un detach, porque no dejar al motor trabajar como el lo sabe hacer
bien y no correr riesgos?


Salu2
Maxi [MVP SQL SERVER]
www.sqlgurus.org


"Luis Dominguez" escribió en el mensaje
news:%
> Ante todo, gracias por responder. Comento los puntos que has aportado:
>
>> 1 - Que pasa si existen usuarios conectados a la db en el momento de
>> quere
>> hacer el detach o usuarios que desean conectarse en ese momento?.
>
> Esto se da por hecho. Todo el mundo debe estar fuera. Eso no es difícil

de

> conseguir puesto que, por la naturaleza del uso de la base de datos, se
> hace
> en un momento muy específico.
>
>> 2 - Que pasaria si a las 3:00 pm se produce un error en la db y deseas
>> restaurar la db hasta un punto especifico?.
>
> Estoy de acuerdo contigo. :)
>
>> 3 - Que pasaria si esa copia se daña?
>
> Igualmente se pueden dañar los backups, ¿no es cierto?
>
>> 4 - Como piensas reciclar el log de transacciones para que este no

crezca

>> indefinidamente?
>
> El administrador de sistema se encarga de ir truncando el log a medida

que

> va creciendo.
>
> ¿Hay alguna razón más por la cual no deba utilizar este método?
>
>
> Gracias.
>
>
>
> "Alejandro Mesa" escribió en

el

> mensaje news:
>> Luis Dominguez,
>>
>> > Yo creo que no es la mejor forma de hacerlo pero no sé precisar qué
> posibles
>> > problemas puedan surgir
>>
>> 1 - Que pasa si existen usuarios conectados a la db en el momento de
>> quere
>> hacer el detach o usuarios que desean conectarse en ese momento?.
>>
>> 2 - Que pasaria si a las 3:00 pm se produce un error en la db y deseas
>> restaurar la db hasta un punto especifico?.
>>
>> 3 - Que pasaria si esa copia se daña?
>>
>> 4 - Como piensas reciclar el log de transacciones para que este no

crezca

>> indefinidamente?
>>
>>
>> La manera de hacer backups de la db en T-SQL es usando el comando

"backup

>> database" y "backup log". De esta forma evitarias los problemas
> referenciados
>> en todas las preguntas anteriores.
>>
>>
>> AMB
>>
>>
>> "Luis Dominguez" wrote:
>>
>> > Hola a todos,
>> >
>> > Se quiere hacer un backup fiable y para ello se opera de la manera
>> > siguiente:
>> >
>> > 1. Se hace un sp_detach_db de la base de datos.
>> > 2. Se copian los ficheros .mdf y .ldf en un dispositivo externo.
>> > 3. Se vuelve a hacer un sp_attach_db de la base de datos.
>> >
>> > Yo creo que no es la mejor forma de hacerlo pero no sé precisar qué
> posibles
>> > problemas puedan surgir. Pienso en cómo quedaran los logins,

usuarios,

> jobs,
>> > .
>> >
>> > Se aceptan comentarios.
>> >
>> > Gracias y un saludo,
>> >
>> >
>> >
>> >
>
>

Hola, creo que tenes suficientes argumentos, y el mas importante es la
perdia de disponibilidad del motor


Salu2
Maxi [MVP SQL SERVER]
www.sqlgurus.org


"Luis Dominguez" escribió en el mensaje
news:

Sí, sí Maxi, ... si yo estoy contigo también! De hecho, si relees el post
original, en él digo:

"Yo creo que no es la mejor forma de hacerlo pero no sé precisar qué
posibles
problemas puedan surgir. Pienso en cómo quedaran los logins, usuarios,
jobs,.."

Lo que pasa es que me gustaría encontrar argumentos palpables para poder
defender que ésta es la peor opción para hacer un backup.

Hasta el momento, las que ha aportado Alejandro no son suficientes razones
de peso para que finalmente se decida este método como "el método oficial
de
backups".

Yo intento buscar argumentaciones para refutar esta teoría pero ... no las
encuentro. Por eso os pido ayuda y os agradezco el esfuerzo que destináis.

Un saludo


"Maxi" escribió en el mensaje
news:%

Luis, con el permiso de Ale. Cuando sacas a usuarios para hacer el backup
estas perdiendo disponibilidad de tu servidor, ademas, como haces para

sacar

los usuarios y asegurarte que nadie va entrar. Es mas yo ni le veo
sentido
hacer un detach, porque no dejar al motor trabajar como el lo sabe hacer
bien y no correr riesgos?


Salu2
Maxi [MVP SQL SERVER]
www.sqlgurus.org


"Luis Dominguez" escribió en el mensaje
news:%
> Ante todo, gracias por responder. Comento los puntos que has aportado:
>
>> 1 - Que pasa si existen usuarios conectados a la db en el momento de
>> quere
>> hacer el detach o usuarios que desean conectarse en ese momento?.
>
> Esto se da por hecho. Todo el mundo debe estar fuera. Eso no es difícil

de

> conseguir puesto que, por la naturaleza del uso de la base de datos, se
> hace
> en un momento muy específico.
>
>> 2 - Que pasaria si a las 3:00 pm se produce un error en la db y deseas
>> restaurar la db hasta un punto especifico?.
>
> Estoy de acuerdo contigo. :)
>
>> 3 - Que pasaria si esa copia se daña?
>
> Igualmente se pueden dañar los backups, ¿no es cierto?
>
>> 4 - Como piensas reciclar el log de transacciones para que este no

crezca

>> indefinidamente?
>
> El administrador de sistema se encarga de ir truncando el log a medida

que

> va creciendo.
>
> ¿Hay alguna razón más por la cual no deba utilizar este método?
>
>
> Gracias.
>
>
>
> "Alejandro Mesa" escribió en

el

> mensaje news:
>> Luis Dominguez,
>>
>> > Yo creo que no es la mejor forma de hacerlo pero no sé precisar qué
> posibles
>> > problemas puedan surgir
>>
>> 1 - Que pasa si existen usuarios conectados a la db en el momento de
>> quere
>> hacer el detach o usuarios que desean conectarse en ese momento?.
>>
>> 2 - Que pasaria si a las 3:00 pm se produce un error en la db y deseas
>> restaurar la db hasta un punto especifico?.
>>
>> 3 - Que pasaria si esa copia se daña?
>>
>> 4 - Como piensas reciclar el log de transacciones para que este no

crezca

>> indefinidamente?
>>
>>
>> La manera de hacer backups de la db en T-SQL es usando el comando

"backup

>> database" y "backup log". De esta forma evitarias los problemas
> referenciados
>> en todas las preguntas anteriores.
>>
>>
>> AMB
>>
>>
>> "Luis Dominguez" wrote:
>>
>> > Hola a todos,
>> >
>> > Se quiere hacer un backup fiable y para ello se opera de la manera
>> > siguiente:
>> >
>> > 1. Se hace un sp_detach_db de la base de datos.
>> > 2. Se copian los ficheros .mdf y .ldf en un dispositivo externo.
>> > 3. Se vuelve a hacer un sp_attach_db de la base de datos.
>> >
>> > Yo creo que no es la mejor forma de hacerlo pero no sé precisar qué
> posibles
>> > problemas puedan surgir. Pienso en cómo quedaran los logins,

usuarios,

> jobs,
>> > .
>> >
>> > Se aceptan comentarios.
>> >
>> > Gracias y un saludo,
>> >
>> >
>> >
>> >
>
>

Luis Dominguez,

> 3 - Que pasaria si esa copia se daña?

Igualmente se pueden dañar los backups, ¿no es cierto?

Claro que es cierto, mi punto es que puedes mantener backups del log de
transacciones y backups full de la db. Si algun backup full se daña, puedes
todavia restaurar los backup del log de transacciones. Como si tuviesemos dos
set.

> 4 - Como piensas reciclar el log de transacciones para que este no crezca
> indefinidamente?

El administrador de sistema se encarga de ir truncando el log a medida que
va creciendo.

Como lo va truncando?

Si usamos modelos de recuperacion bulk-logged o full, el log de
transacciones se recicla a medida que vamos haciendo backups de el. Esto
ayuda a que el log no crezca indefinidamente. No es necesario encojer (que no
es lo mismo que truncar)el log constantemente, pues este tiene que crecer en
cierto punto y esto toma tiempo y recursos si SQL Server lo incrementa
durante un periodo pico de nuestro sistema.


AMB

"Luis Dominguez" wrote:

Ante todo, gracias por responder. Comento los puntos que has aportado:

> 1 - Que pasa si existen usuarios conectados a la db en el momento de quere
> hacer el detach o usuarios que desean conectarse en ese momento?.

Esto se da por hecho. Todo el mundo debe estar fuera. Eso no es difícil de
conseguir puesto que, por la naturaleza del uso de la base de datos, se hace
en un momento muy específico.

> 2 - Que pasaria si a las 3:00 pm se produce un error en la db y deseas
> restaurar la db hasta un punto especifico?.

Estoy de acuerdo contigo. :)

> 3 - Que pasaria si esa copia se daña?

Igualmente se pueden dañar los backups, ¿no es cierto?

> 4 - Como piensas reciclar el log de transacciones para que este no crezca
> indefinidamente?

El administrador de sistema se encarga de ir truncando el log a medida que
va creciendo.

¿Hay alguna razón más por la cual no deba utilizar este método?


Gracias.



"Alejandro Mesa" escribió en el
mensaje news:
> Luis Dominguez,
>
> > Yo creo que no es la mejor forma de hacerlo pero no sé precisar qué
posibles
> > problemas puedan surgir
>
> 1 - Que pasa si existen usuarios conectados a la db en el momento de quere
> hacer el detach o usuarios que desean conectarse en ese momento?.
>
> 2 - Que pasaria si a las 3:00 pm se produce un error en la db y deseas
> restaurar la db hasta un punto especifico?.
>
> 3 - Que pasaria si esa copia se daña?
>
> 4 - Como piensas reciclar el log de transacciones para que este no crezca
> indefinidamente?
>
>
> La manera de hacer backups de la db en T-SQL es usando el comando "backup
> database" y "backup log". De esta forma evitarias los problemas
referenciados
> en todas las preguntas anteriores.
>
>
> AMB
>
>
> "Luis Dominguez" wrote:
>
> > Hola a todos,
> >
> > Se quiere hacer un backup fiable y para ello se opera de la manera
> > siguiente:
> >
> > 1. Se hace un sp_detach_db de la base de datos.
> > 2. Se copian los ficheros .mdf y .ldf en un dispositivo externo.
> > 3. Se vuelve a hacer un sp_attach_db de la base de datos.
> >
> > Yo creo que no es la mejor forma de hacerlo pero no sé precisar qué
posibles
> > problemas puedan surgir. Pienso en cómo quedaran los logins, usuarios,
jobs,
> > .
> >
> > Se aceptan comentarios.
> >
> > Gracias y un saludo,
> >
> >
> >
> >