Pablo Braulio wrote:
El Domingo, 23 de Octubre de 2005 19:54, Manuel escribió:
A mi me parece que el problema no es necesariamente de ancho de banda,
ni de la aplicación que usas para transferir el archivo. Creo que el
problema es de la política de backup .
Pues la política es la siguiente, pues me parece la mas acertada.
Hago un tgz por cada día laboral de la semana (copia-lunes.tgz,
copia-martes.tgz....). Es decir, dispongo siempre de 5 copias.
Hasta ahora hacía la copia sincronizándola diariamente con rsync, a otro disco
duro y otro equipo. Entonces si que podía hacer update. También podía hacer
esto fuera de mi red local con rsync.
Pero esto no me parece lo mas correcto, pues en el caso de que la información
original se borre accidentalmente o se dañe, se daña la copia. Es decir, si
por error se borra algo o se modifica algún archivo, se daña la base de
datos, etc., cuando el sistema haga la copia que tiene programada (cron),
entonces el directorio de destino de la copia será igual de erroneo.
Es por esto que prefiero hacer una copia por cada día y en este último caso
puedo restaurar.
Como última medida de seguridad, hay que sacar las copias (o copiarlas) a otro
equipo fuera del despacho.
Para esto estoy probando sftp o rsync --rsh=ssh. Parece ser que rsync (con
ssh) funciona más rápido.
Para un archivo de 227 mb sftp ha tardado mas de 3 horas, mientras que rsync
ha tardado 1:20 horas.
Has comparado rsync con archivos tar y no tgz, a lo mejor hace un mejor
trabajo?.
Las comparaciones de rsync puede que no sean muy eficientes si el
archivo es muy grande y binario, no lo sé, solo lo intuyo. Si el
respaldo es diferencial o incremental ya cortas por la cabeza las
redundancias, a menos que el respaldo sea una base de datos con muchas
alteraciones.
El problema con los respaldos incrementales son los restores pero es
manejable. lo debes probar para que estés seguro de que funciona el
procedimiento, puede ser en un equipo de pruebas porcia y debe dar un
mirror como resultado.
Otro tema es que hay compresores especializados en archivos grandes.
http://rzip.samba.org/
Suerte,
MS
Suerte
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]