Esta es una extensión de¿Por qué rsync intenta copiar un archivo que ya está actualizado?
Estoy intentando utilizar el --copy-devicesparche para rsynccopiar una unidad de disco completa y almacenarla como una imagen en otra máquina.
La copia parece haberse ejecutado correctamente, sin embargo, cuando vuelvo a ejecutar rsynccon los mismos valores, parece copiar algunos de los datos nuevamente cada vez.
Corrí rsynccon la verbosidad y obtuve esto:
$ sudo rsync -vvz --partial --progress --copy-devices /dev/sdb me@otherserver:/backupdisks/mydisk.img
opening connection using: ssh -l me otherserver rsync --server -vvze.Lsfx --partial --copy-devices . /backupdisks/mydisk.img (11 args)
me@otherserver's password:
delta-transmission enabled
sdb
320,071,851,520 100% 63.47MB/s 1:20:09 (xfr#1, to-chk=0/1)
total: matches=2441955 hash_hits=2441955 false_alarms=204015955 data=0
sent 188 bytes received 21,979,001 bytes 2,837.31 bytes/sec
total size is 0 speedup is 0.00
Soy consciente de que rsync determina los cambios por tiempo, pero el disco no ha cambiado entre rsyncs (y, de todos modos, ¿cómo determinaría el tiempo de modificación de un disco?). Sin embargo, el tiempo en la imagen remota se actualiza cada vez. Entonces este podría ser el problema.
La otra posibilidad es que el disco tenga un sector defectuoso que devuelva un valor diferente cada vez y niegue cualquier suma de comprobación que se esté utilizando.
Mi pregunta es doble:
¿Mi imagen se ha transferido correctamente y, de ser así, por qué parece retransmitir gran parte del disco si lo ejecuto nuevamente? (Esto también puede responderse en parte como parte de mi corolario de la pregunta¿Qué son "coincidencias", "hash_hits" y "false_alarms" en la salida de rsync? ¿"data=0" significa éxito?)
¿Me falta un interruptor para que esto funcione correctamente? (¿Quizás
--checksum?) ¿Es posible enumerar las fallas a nivel de bloque utilizadas por el algoritmo rsync?
Respuesta1
De forma predeterminada, rsync compara archivos por tamaño y marca de tiempo, pero un dispositivo no tiene un tamaño, por lo que debe calcular las diferencias utilizando el algoritmo delta que se describe en esteinforme técnico. En términos generales, el archivo remoto se divide en bloques de un tamaño elegido y las sumas de verificación de estos se devuelven. El archivo local se suma de manera similar en bloques y se compara con la lista. Luego se le dice al control remoto cómo volver a ensamblar los bloques que tiene para rehacer el archivo, y se envían los datos de los bloques que no coinciden.
Puede ver esto solicitando resultados de depuración en el nivel 3 solo para el algoritmo deltasum con la opción --debug=deltasum3. Puede especificar un tamaño de bloque con -Bpara simplificar los números. Por ejemplo, para un archivo que ya se ha copiado una vez, una segunda ejecución de
rsync -B 100000 --copy-devices -avv --debug=deltasum3 --no-W /dev/sdd /tmp/mysdd
produce una salida como esta que muestra la suma de comprobación de cada bloque:
count=164 rem=84000 blength=100000 s2length=2 flength=16384000
chunk[0] offset=0 len=100000 sum1=61f6893e
chunk[1] offset=100000 len=100000 sum1=32f30ba3
chunk[2] offset=200000 len=100000 sum1=45b1f9e5
...
Luego podrás ver que coincide con las sumas de verificación del otro dispositivo de manera bastante trivial, ya que no hay diferencias:
potential match at 0 i=0 sum=61f6893e
match at 0 last_match=0 j=0 len=100000 n=0
potential match at 100000 i=1 sum=32f30ba3
match at 100000 last_match=100000 j=1 len=100000 n=0
potential match at 200000 i=2 sum=45b1f9e5
match at 200000 last_match=200000 j=2 len=100000 n=0
...
Al final, el data=campo es 0, lo que indica que no se enviaron datos nuevos.
total: matches=164 hash_hits=164 false_alarms=0 data=0
Si ahora corrompimos la copia sobrescribiendo la mitad del archivo:
echo test | dd conv=block,notrunc seek=80 bs=100000 of=/tmp/mysdd
touch -r /dev/sdd /tmp/mysdd
luego la depuración de rsync nos muestra una nueva suma de verificación para el bloque 80 pero no coincide. Pasamos del partido 79 al partido 81:
chunk[80] offset=8000000 len=100000 sum1=a73cccfe
...
potential match at 7900000 i=79 sum=58eabec6
match at 7900000 last_match=7900000 j=79 len=100000 n=0
potential match at 8100000 i=81 sum=eba488ba
match at 8100000 last_match=8000000 j=81 len=100000 n=100000
Al final mostramos data=100000que se tuvo que enviar un bloque de datos completamente nuevo.
total: matches=163 hash_hits=385 false_alarms=0 data=100000
El número de coincidencias se ha reducido en 1 debido a la suma de comprobación del bloque corrupto que no coincidió. Quizás los aciertos de hash aumenten porque perdimos la coincidencia secuencial.
si miramosmásEn el mismo informe técnico, se muestran algunos resultados de las pruebas y elalarmas falsas se describen como "el número de veces que la suma de comprobación móvil de 32 bits coincidió pero la suma de comprobación fuerte no". Cada bloque tiene una suma de verificación simple y una suma de verificación md5 (md4 en versiones anteriores). La suma de comprobación simple es fácil de buscar utilizando una tabla hash, ya que es un entero de 32 bits. Una vez que coincide con una entrada, también se compara la suma de comprobación md5 de 16 bytes más larga y, si no coincide, es una falsa alarma y la búsqueda continúa.
Mi ejemplo utiliza un dispositivo de llave USB muy pequeño (y antiguo) de 16 Mbytes, y el tamaño mínimo de la tabla hash es 2**16, es decir, 65536 entradas, por lo que está bastante vacía cuando tengo las 164 entradas de fragmentos que tengo. Tantas falsas alarmas son normales y son más una indicación de eficiencia que cualquier otra cosa.
Respuesta2
Desea considerar su uso rsync --partial --inplaceademás de sus otras opciones, porque de lo contrario, hará una copia completa de la imagen del disco en el lado de destino mientras está funcionando. También lo he estado usando -B 4096porque es el tamaño del sector natural del dispositivo y el tamaño de bloque predeterminado de rsync es demasiado pequeño para este tipo de operación.
Para verificar que la imagen se haya copiado correctamente, sugeriría que sha1sumse haga de forma independiente tanto en el lado de origen como en el de destino. No debería ser necesario, pero si quieres estar seguro, es sencillo y puedes confiar en ello. Supongo que su disco de origen no es un montaje en vivo ni nada desagradable por el estilo; de lo contrario, todas las apuestas están canceladas y no existe un método confiable para enviarlo.