Hi, this is the Mlmmj program managing the
mailing list.
Somebody (and we hope it was you) has requested that your email address
be added to the list. This means every time a
post is sent to the list, you will receive a copy of it.
To confirm you want to do this, please send a message to
which
El FTP ya lo había abandonado hace mas de 15 años porque tenia ese tipo de
problemas.
Me obligaba a usar un checksum.
Si usas la backup de SQL con compresión los archivos no se te van a
comprimir casi nada si usas compresión adicional externa ya que se produce
un fenómeno de aleatorización.
--
Si, pero en este caso no son cortes de red, el archivo pasa completo pero algo
hace que no se pueda leer correctamente
Diego Vega
Administración de Base de Datos y Aplicaciones
Gerencia de Tecnologia y Sistemas
t. (351) 4207121 / Int. 5136 / 7119 / 7121
Humberto Primo 670 3º piso - Torre Suquia,
baja
El 13 de febrero de 2015, 17:22, Jose Mariano Alvarez <
jose.mariano.alva...@gmail.com> escribió:
> Robocopy te permite esperar para reiniciar la copia desde el punto que se
> corto la red por ejemplo.
>
> Saludos
>
> --
>
> Ing. José Mariano Alvarez
> http:/
Gracias por el tip.
Como estoy usando S3, se puede utilizar un checksum para verificar que el
archivo haya llegado bien. Voy a asegurarme que la herramienta que uso
para subir el archivo lo este chequeando :)
Saludos!
Diego
2015-02-13 17:09 GMT-03:00 Vega Diego Raul :
> Hola Diego, a lo que ya
Robocopy te permite esperar para reiniciar la copia desde el punto que se
corto la red por ejemplo.
Saludos
--
Ing. José Mariano Alvarez
http://blog.josemarianoalvarez.com/
http://twitter.com/JoseMarianoA
SQL Total Consulting
El 13 de febrero de 2015, 5:
Hola Diego, a lo que ya se dijo yo le sumaría que tengas cuidado al mover el
archivo de backup, a nosotros nos suele pasar cuando movemos archivos grandes
(mas de 20Gb + o - ) por un ftp al descargarlo no sé por qué el archivo queda
inconsistente, lo que solucionamos comprimiendo el archivo y de
Gracias!
2015-02-13 16:28 GMT-03:00 Jose Mariano Alvarez <
jose.mariano.alva...@gmail.com>:
> Surgen de las auditorias.
> Cada 6 meses hacen un file-over al datacenter de contingencia y prueban
> los restore.
>
>
> --
>
> Ing. José Mariano Alvarez
> http://blog.jo
Surgen de las auditorias.
Cada 6 meses hacen un file-over al datacenter de contingencia y prueban los
restore.
--
Ing. José Mariano Alvarez
http://blog.josemarianoalvarez.com/
http://twitter.com/JoseMarianoA
SQL Total Consulting
El 13 de febrero de 2015, 3
Gracias por la info. La necesidad de "ejercitar los mecanismos operativos
de recuperación" esta.
Solo por curiosidad, sabes cada cuanto deben hacer esto los bancos?
2015-02-13 15:09 GMT-03:00 Jose Mariano Alvarez <
jose.mariano.alva...@gmail.com>:
> Hacer restore periódicos con cierta frecuenci
Gracias por la aclaracion. Con verify me referia a hacer el backup tildando
la opcion "verify when finished", no se como se llama en SQL, creo que solo
VERIFY.
Sumando lo tuyo a lo que dijo Mariano, entiendo que no tendria mucho
sentido en mi caso entonces.
Yo actualmente hago un backup a disco (
Title: Olá
Olá,
estamos enviando e-mail de notificação de pendências financeiras em seu
cadastro, referente a compra de um
TV LED 46" Full HD com
Conversor Digital Integrado, 4 HDMI, Entrada PC, USB, UN46C5000 - Samsung,
pelo Pague Seguro UOL. A
Hacer restore periódicos con cierta frecuencia (y no de todos los backups)
es una buena practica no solo para probar la consistencia del backup sino
también para ejercitar los mecanismos operativos de recuperación. Por
ejemplo, a los bancos el central se lo exige.
Saludos
--
--
Hola Diego,
- El checkDB te proteje de inconsistencias en las bases de datos
productivas, hay inconsistencias que pueden pasar al backup y estarias
haciendo un backup con algo inconsistente
- El checksum sirve para determinar al momento de restore si el archivo de
backup esta instacto o no, y adema
Y que porcentaje de seguro estoy si no lo hago? :)
Parece broma, pero en realidad es en serio... Si queres saber si un auto
0km funciona la unica forma de estar seguro es probarlo, pero la verdad es
que podemos estar 99% seguros sin probarlo. Es una aberración no hacer el
RESTORE o con lo que e
Yo haría el chequeo de la base después del backup full si quiero verificar
que la base no se "rompió" entre el chequeo y el backup. Me garantiza que
en el estado previo la base esta consistente o se puede llegar a un estado
consistente.
Si el backup es a disco es muy probable que no tengas problema
Si queres estar 100% seguro te aconsejo restore.
El feb 13, 2015 1:23 PM, "Diego Jancic" escribió:
> Buenas gente!
>
> Tengo un SQL Server 2008R2 en produccion al que le estamos haciendo
> backups completos diarios y de transaction log cada 30 minutos.
>
> Para el FULL backup:
> - Hago DBCC CHECK
Buenas gente!
Tengo un SQL Server 2008R2 en produccion al que le estamos haciendo backups
completos diarios y de transaction log cada 30 minutos.
Para el FULL backup:
- Hago DBCC CHECKDB antes del backup
- Hago el backup con "Verify"
- Hago el backup con "Checksums"
Para los LOG backups, tambien
Your are subscriber of list sympa-us...@listes.renater.fr with email
archive@mail-archive.com
Everything about this list: https://listes.renater.fr/sympa/info/sympa-users
Unsubscription:
mailto:sy...@listes.renater.fr?subject=sig%20sympa-users%20archive%40mail-archive.com
19 matches
Mail list logo
