Copia de security RSync del repository de Subversion con Rsyncrypto

La situación

Tengo un repository de Subversion bastante grande que estoy tratando de hacer copys de security de manera eficiente. El tamaño del repository es de aproximadamente 6 GB y sigue creciendo. Algunas confirmaciones grandes tienen un tamaño de entre 500 y 1 GB.

Estoy intentando hacer una copy de security de este repository en una location externa, a través de un enlace ascendente de Internet.

Explicando el tamaño de esto

Quien se lo esté preguntando, mantenemos todo el entorno de producción para varios sitios (files de configuration, EXEs, files de datos) en este único repository, de modo que podamos retroceder a una versión de trabajo existente y rastrear los cambios en la configuration de producción. El código se guarda en un repository diferente.

El como

Esto es lo que estoy haciendo en realidad:

  1. Copia de security del repository en una carpeta de trabajo en el server utilizando el "svnadmin hotcopy SRCDIR TGTDIR"
  2. Cifre y comprima ese repository usando "rsyncrypto -r SRCPATH DSTPATH ​​KEYSPATH CERTIFICATE"
  3. Realice una copy de security de la versión cifrada en una location externa utilizando "rsync -Crtv" (en realidad cwRsync porque estoy ejecutando en Windows)

El problema

Primero debo decir que funciona, aunque todavía tiene un problema subyacente.

El problema radica en el hecho de que esperaba que cada vez que se ejecutara el process, solo se copyrían los nuevos files / datos de revisión ([repos] / db / revs / 0 / …), requiriendo solo ancho de banda y time cuando se hace una gran comisión. Sin embargo, en cambio:

  • Si solo ejecuto el paso 3 muchas veces, rsync se comporta como debería y no se copy nada porque nada ha cambiado.
  • Si ejecuto solo los pasos 2 y 3 muchas veces, rsync también se comporta bien. La versión encriptada es la misma siempre y rsync no tiene que transmitir nada.
  • Pero, parece que cada vez que ejecuto los tres pasos (con un nuevo compromiso realizado en el repository) todo el repository se vuelve a cargar en su totalidad . Por lo tanto, se está derrotando todo el propósito de usar rsync en primer lugar.

Es como si los files en [repos] / db / revs / 0 / … estuvieran cambiando cada vez que hago una copy en caliente.

Las preguntas

¿Es esto un comportamiento esperado de "svnadmin hotcopy" que los [repos] / db / revs / 0 / … cambian de una copy en caliente a otra?

¿Alguna sugerencia u opción que pueda utilizar para hacer que este hotcopy rsync sea amigable o diga rsyncable ?

No estoy seguro de que el uso de 'svnadmin dump' en todo el repository produzca un file "rsyncable" .

No conozco los detalles de cómo Subversion almacena sus files de copy de security, así que no sé si una copy rápida de r5678 debería ser idéntica a una copy en bloque de r6789 (que es lo que rsync necesitaría para hacer una copy eficiente) ) Lo que hacemos cuando realizamos una copy de security de nuestro repository de desarrollo es hacer una copy de security completa (copy rápida y luego realizar copys de security completas de todos los conciertos) cada semana, y hacer una copy de security incremental todos los días usando el siguiente command:

 svnadmin dump /path/to/repos -r latest-backed-up-rev:latest-repos-rev --incremental --deltas 

La opción –incremental significa "Esto se debe aplicar a un repository en la revisión latest-backed-up-rev", y la opción –deltas usa un formatting binary que no es mucho más grande que el cambio real en el tamaño del repository. Si reemplaza el paso 1 con un volcado que solo agrega un file pequeño, su rsync se comportará bien.

Tengo un script de shell que automatiza la búsqueda de la copy de security y la última revisión y crea el file adecuado, si lo desea.