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. -- Saludos. Pablo. Fingerprint 5607 40CF 45EF D490 B794 5056 D7B2 C3DC ABF1 CE49 Jabber: bruli(at)myjabber(dot)net
Attachment:
pgp_ZidoZG9gG.pgp
Description: PGP signature