Duplicidad de respaldo completo de por vida y eficiencia

Estoy tratando de elaborar una estrategia de respaldo para algunos clientes, y me estoy inclinando hacia la duplicidad para el respaldo remoto (ya uso rdiff-backup para respaldos internos / en la ubicación).

¿Es razonable querer una copia de seguridad completa de vez en cuando? Dado que la duplicidad aumenta hacia adelante, cada copia de seguridad incremental depende del incremento anterior, y todas dependen en gran medida de la última copia de seguridad completa. Si eso se corrompe, suceden cosas malas. Una pregunta relacionada: ¿Duplicity prueba la coherencia de las copias de seguridad incrementales?

Suponiendo que no quiero una copia de seguridad completa de vez en cuando, qué grado de eficacia duplicidad crear esa copia de seguridad completa? ¿Puede / verifica las firmas de archivos y copia datos sin cambios de copias de seguridad / incrementos completos anteriores? Básicamente, ¿crear un nuevo archivo 'completo' transfiriendo datos nuevos / modificados y fusionando datos existentes sin cambios?

En este momento, mi preocupación es que se necesita ejecutar una copia de seguridad completa, pero el uso constante de gran ancho de banda de las copias de seguridad completas hará que esto no sea razonable para algunos clientes.

Creo que es razonable querer una copia de seguridad completa de vez en cuando: la mayoría de mis máquinas están configuradas para hacer una cada pocos meses. Ese número no tiene nada de mágico: el valor correcto dependerá de la cantidad de datos que tenga, la rapidez con la que cambien, la probabilidad de que desee restaurar desde cualquier otra cosa que no sea la instantánea más reciente, cuánto tráfico y almacenamiento le cuesta y cuán paranoico eres. Otras personas pueden querer una copia de seguridad completa cada semana.

A menos que haga una copia de seguridad completa de vez en cuando, el tamaño del archivo y el tiempo de recuperación continuarán creciendo.

No creo que la duplicidad tenga específicamente un comando "check" http://pad.lv/660895 , pero sería bueno si lo hiciera. Es muy prudente hacer una restauración de prueba de vez en cuando.

Una pregunta relacionada es si debe mantener más de una cadena de respaldo. De nuevo, depende del costo. Una razón para conservar uno es que podría restaurarlo si la cadena actual está dañada, ya sea debido a una falla de hardware, falla del sistema operativo o un error de duplicidad. Por supuesto, si la cadena anterior es muy antigua, restaurarla puede tener un valor limitado.

Hacer una copia de seguridad completa siempre carga una copia completa de los datos.

Si la preocupación del cliente es la fracción de ancho de banda utilizada, en lugar de los cargos de tráfico, es posible que desee ejecutarlo, por ejemplo trickle.

Lo que está pidiendo se llama una copia de seguridad completa sintética , que se refiere al proceso de obtener una copia de seguridad completa combinando una copia de seguridad incremental con una copia de seguridad completa anterior en el lado de destino (es decir, el servidor de copia de seguridad).

No estoy familiarizado con Duplicity, pero desde su sitio web parece no hacer copias de seguridad completas sintéticas. Debe mantener todos los incrementales de nuevo al máximo en los que se basan. Si ese es el caso, es probable que desee forzar una copia de seguridad completa de vez en cuando, porque:

• Pasar por un millón de incrementos probablemente hará que las restauraciones sean lentas
• Probablemente no desee mantener los incrementales que se remontan al principio de los tiempos.

Una forma interesante de lograr fulls sintéticos es usar rsync con la opción --link-dest = DIR , o usar rsnapshot . Solo almacenará las diferencias entre cada copia de seguridad incremental, pero cada una parecerá estar llena. Cuando elimine alguno de ellos, fusionará automáticamente los incrementales de manera apropiada. Lo hace a través de la magia de los enlaces duros, por lo que las diferencias se basarán en archivos (o bien el archivo ha cambiado y está incluido en la diferencia, o no).