detectar cambios en archivos en tiempo real?

BocaDePez 18 febrero 2010 11:14

⋮

Hola, uso Freebsd, espero que tenga entrada en este foro jejeje.

Un dia me petó el disco duro y perdí información importante, hago backups, pero cada semana, asi que coincidió que perdí lo de esa semana, un jaleo enorme. La copia la hago en un disco duro conectado por USB.

Tengo muchisimos gigas de información (miles y miles de fotos, por ejemplo) por lo que si hago una copia de seguridad cada dia me tarda horas en copiar tantos gigas (pongamos 500 gb). Entonces se me ocurró usar rsync para que solo me copie los archivos que han cambiado, pero tengo tantos archivos, que en buscar cambios se tira tambien horas en recorrer todo el arbol de directorios del disco duro. Sería genial un sistema que me haga una copia del archivo cuando este ha cambiado. Por ejemplo, de esos 500GB modifico una foto de 10 MB, por lo que solo me copiaria esos 10MB empleando 1 segundo, y no recorriendose los 500GB de archivos para encontrar ese cambio de 10MB y que por tanto se tire tropecientasmil horas. Esto existe?

Gracias por adelantado!

BocaDePez 18 febrero 2010 11:53

⋮

Necesitas un RAID

✖

BocaDePez 18 febrero 2010 11:57

⋮

Un RAID sería por la catastrofe que me pasó, pero no es lo que pregunto. Un RAID no es un backup. Si en un RAID borro un archivo se borra tambien en su disco espejo, NO ES UNA COPIA DE SEGURIDAD es solo por si falla uno de los discos.

En mi caso quiero backup, es decir, si BORRO X sin querer, que pueda ir a la copia y recuperarla.

campi 18 febrero 2010 12:12

⋮

Creo que es posible hacerlo con NFS..

✖

BocaDePez 18 febrero 2010 12:29

⋮

NFS no es para montar una partición de otro equipo? es dcir, Network File System?

✖

vukits 18 febrero 2010 12:50

⋮

te da igual tirar de nfs desde computadora de lan que de localhost ;)

xavisuper 18 febrero 2010 12:48

⋮

Yo no descartaría investigar si en RAID+1 hay alguna opción para capar el borrado en la copia. Sería extraño, porque RAID trabaja a nivel de bloque en disco, y parte del mantenimiento de un sistema de ficheros puede incluir borrado de bloques que no necesariamente signifiquen borrado de ficheros, pero que sean necesarios para un sistema de ficheros íntegro.

Otra opción que se me ocurre es que uses un sistema de ficheros con journaling (ext3 o ext4 en linux, en FreeBSD no sé cuál sería) y busques una herramienta que tire de journaling para replicar datos. No sé exactamente cómo funciona el journaling ni si tendrías los mismos problemas que comentaba antes con RAID, pero podría estar bien investigarlo.

Hay sistemas de ficheros distribuidos, como el antiguo AFS, Coda, Intermezzo y alguno más, que aunque están pensados para tener árboles de ficheros en red, con réplicas y otras funcionalidades, quizás puedan tener aplicación a lo tuyo.

Si la solución no se integra con el sistema de ficheros, mucho me temo que cualquier herramienta basada en inspección de directorios y comparaciones, bien sea por checksum, por nombre o por fecha, va a ser más o menos igual de lenta que lo que ya tienes ahora.

xavisuper 18 febrero 2010 13:00

⋮

A lo mejor el rsync te va lento porque al estár comparando tu disco interno con el disco usb estás limitado por la velocidad del puerto usb. Si la comparación la haces además por checksum, entonces te eternizas.

Una alternativa que se me ocurre es que te crees un script que inicialmente calcule el checksum de todos los ficheros y lo guarde; y luego un find que recorra el disco, calcule el checksum de cada fichero, lo compare con el guardado previamente y si no coincide o no existe, que lo copie al disco de backup a la vez que actualiza el valor guardado de checksum. Con éso te evitas consultas al disco usb, sólo escribes los cambios, y aceleras el proceso.

✖

BocaDePez 18 febrero 2010 13:07

⋮

Creo que la demora se produce precisamente en recorrer los miles de archivos por centenas de directorios.

Estaba mirando el Coda y otros, pero parecen ser sistemas no muy actualizados. En Coda dicen que es de pruebas. Y Lustre, que ese l que he visto que es el actual, no creo que se aaplicable, habla de grandes, grandes corporaciones con superordenadores jeje.

Realmente si creo que sea a nivel de particion. Crear una partición de datos con un file system determinado que al crear A se crea en otra particion.

Solo que por ahora solo encuentro informacion obsolota y no me da buena espina.

✖

xavisuper 18 febrero 2010 13:17

⋮

Creo que la demora se produce precisamente en recorrer los miles de archivos por centenas de directorios.

Y si a éso le añades que lo haces por usb, diría que se ralentiza aún más. :(

La verdad es que no tengo una solución a tu problema. Lo que he dicho son reflexiones en voz alta, es lo que investigaría yo si me viese en tu caso, pero sin saber si el resultado te va a compensar.

A ver si alguien aporta alguna idea más.

superllo 18 febrero 2010 13:22

⋮

Yo creo que si tienes mucho material "estático" como fotos o vídeos hagas copia en DVDs (a todo caso dos) y lo envíes a sitios diferentes (por el tema de si una se pierde) ya que si no vas a modificar 10 gigas de fotos ¿por qué hacer copia todos los días?

Luego haces copia únicamente de lo que no tengas en DVDs y seguro que te va más rápido.

✖

BocaDePez 18 febrero 2010 14:03

⋮

Por eso motivo digo que es tonteria hacer copia cada dia de algo que no toco, incluso semanal o mensual. El problema está en que si modifico A B y C, no tenga que acordarme de hacer la copia, sino que un sistema detecte que solo he modificado A, B y C y por tanto no me copie X, Y, Z porque es lo mismo.

Un caso real seria: tengo que hacer un album de las vacaciones y tengo un directorio con 10 GB de fotos de la boda, con copia de seguridad en un disco duro USB. Día tras día pues voy modificando fotos, pongamos que a un ritmo de 1 GB por dia. En 10 días tendré todas las fotos retocadas. Es tonteria cada día estar copiando 10 GB de fotos si solo he modificado 1 GB. Y al dia siguiente lo mismo, para que copiar la modificación de ayer junto los otros 9 GB y hoy incluso no he tenido tiempo de retocar ninguna. Si asi le añadimos que en vez de 10GB pueden ser 50GB.

La opción manual sería acordarme de que fotos he retocado y copiarlas manualmente al USB, pero eso es un jaleo que quita tiempo y no es fiable ponerme a copiar a mano lo que yo creo que he modificado (si, podria hacer busquedas por fecha de modificación) pero encima puede que el equipo lo use otra persona y tambien se ponga a retocar fotos y se le olvide hacer el backup manual.

Por tanto, el tema esta en que RSYNC se tira horas en recorrer todo el disco duro para saber que ha cambiado y copiarlo al USB. ES mas rapido que copiar todo a saco pero aun asi son horas, vamos, que tengo que dejar el pc encendido para que lo haga por la noche.

Creo que el problema esta en que los pc actuales con discos USB o NAS siguen siendo lentos para volumenes de gigabytes, aun que no se como lo haran las grandes empresas para hacer un backup de Terabytes! Les tardaran dias!!!!

El tema de cuando termine el album pasar a DVD ya es otra historia a nivel de almacenamiento.

✖

superllo 18 febrero 2010 14:25

⋮

Pues por eso. Que lo que le está costando es ir archivo por archivo mirando la fecha de modificación y si son miles le cuesta un tiempo hacerlo. Por eso yo te decía que lo que tengas retocado lo pongas en un directorio separado de la copia y así que eso no lo rastree el RSYNC (o lo que tengas). Me imagino que cualquier programa de backup tendrá que hacer eso o algo parecido para encontrar archivos modificados.

BocaDePez 18 febrero 2010 18:35

⋮

¿Y por qué no poner una carpeta o directorio de entrada (o puente) hacia las carpetas finales. Dicha carpeta de entrada generaría el backup por fecha en otro lugar de almacenamiento.

✖

BocaDePez 18 febrero 2010 18:42

⋮

Perdón, no había leído bien. Lo que dije en este comentario anterior no tiene mucho sentido para lo que pretendes hacer. Disculpa.