Tengo dos directorios de respaldo que se encuentran en el mismo sistema de archivos en mi servidor de respaldo. El primero se llama "clon": contiene un clon de mi computadora portátil que se actualiza de forma remota todas las noches a través de rsync. El segundo se llama "copia de seguridad", que es una instantánea rsync semanal de solo las partes importantes del clon. Para ahorrar espacio, la "copia de seguridad" se crea como enlaces duros para clonar en lugar de copias, usando --link-dest:
rsync -avum --link-dest=/clone /clone/ /backup
Ahora también quiero usar la opción --backup para copiar las versiones antiguas de los archivos modificados desde la copia de seguridad a un área de almacenamiento, en caso de que las necesite o borre accidentalmente algo importante. Esto funciona bien sin --link-dest:
rsync -avumb --backup-dir=/holding/2016_10_22 /clone/ /backup
Sin embargo, esto crea copias de los archivos modificados en la copia de seguridad, lo que desperdicia espacio. Quiero enlaces físicos. Pero si vuelvo a agregar el parámetro --link-dest:
rsync -avumb --backup-dir=/holding/2016_10_22 --link-dest=/clone /clone/ /backup
...entonces soloeliminadose realiza una copia de seguridad de los archivos. Los archivos modificados están vinculados de forma silenciosa. La razón (creo) es que --link-dest comparte la lógica de --copy-dest. Es decir, si el archivo de origen no se modifica en relación con el archivo de destino de copia (o destino de enlace), entonces no se transfiere, sino que se copia/vincula desde el directorio de destino de copia/enlace al directorio de destino. Debido a que estoy usando el directorio de origen como directorio de enlace de destino, todos los archivos no eliminados permanecen "sin cambios" y se manejan de forma silenciosa.
Podría hacer esto en dos pasos: primero --backup sin --link-dest, luego nuevamente --link-dest sin --backup. (Las versiones más nuevas de rsync reemplazarán archivos idénticos con enlaces físicos). Pero realmente preferiría hacerlo todo de una vez.
¿Hay alguna manera de hacer --backup y al mismo tiempo crear solo enlaces físicos? (Realmente lo que quiero es rsync "normal" con enlaces físicos en lugar de transferencia de archivos. Mi uso de --link-dest parece un truco, dada la lógica prevista de esa opción).
Pregunta adicional: la página de manual parece indicar que se prefiere usar --link-dest solo en objetivos vacíos:
Esta opción funciona mejor al copiar en una jerarquía de destino vacía, ya que los atributos de los archivos existentes pueden modificarse y eso puede afectar a los archivos de destino alternativos a través de enlaces físicos. Además, el detalle de los cambios puede resultar un poco confuso.
La parte sobre detallar que se "confunde" es un poco vaga. ¿Usar --link-dest en un destino que no está vacío es realmente "peligroso", suponiendo que no me importen demasiado los atributos del archivo? ¿Alguien puede dar un ejemplo?
Respuesta1
Como mencioné anteriormente, terminé ejecutando el proceso en dos pasos.
src = the "live" clone directory, a mirror of my laptop = primary backup
dst = the weekly snapshot of important parts clone
trashdir = the items from src that don't exist in dst, because they have since been deleted, sorted into date-stamped directories
cmd = ("rsync -avumb --stats --delete --delete-excluded --filter='merge %s' --backup-dir=%s %s %s" %
(filterfile, trashdir, src, dst))
cmd = ("rsync -avum --stats --delete --delete-excluded --filter='merge %s' --link-dest=%s %s %s" %
(filterfile, src, src, dst))
El primer paso realiza una copia de seguridad de las partes importantes del clon y guarda los archivos que se eliminaron desde la última copia de seguridad en la papelera. (Hay razones por las que quiero esta copia de seguridad intermedia solo de archivos seleccionados y solo quiero que se actualice semanalmente).
El segundo paso convierte los archivos de la copia de seguridad en enlaces físicos que apuntan a la clonación. El resultado es que la copia de seguridad no ocupa espacio real. trashdir, por definición, no es un archivo vinculado, porque consta únicamente de archivos que se eliminaron de la clonación y la copia de seguridad.
No estoy del todo seguro de si los indicadores --delete-excluded son necesarios (particularmente en el segundo comando). Los dejé allí, en caso de que cambie el archivo de filtro, que define qué partes del clon se ignorarán al crear la copia de seguridad.
Descubrí que en cinco años, trashdir ha crecido hasta aproximadamente el tamaño del clon, por lo que tamaño total = clon x2, lo cual es aceptable para mí, dado que tengo seis años de historial de archivos eliminados y puedo podarlos fácilmente fecha.
Además de lo anterior, tengo un script que se ejecuta cp -alpara copiar el clon en aproximadamente un mes de instantáneas rotativas vinculadas con fecha y fecha. Esto me cubre para archivos que han sido modificados, en lugar de eliminados. El tamaño total durante un mes parece ser aproximadamente la mitad del tamaño del clon.
Entonces, el espacio total en disco es ~2.5 del clon, y tengo:
- el clon en sí, actualizado cada noche
- una copia de seguridad de archivos seleccionados que es estable durante una semana
- un mes de instantáneas clonadas versionadas
- seis años de archivos eliminados
Lo cual creo que es una protección bastante buena contra la pérdida del disco original, sobrescribir un archivo y necesitar una versión anterior, y eliminar un archivo y necesitarlo más adelante.
Es un poco complicado y probablemente podría haberse logrado con software de terceros, pero funciona para mí y está construido sobre herramientas de bajo nivel que probablemente no desaparezcan o cambien significativamente la funcionalidad.
(@gsl - En realidad, gracias por solicitar la actualización. Descubrí que uno de mis scripts falló cuando actualicé a python3 y no se había ejecutado durante un par de meses. ¡Necesito prestar más atención a mis registros de errores!)
Sin embargo, definitivamente todavía estoy interesado en formas de simplificar esto, así que no dudes en comentar si las cosas que estoy haciendo podrían lograrse de alguna manera más sencilla.