Restic: Restic usa `mtime` para detectar cambios en los archivos, que pueden omitir cambios.

El uso de mtime presenta otro problema: los cambios solo en los metadatos, como el propietario, el grupo, los modos, las ACL POSIX y cualquiera de los atributos extendidos, no se detectan en absoluto.

La opción -f ayuda, pero lleva años hacer una copia de seguridad de un sistema de archivos enorme, ya que simplemente es equivalente a una copia de seguridad inicial; por ejemplo, en mi caso (aproximadamente 35G de datos, más de 600K archivos) se necesitan ca. 1,5 h para hacer la primera copia de seguridad, luego menos de 10 m por cada instantánea, pero con -f siempre se ejecuta más de 1 h.

El uso de mtime presenta otro problema: los cambios solo en los metadatos, como el propietario, el grupo, los modos, las ACL POSIX y cualquiera de los atributos extendidos, no se detectan en absoluto.

Hm, ¿a qué te refieres? Todas las comprobaciones mencionadas hasta ahora (mtime, ctime como se implementó en el # 2212) solo se usan para determinar si un archivo necesita ser releído o no. Los metadatos, incluidas las ACL, siempre están recién cargados y escritos en el repositorio. Si no ha cambiado desde la última copia de seguridad, la deduplicación de restic se encarga de que no se guarde de nuevo. Si algo ha cambiado, los metadatos se guardan en el repositorio.

¿Me pierdo algo?

@ fd0 Lo que quiero decir es que si solo han cambiado los metadatos, mtime no se modifica en absoluto, por lo tanto, los cambios en los metadatos solo no se llevarán a cabo en la copia de seguridad, ya que el archivo no se reconoce como cambiado en absoluto, al menos así fue en 0.9.4 y aún así en 0.9.5 (recién probado). He grabado una sesión que demuestra esto (usando chown y backup nuevamente).

Una vez implementado el # 2212, debería funcionar (espero), pero en las versiones actuales no funciona, a menos que se use --force (pero forzar la relectura de todo es demasiado costoso).

@aldem oh wow, ahora lo entiendo y puedo reproducirlo. Creo que es un error (separado) (y una regresión) del nuevo código de archivador introducido con 0.9.0. Yo investigaré ...

Es una regresión, funciona correctamente con 0.8.3. Abriré un nuevo problema y lo solucionaré.

Esto se rastrea como # 2249

@ fd0 Gracias, esto fue un verdadero

Encontré este boleto y luego el # 2212, así que pensé que aún no se implementó, por eso no presenté un informe de error.

Disculpe, pero ¿no deberíamos advertir más a los usuarios sobre este problema? Algo como "ATENCIÓN: ¡todas sus copias de seguridad realizadas con restic <= 0.9.5 podrían faltar archivos modificados!".

Solo descubrí esto después de que me mordieron duro (lo

Creo que la seriedad de esto va más allá de enloquecer a alguien que verifica todo (es decir, la suma de comprobación SHA para archivos restaurados) como yo, ya que los cambios que deberían haberse respaldado se están perdiendo, si alguien necesita recuperar uno de estos archivos de la copia de seguridad. (es decir, error del operador, recuperación ante desastres, etc.), sin ninguna advertencia, obtendrá un archivo antiguo y desactualizado: - / y en tal escenario, es decir, después de que se haya perdido el archivo original, se perderá para siempre: allí obviamente no hay forma de recuperarlo de una copia de seguridad resticida: frunciendo el ceño:

Hice una publicación separada al respecto en el foro , pero creo que esto debería figurar de manera más prominente en algún lugar, tal vez en el sitio web de restic o incluso en la página de descarga.

¿Podemos hablar un poco más sobre esto, por favor?

¿No es un comportamiento estándar para las herramientas de copia de seguridad de Unix usar mtime para detectar archivos modificados?

Obviamente, si cambia los datos del Archivo A y luego establece su mtime a lo que era antes de que cambiaran los datos, el archivo aparece sin cambios. Eso parece un caso clásico de, "Doctor, me duele cuando me pincho en el ojo".

Ahora, también obviamente, hay una amplia variedad de herramientas en la naturaleza, y algunas de ellas podrían hacer The Wrong Thing así. Entonces, de hecho, Restic debería tener una opción para considerar ctime u otras marcas de tiempo para determinar si un archivo ha cambiado. Tener esa opción es indudablemente algo bueno.

Pero me parece falso cambiar el valor predeterminado. AFAIK, este es un comportamiento inesperado y no estándar para una herramienta de respaldo de Unix y, como se indica en el n. ° 2495, cambiar el valor predeterminado tiene consecuencias importantes e indeseables.

Además, este cambio se realizó en una versión "Z" (como en el control de versiones XYZ de estilo SemVer), que debería reservarse para la corrección de errores, sin cambiar el comportamiento predeterminado. # 2495 es solo un ejemplo de usuarios de Restic con grandes cantidades de datos (14 TB en ese). Creo que los usuarios de Restic deberían poder esperar que la actualización de 0.9.xa 0.9.y no cambiará ningún comportamiento excepto para corregir errores.

Y este problema casi con certeza NO fue un error, porque cualquier programa que cambie intencionalmente el mtime de los archivos cuyos datos han cambiado a una marca de tiempo anterior casi seguramente está haciendo lo incorrecto y debería esperar tener ese efecto en las herramientas de respaldo.

Entonces, creo que el comportamiento predeterminado debería cambiarse nuevamente para usar mtime, que parece estándar para las herramientas de respaldo de Unix.

Si me equivoco acerca de que mtime es el estándar para las herramientas de copia de seguridad de Unix, tal vez sería conveniente hacer una encuesta.

Gracias.

SemVer dice:

1. La versión principal cero (0.yz) es para el desarrollo inicial. Cualquier cosa PUEDE cambiar en cualquier momento. La API pública NO DEBE considerarse estable.

@alphapapa En realidad, algunas herramientas de copia de seguridad "estándar" * ix como tar (aunque no hay un estándar oficial, para ser precisos) verifican ctime, ya que sin verificar ctime no sería posible detectar cambios de solo metadatos (propiedad, modos, etc. ).

@alphapapa escribió:

¿No es un comportamiento estándar para las herramientas de copia de seguridad de Unix usar mtime para detectar archivos modificados?

No, todo lo que sé que se realiza correctamente utiliza ctime. mtime es bastante inútil para las copias de seguridad, ya que se puede establecer en un valor arbitrario, y a menudo lo es. Simplemente descomprimir un archivo tar dará como resultado archivos con el mtime configurado como antes.

Las copias de seguridad realizadas estilo rsync hacen uso de la -mtime (pero no en contra de un incremento, sólo para ver si es diferente), y rsync archivos que han cambiado se pierda.

@alphapapa He considerado esto como una corrección de errores porque con mtime restic puede perder datos (el archivo ha cambiado pero mtime se restableció) y no recoger cambios de solo metadatos. Ambos son muy indeseables en mi humilde opinión. No esperaba que hubiera tantos casos en los que restic ahora vuelve a leer datos. Hmhmhm.

Si me equivoco acerca de que mtime es el estándar para las herramientas de copia de seguridad de Unix, tal vez sería conveniente hacer una encuesta.

Al menos borg detecta cambios basados ​​en ctime , size y inode de forma predeterminada: https://borgbackup.readthedocs.io/en/stable/usage /create.html

Se han hecho algunas afirmaciones aquí que no son necesariamente correctas, pero no son necesariamente incorrectas y me he debatido si debo desafiarlas ...

Una primera afirmación que me gustaría hacer es que ni ctime ni mtime están garantizados como métodos confiables para determinar si se ha producido un cambio. Esto fue especialmente cierto en el pasado, cuando estas marcas de tiempo tenían una segunda granularidad (o quizás peor, aunque afortunadamente nunca me enfrenté a eso). Esto significa que muchas herramientas más allá de las herramientas de copia de seguridad se ven afectadas por esto, incluido el comando "make", utilizado durante mucho tiempo para crear software. Esto ha mejorado con los sistemas de archivos que ahora tienen microsegundos o mejor granularidad, pero creo que es una premisa completamente falsa creer que la marca de tiempo por sí sola puede detectar si un cambio definitivamente se ha producido o no. Siempre habrá casos extremos, y lo mejor que puede hacer es intentar reducir los casos extremos, aunque esto a menudo tiene un costo de rendimiento.

Si realmente desea saber si el contenido cambió, debe verificar el contenido. Esto se aplica tanto a los datos como a los metadatos. Esta es la razón por la que comandos como "rsync" han tenido la capacidad de verificar el contenido desde que tengo memoria. Siempre es la opción si no puede confiar en las marcas de tiempo, en cuyo caso debe hacer una comparación completa de todo el contenido, o puede confiar en las marcas de tiempo, en cuyo caso se pueden omitir ciertas operaciones para optimizar el proceso.

La comprobación de ctime es un ejemplo de este tipo de compromiso. Al agregar ctime a la lista de comprobaciones, reduce significativamente la ya baja probabilidad de falla, pero el costo es que de repente agrega una serie de falsos positivos. La actualización de ctime no implica que el contenido haya cambiado, ni que los datos registrados en la copia de seguridad hayan cambiado. Solo indica que "algo sobre el inodo ha cambiado".

El principal problema que tengo con ctime es que lo que ctime está verificando son datos que se pueden consultar en su totalidad a bajo costo, y esto es lo que hace rsync. Quiero decir que ctime se actualizará si los metadatos cambian, pero verificar los metadatos en busca de cambios directamente es siempre la mejor verificación que verificar ctime. Probablemente nunca escribiría un código que diga "si ctime no se ha actualizado, omita la comprobación del propietario, el grupo, el tamaño o el número de inodo". Las llamadas stat () devuelven toda esta información y está disponible. Verificar los metadatos tiene el mismo costo y es más confiable que verificar si la marca de tiempo de los metadatos se ha actualizado. Por lo tanto, realmente no considero la actualización de ctime como prueba de nada, excepto que el sistema que marcó el inodo se ha actualizado, y si ya estamos verificando los metadatos que nos interesan, esta no es información realmente valiosa.

La única excepción parece ser el caso de un comando similar a "restaurar", como el "tar" mencionado anteriormente, que restaura mtime al pasado, lo que tiene el efecto de cascada de hacer que la copia de seguridad vea una marca de tiempo más antigua. En mi experiencia, no he encontrado que esto sea tan problemático como se describe. La marca de tiempo se actualiza después de llenar el archivo con datos, y cualquier comparación con la marca de tiempo debe usar "no es igual" en lugar de "mayor que" o "menor que", por lo que en realidad no veo el caso de problema de caso mencionado anteriormente como un preocupación real. De hecho, me siento tentado a argumentar lo contrario: si los datos se restauraron, tal vez debería omitirse. Sin embargo, esta debe ser una decisión explícita de la persona que realiza las manipulaciones.

También creo que vale la pena mencionar que existen herramientas de "restauración" que pueden restaurar tanto "ctime" como "mtime". Por ejemplo, en varios de mis casos de uso, hacemos un uso intensivo de instantáneas de volumen delgado LVM, posiblemente con la coordinación de aplicaciones para "inmovilizar" los datos (generalmente, descargarlos en el disco y pausar algunos tipos de actualizaciones), montar instantáneas particulares en un punto de montaje de "respaldo" y luego ejecute Commvault (sistema actual) contra el punto de montaje de "respaldo". Queremos cambiar esto a Restic. Este contexto adicional es para explicar que el uso de "ctime" y "número de inodo" son aspectos del sistema de archivos POSIX, que no necesariamente se conservan o interpretan de acuerdo con las expectativas puestas en ellos. Otros sistemas incluirían tecnologías de replicación. Básicamente, esta es la razón por la que restic tiene una opción "--ignore-inode", porque a menudo estos sistemas backend ni siquiera pretenden respetar el tipo de interpretación que se está aplicando, y esto hace que cualquier verificación contra ctime sea inválida.

Creo que hay razones legítimas para monitorear ctime y razones legítimas para ignorar ctime. Este no es un caso en el que un campo es definitivamente correcto y el otro campo está definitivamente equivocado. Este es un caso en el que es importante comprender cómo se crean sus datos y cómo se actualizan, para comprender cuál es el compromiso correcto entre copias de seguridad eficientes y confiables.

En mis casos hasta ahora, "--ignore-inode" cumple con mis requisitos. En la vida real, probablemente usaremos "--ignore-inode" en la mayoría, si no en todas, las aplicaciones de la vida real de Restic. No queremos el comportamiento de verificación "ctime". No creo que rsync pierda tantos casos como la gente ha sugerido, ni creo que ctime resuelva este problema al 100%. Creo que esta es una visión del mundo extremadamente conservadora. Esta visión conservadora puede ser válida si no comprende cómo se crean y actualizan los datos, o si cree que el costo de rendimiento vale la pena una verificación adicional. En mi opinión, para nuestros datos de producción de la vida real, no estoy de acuerdo en que el costo de rendimiento valga la pena la verificación adicional, y recomendaré que "--ignore-inode" se considere cuidadosamente y se recomiende en todos los casos, a menos que También desea monitorear casos excepcionales específicos sobre los que ciertas personas han advertido.

@MarkMielke

Verificar los metadatos tiene el mismo costo y es más confiable que verificar si la marca de tiempo de los metadatos se ha actualizado.

Se olvidó de las ACL de POSIX y los atributos extendidos en general; esto no es devuelto por la llamada stat (), pero incluso toda la información de inodo que devuelve stat () aún requiere comparaciones adicionales, por lo que solo es relativamente "de bajo costo" (tiene para ser analizado / deserializado y comparado uno por uno). Multiplique esto por millones de archivos y obtenga la imagen ...

En cuanto a la resolución de tiempo, sí, en algunos casos extremos (no) el cambio de ctime (en sistemas de archivos antiguos que carecen de una resolución inferior a un segundo) puede perder actualizaciones reales, pero es muy poco probable, incluso cuando la copia de seguridad se ejecuta una vez por minuto, las probabilidades de que se produzca un cambio específico golpee el mismo segundo solo durante la copia de seguridad anterior y no en el medio son bastante bajos, tal vez en sistemas muy cargados (pero si el sistema está muy cargado, entonces su copia de seguridad de comparación de contenido probablemente matará su rendimiento por completo).

No creo que rsync pierda tantos casos como la gente ha sugerido, ni creo que ctime resuelva este problema al 100%

No puedo hablar por todos, pero durante más de 15 años de uso de rsync con comprobaciones de ctime + mtime, nunca tuve un problema con los datos modificados (meta) perdidos (y son petabytes de datos y miles de millones de archivos sincronizados), mientras con restic (cuando se ignoró ctime) noté el problema casi instantáneamente (cuando se omitieron los cambios de propietario / modo), y la solución (comparar el contenido siempre) aumentó significativamente la E / S y el tiempo de respaldo incluso en el respaldo de volumen relativamente bajo.

Tiene suerte si su copia de seguridad se ejecuta durante menos de una hora (cuando siempre se compara el contenido), pero si necesita de 8 a 16 horas y tiene que hacerlo todos los días al menos una vez, descubrirá rápidamente que esto es un gran estrés. en el sistema (= todo es extremadamente lento), mientras que ctime (especialmente con una resolución de micro o nanosegundos presente en los sistemas de archivos modernos) elimina casi por completo la posibilidad de perder el cambio en al menos metadatos, y no conozco ningún método ( al menos en Linux) que es capaz de manipular ctime directamente (excluyendo imágenes de disco, por supuesto), por lo que es un buen indicador de cambios en metadatos / datos.

La principal ventaja es que, en la mayoría de los casos prácticos, ctime ayuda a _ evitar_ la comparación de metadatos o contenido, reduciendo así significativamente (órdenes de magnitud) el tiempo de copia de seguridad.

Sí, estoy de acuerdo en que debería haber opciones para ajustar el comportamiento restic (probablemente incluso extendiéndolas para usar diferentes métodos basados ​​en rutas / patrones), pero en cualquier caso, el "predeterminado" (tipo tar / rsync) debería basarse en ctime + mtime y creo que funciona como se esperaba "listo para usar" para el 99% de los usuarios.

La única excepción parece ser el caso de un comando similar a "restaurar", como el "tar" mencionado anteriormente, que restaura mtime al pasado, lo que tiene el efecto de cascada de hacer que la copia de seguridad vea una marca de tiempo más antigua. En mi experiencia, no he encontrado que esto sea tan problemático como se describe.

Lo he encontrado en numerosas ocasiones. Aunque, con git, esto parece menos común, solía descomprimir muchos archivos tar de archivos.

En cuanto a fallas de rsync. Para aclarar, no creo que rsync alguna vez use ctime. Solo está comparando dos árboles y, dado que no se puede establecer ctime, no se puede establecer en el mismo valor que el archivo fuente. Solo compara mtime y posiblemente otros atributos. El momento en que falló fue cuando un paquete debian reemplazó un archivo comprimido con una recompresión del mismo archivo. El mtime se estableció en el tiempo del archivo original y se volvió a comprimir al mismo tamaño. Pero dado que el encabezado gzip tiene una marca de tiempo, el contenido era diferente. En este caso, no importó demasiado, excepto cuando le pedí a dpkg que verificara el contenido de los paquetes instalados y el hash del archivo era incorrecto.

Acepto su punto de que los controles de acceso y los atributos extendidos son más costosos de consultar que solo lstat (). Sin embargo, me gustaría señalar que este es un caso de "mejor para estar seguro" frente a "rendimiento", y usted está eligiendo el rendimiento. Quiero decir, que cuando uso rsync y especifico las banderas -avHAXS las que estoy tan familiarizado al escribir, elijo pagar este costo, mientras que usted elige no hacerlo. También estuvo de acuerdo en que ctime en el pasado con segunda granularidad tenía un nivel de riesgo, pero está dispuesto a definir el riesgo como bastante bajo. Entonces, nuestras definiciones de comodidad son mucho más grises de lo que están alineadas o son polos opuestos. :-)

No puedo hablar por todos, pero durante más de 15 años de uso de rsync con comprobaciones de ctime + mtime, nunca tuve un problema con los (meta) datos modificados perdidos (y son petabytes de datos y miles de millones de archivos sincronizados). ..

Es interesante que digas eso, ya que mi experiencia es la misma ... con una excepción. Rsync no usa ctime. Estaba bastante seguro de que no era así, pero acabo de comprobar la fuente para estar absolutamente seguro, y no es así. No hay menciones de st_ctim o st_ctime, que es el campo que se extrae de lstat () para determinar el ctime del archivo. Hay varias menciones de st_mtime, que se introducen en la estructura de datos file-> modtime, donde la estructura del archivo tampoco tiene espacio para ctime.

Entonces, esto me lleva a preocuparme por este punto:

... mientras estaba con restic (cuando se ignoró ctime) noté un problema casi instantáneamente (cuando se omitieron los cambios de propietario / modo), y la solución (comparar el contenido siempre) aumentó significativamente la E / S y el tiempo de respaldo incluso en el respaldo de volumen relativamente bajo .

¡Este parece ser el verdadero problema al que te enfrentas! Esto me hace sospechar que estaba lidiando con condiciones de carrera o algún otro problema. rsync también tiene condiciones de carrera, pero es por eso que normalmente lo ejecutas más de una vez para recopilar las actualizaciones "desde" que escaneó esa parte del directorio, o si te sientes especialmente pedante como yo a veces, tomas instantáneas del sistema de archivos, y utilice rsync o restic en la instantánea para garantizar la coherencia del sistema de archivos.

Rsync no usa ctime.

Bueno, supuse entonces que rsync usa ctime para detectar cambios en los metadatos, ya que siempre fueron recogidos, aunque el resto seguramente lo hizo mtime (en mis conjuntos de datos no hay nada que manipule deliberadamente mtime, se actualiza solo en el contenido actualizaciones).

Pero incluso en el caso de que recurramos solo a comparaciones de metadatos (suponiendo que mtime sea confiable para detectar cambios de contenido), los ahorros son bastante grandes. Realmente no podía permitirme el lujo de esperar 8 horas cada vez que se tiene que hacer una copia de seguridad, y tiene razón: estoy dispuesto a aceptar el riesgo, especialmente ahora que la resolución de tiempo está en una escala de nanosegundos.

Honestamente, ni siquiera podría imaginar que se realizarán dos cambios en el mismo nanosegundo incluso en el disco RAM, lo que representa toda la sobrecarga de manejo de E / S (llamadas al sistema, cambios de contexto, etc.).

Esto me hace sospechar que estaba lidiando con condiciones de carrera o algún otro problema.

Sin condiciones de carrera, fue realmente simple: la copia de seguridad se realizó una vez, luego pocos archivos obtienen cambios de modo / acl (realizados pocos minutos después de la copia de seguridad, por lo que definitivamente no hay problemas de resolución de tiempo de [cm]), y no produjo ninguna actividad en la siguiente la copia de seguridad se ejecutará algún tiempo después. Sin embargo, resultó ser un error en restic, ya que no comparaba metadatos ni comprobaba ctime.

Rsync no usa ctime.

Rsync no usa ctime porque no puede. Se trata de sincronizar dos directorios. Dado que el ctime no se puede configurar, no tiene ningún sentido compararlo con nada.

Esto es muy diferente a algo como restic (o prácticamente cualquier otra solución de respaldo), donde se almacena el ctime. En este caso, hace comparar el ctime con lo que está almacenado en la copia de seguridad. Yo iría tan lejos como para argumentar que comparar el ctime es la _única_ forma de hacer una copia de seguridad de todo correctamente, y es por eso que, hasta donde puedo decir, cada sistema de respaldo (aparte de rsync, que realmente no llamaría respaldo) usa el ctime para determinar qué respaldar.

Rsync es una herramienta bastante diferente a Restic.

Sin condiciones de carrera, fue realmente simple: la copia de seguridad se realizó una vez, luego pocos archivos obtienen cambios de modo / acl (realizados pocos minutos después de la copia de seguridad, por lo que definitivamente no hay problemas de resolución de tiempo de [cm]), y no produjo ninguna actividad en la siguiente la copia de seguridad se ejecutará algún tiempo después. Sin embargo, resultó ser un error en restic, ya que no comparaba metadatos ni comprobaba ctime.

Sí, eso es un error enorme. Por sí solo, sin ningún otro factor. Debería estar verificando los metadatos, o supongo que al menos la marca de tiempo de los metadatos (= ctime). :-)

... y es por eso que, hasta donde yo sé, cada sistema de respaldo (que no sea rsync, al que realmente no llamaría respaldo) usa ctime para determinar qué respaldar.

Yo uso rsync para realizar copias de seguridad mucho más que cualquier otra herramienta, aunque a menudo se usa como un componente en un sistema más grande. La mayoría de los sistemas de copia de seguridad tradicionales son muy deficientes, y la copia de seguridad lleva horas y horas, mientras que rsync puede completarse en segundos o menos incluso para sistemas de archivos grandes, si se hace con cierta conciencia de cómo funciona rsync internamente.

La única razón por la que estoy aquí es porque creo que Restic es un poco diferente de los sistemas de respaldo tradicionales, y quiero que esta creencia se demuestre como cierta, y tal vez pueda usar rsync menos y más Restic.

Por ejemplo, un caso de uso muy común para mí: usaremos rsync para copiar un sistema de archivos local a un sistema de archivos NFS remoto, que es en sí mismo una instantánea y una copia de seguridad. Pero otros ejemplos incluyen el uso de rsync para obtener datos de un sistema de archivos local en un servidor de producción a un servidor de archivos local en un servidor en espera, y luego realizar la copia de seguridad en el servidor en espera, de modo que el proceso de copia de seguridad en sí (que puede llevar varias horas , especialmente si se trata de una copia de seguridad basada en aplicaciones) no genera una sobrecarga de rendimiento en el servidor de producción. (A veces nos volvemos más sofisticados que esto ... y clonamos el volumen iSCSI que aloja los datos, lo montamos en el servidor en espera y hacemos una copia de seguridad de esto ...)

Mi punto en todo esto es que es realmente fácil para cualquiera de nosotros, incluido yo mismo, ver nuestras propias experiencias y sacar conclusiones fáciles y rápidas sobre cómo hacemos las cosas y cómo otras personas no deben hacerlo correctamente. Pero, si no cumple con los requisitos de las otras personas, es difícil decir realmente si lo están haciendo incorrectamente o no. Hay más de una respuesta a esta pregunta.

@ d3zd3z

Rsync no usa ctime.

Rsync no usa ctime porque no puede. Se trata de sincronizar dos directorios. Dado que el ctime no se puede configurar, no tiene ningún sentido compararlo con nada.

Esto es muy diferente a algo como restic (o prácticamente cualquier otra solución de respaldo), donde se almacena el ctime. En este caso, hace comparar el ctime con lo que está almacenado en la copia de seguridad. Yo iría tan lejos como para argumentar que comparar el ctime es la _única_ forma de hacer una copia de seguridad de todo correctamente, y es por eso que, hasta donde puedo decir, cada sistema de respaldo (aparte de rsync, que realmente no llamaría respaldo) usa el ctime para determinar qué respaldar.

Rsync es una herramienta bastante diferente a Restic.

Si puedo jugar al abogado del diablo por un momento, para ayudarme a pensar más claramente sobre estas herramientas:

¿En qué se diferencia fundamentalmente Restic de Rsync? Rsync sincroniza dos árboles de directorios, ya sean remotos o locales. Restic sincroniza efectivamente dos árboles de directorio, uno de ellos montado localmente y el otro es un árbol virtual almacenado en el repositorio de respaldo de Restic. Por supuesto, hay un millón de opciones y Rsync es una herramienta muy flexible y poderosa. Incluso puede realizar copias de seguridad (reales) mediante el uso de enlaces físicos en el destino. Pero fundamentalmente, ¿no están haciendo lo mismo: sincronizar dos árboles de directorios?

Si es así, entonces por esa lógica, si Rsync no usa ctime, ¿por qué debería hacerlo Restic? ¿Es solo una optimización para almacenar ctime y comparar eso en lugar de otros metadatos?

Gracias a ti y a @MarkMielke por tu esclarecedora discusión aquí.

Si es así, entonces por esa lógica, si Rsync no usa ctime, ¿por qué debería hacerlo Restic?

rsync no lo hace porque no puede establecerlo en un valor específico en el sistema de archivos de destino, mientras que restic almacena el valor de ctime en el archivo, por lo que podría compararse.

Como mencioné antes, comparar metadatos de millones de archivos (sin comparar contenido) podría resultar bastante caro.

Si es así, entonces por esa lógica, si Rsync no usa ctime, ¿por qué debería hacerlo Restic? ¿Es solo una optimización para almacenar ctime y comparar eso en lugar de otros metadatos?

Rsync no usa ctime porque no puede, no porque no debería. Otro ejemplo sería Unison, que usa ctime. También almacena una base de datos para cada lado que almacena los metadatos del archivo (principalmente ctime) para que pueda saber cuándo cambia un archivo.

La diferencia fundamental es que restic hace múltiples instantáneas de un sistema de archivos y las almacena todas. rsync intenta sincronizar un directorio con otro, sin almacenar ningún otro dato. Hace lo mejor que puede sin almacenar nada, pero debido a que no tiene forma de saber cuál era el ctime antes, realmente no puede saber perfectamente si algo ha cambiado.

Restic no está "sincronizando", está haciendo una instantánea. Funciona bien sin hacer referencia a la copia de seguridad anterior, e incluso debería almacenar el mismo resultado (debido a la deduplicación). Dado que podemos almacenar el ctime, eso se puede comparar con la fuente para hacer que esta optimización sea más robusta que solo adivinar basándose en otros parámetros.

En cuanto a fallas de rsync. Para aclarar, no creo que rsync alguna vez use ctime. Solo está comparando dos árboles y, dado que no se puede establecer ctime, no se puede establecer en el mismo valor que el archivo fuente. Solo compara mtime y posiblemente otros atributos. El momento en que falló fue cuando un paquete debian reemplazó un archivo comprimido con una recompresión del mismo archivo. El mtime se estableció en el tiempo del archivo original y se volvió a comprimir al mismo tamaño. Pero dado que el encabezado gzip tiene una marca de tiempo, el contenido era diferente. En este caso, no importó demasiado, excepto cuando le pedí a dpkg que verificara el contenido de los paquetes instalados y el hash del archivo era incorrecto.

Ewww. :-) Programa de compresión incorrecto. :-)

Restic no está "sincronizando", está haciendo una instantánea. Funciona bien sin hacer referencia a la copia de seguridad anterior, e incluso debería almacenar el mismo resultado (debido a la deduplicación). Dado que podemos almacenar el ctime, eso se puede comparar con la fuente para hacer que esta optimización sea más robusta que solo adivinar basándose en otros parámetros.

Éstos son semántica. :-)

Me encanta cuando la tecnología disruptiva como Git reinventa por completo la forma de pensar de las personas (incluida la forma en que probablemente dio forma a Restic), pero cuán fundamentalmente se trata de un concepto simple como obtener datos de un lugar a otro de la manera más eficiente posible sin romperlos.

Las confirmaciones de Git son instantáneas del sistema de archivos. Puede discutir si la creación de una confirmación de Git es sincronizar o hacer instantáneas, pero el efecto es realmente el mismo. Está capturando el estado de un sistema y describiéndolo en otro sistema, de tal manera que podría reproducir el sistema original +/- algunos artefactos. Curiosamente para mí ... Git tampoco almacena ctime. :-)

Curiosamente para mí ... Git tampoco almacena ctime. :-)

Además, no es correcto. El índice de git almacena el ctime (y mtime) de cada archivo, y si el ctime cambia, repite los archivos. Su comportamiento es prácticamente idéntico a cómo lo hace Restic. Formato de índice de Git .

Mi error. Lo siento. :-) La bonita impresión lo excluye. :-)

(Aunque, esto plantea la pregunta de para qué se usa realmente ... ya que si realmente reafirma el archivo para cada nuevo espacio de trabajo, Git realmente no funcionaría ... se requiere investigación ...) -

ACTUALIZAR: El índice solo se utiliza para detectar rápidamente cambios en el árbol de trabajo. También tiene opciones similares como "trustctime", con un toque divertido:

       core.trustctime
           If false, the ctime differences between the index and the working tree are ignored; useful when the inode change time is regularly modified by something outside Git (file
           system crawlers and some backup systems). See git-update-index(1). True by default.

Y en git-update-index:

       The command also looks at core.trustctime configuration variable. It can be useful when the inode change time is regularly modified by something outside Git (file system
       crawlers and backup systems use ctime for marking files processed) (see git-config(1)).

Al parecer, algunos sistemas de copia de seguridad actualizan ctime? :-) Eww ....

(Aunque, esto plantea la pregunta de para qué se usa realmente ... ya que si realmente reafirma el archivo para cada nuevo espacio de trabajo, Git realmente no funcionaría ... se requiere investigación ...) -

Si copia un espacio de trabajo de git en otro lugar (o lo restaura desde la copia de seguridad), git de hecho repetirá todos los archivos.

Al parecer, algunos sistemas de copia de seguridad actualizan ctime?

Por ejemplo, gnu tar tiene una opción --preserve-atime , que luego de acceder al archivo, establece el atime, lo que tiene como consecuencia la actualización del ctime.

No tengo conocimiento de nada que use ctime para marcar archivos procesados, o cómo funcionaría eso. Supongo que modifican mtime o atime, lo que tiene la consecuencia de actualizar ctime.

Si es así, entonces por esa lógica, si Rsync no usa ctime, ¿por qué debería hacerlo Restic? ¿Es solo una optimización para almacenar ctime y comparar eso en lugar de otros metadatos?

Rsync no usa ctime porque no puede, no porque no debería. Otro ejemplo sería Unison, que usa ctime. También almacena una base de datos para cada lado que almacena los metadatos del archivo (principalmente ctime) para que pueda saber cuándo cambia un archivo.

Unison es un ejemplo especialmente interesante, ya que utiliza el protocolo de transferencia Rsync (aunque no el algoritmo de detección de cambios Rsync). De su manual:

Detección de actualización rápida
Si sus réplicas son grandes y al menos una de ellas está en un sistema Windows, puede encontrar que el método predeterminado de Unison para detectar cambios (que implica escanear el contenido completo de cada archivo en cada sincronización, la única forma completamente segura de hacerlo bajo Windows) es demasiado lento. Unison proporciona una verificación rápida de preferencias que, cuando se establece en verdadero, hace que utilice tiempos de creación de archivos como 'pseudo números de inodo' al escanear réplicas en busca de actualizaciones, en lugar de leer el contenido completo de cada archivo.

Cuando fastcheck se establece en no, Unison realizará una verificación lenta, volviendo a escanear el contenido de cada archivo en cada sincronización, en todas las réplicas. Cuando fastcheck se establece en el valor predeterminado (que, naturalmente, es el predeterminado), Unison utilizará comprobaciones rápidas en las réplicas de Unix y comprobaciones lentas en las réplicas de Windows.

Esta estrategia puede hacer que Unison pierda la propagación de una actualización si la hora de modificación y la longitud del archivo no han cambiado por la actualización. Sin embargo, Unison nunca sobrescribirá dicha actualización con un cambio de la otra réplica, ya que siempre realiza una verificación segura de actualizaciones justo antes de propagar un cambio. Por lo tanto, es razonable usar este modificador la mayor parte del tiempo y ocasionalmente ejecutar Unison una vez con fastcheck configurado en no, si le preocupa que Unison haya pasado por alto una actualización.

Fastcheck está (siempre) deshabilitado automáticamente para archivos con extensión .xls o .mpp, para evitar que Unison se confunda con los hábitos de ciertos programas (Excel, en particular) de actualizar archivos sin cambiar sus tiempos de modificación.

Tantos programas que se portan mal. :)

La diferencia fundamental es que restic hace múltiples instantáneas de un sistema de archivos y las almacena todas.

Rsync puede hacer eso con copias de seguridad de enlaces físicos, cada una de las cuales es una instantánea.

rsync intenta sincronizar un directorio con otro, sin almacenar ningún otro dato. Hace lo mejor que puede sin almacenar nada, pero debido a que no tiene forma de saber cuál era el ctime antes, realmente no puede saber perfectamente si algo ha cambiado.

Me pregunto si alguien ha implementado algún tipo de "caché ctime" para Rsync para acelerar las comparaciones de árboles grandes.

Restic no está "sincronizando", está haciendo una instantánea. Funciona bien sin hacer referencia a la copia de seguridad anterior, e incluso debería almacenar el mismo resultado (debido a la deduplicación).

¿Hacer una instantánea no sincroniza fundamentalmente los datos desde su origen hasta su destino en la instantánea? Lógicamente está sincronizando datos de un lugar a otro, independientemente de los formatos. Imagínese montar una instantánea de Restic con FUSE y luego ejecutar Rsync en ella (hmm, esa podría ser una forma útil de verificar el contenido de una instantánea después de hacer una).

Dado que podemos almacenar el ctime, eso se puede comparar con la fuente para hacer que esta optimización sea más robusta que solo adivinar basándose en otros parámetros.

Entonces, es solo una optimización que depende de que el sistema de archivos se comporte como se espera, ¿verdad?

Vine aquí porque me gustaría ignorar ctime. Encontré el modificador --ignore-inode, pero no ayuda con respecto al ctime.

Mi sugerencia para toda esta discusión sería agregar un interruptor como:
--ignore-ctime

@ geri777 Como se trata de una solicitud de función independiente de este problema, abra una nueva edición (elija "Solicitud de función" como tipo cuando se le pregunte al respecto) y, allí, complete la plantilla. Explique también el caso de uso de la solicitud.