¿Cómo puedo hacer una copia de seguridad de un repositorio SVN de 13 GB? El volcado es 100+ GB

Question

Tengo aproximadamente una docena de repositorios que en el sistema de archivos tienen entre 1 GB y 10 GB de tamaño, y necesito configurar copias de seguridad automatizadas para todos ellos (nuestros viejos guiones de respaldo se perdieron cuando una computadora bajó) con nuestras máquinas XP de 64 bits.

Después de leer this question sobre la mejor manera de realizar una copia de seguridad de los repositorios SVN, comencé a descartar el repositorio más grande que tenemos, que es de aproximadamente 13 GB. Este comando se ha estado ejecutando durante ~ 2.5 horas, y actualmente está volcando la revisión ~ 200 de 300+.

svnadmin --deltas \\path\to\repo\folder > \\path\to\backup\folder\dump.svn 

El archivo de volcado es más de 100 GB y cuenta. Sé que puedo 7-zip este lechón, pero 100 GB ?! ... o_O

Los repositorios contienen una gran cantidad de datos binarios, que podrían ser parte del problema, pero a partir de ahora, cambiar a un sistema de control de versiones más eficiente (suponiendo que exista) no es realista; SVN es parte de la vida aquí.

He considerado usar hotcopy, que ocupa mucho menos espacio, pero traté de usar uno de nuestros viejos respaldos copia de seguridad, y subversion 1.7 no pudo encontrar un montón de archivos que necesitaba. Parece que tendría que instalar la versión de SVN que originalmente copiaba en caliente el repositorio, y volcar ese repositorio para ponerlo en un SVN más nuevo. Esta declaración parece verificar el problema que estoy teniendo con hotcopy: http://svn.haxx.se/users/archive-2005-05/0842.shtml

Siento que me acabo de tengo faltando algo. Tal vez hay alguna bandera para el volcado que mágicamente hace el volcado 1/5 del tamaño ...

¿Tengo alguna otra opción?

---

ACTUALIZACIÓN: La última revisión, # 327, acaba de ser abandonada. El tamaño final del archivo de volcado es 127 GB. Eso es de un repositorio de 13.5 GB. Probablemente tengo aproximadamente 3 veces más en todos mis repositorios combinados.

Answer 1

Para la copia de seguridad diaria, diría que realmente no necesita hacer un svnadmin dump. Usaría el método de volcado si estuvieras a punto de transferir el repositorio a un nuevo servidor que puede estar ejecutando una versión SVN y SO diferente ya que es la forma más portátil de volcar el repositorio, pero no es muy eficiente en el uso del espacio.

Recomendaría utilizar los métodos de copia rápida mencionados en ese enlace. Eso garantizará que el estado del sistema de archivos sea coherente, y también copiará los archivos de configuración y los scripts de enlace (por cierto, el volcado svnadmin no los copia, por lo que terminará con una copia de seguridad incompleta). Debido a que es solo una copia directa del repositorio, tiene el mismo tamaño, por lo que la copia de seguridad debería ser mucho más manejable.

En caso de emergencia, si necesita restaurar una copia de seguridad hecha desde una copia rápida, todo lo que necesita es una máquina con la misma versión principal de SVN (por ejemplo, 1.6 o 1.7) y, para estar seguro, el mismo sistema operativo. Usted debería ser capaz de utilizar este repositorio directamente, o puede hacer un svnadmin dump en este punto para transferirlo a un nuevo servidor.

EDIT: comparación de svnsync y hotcopy:

aspectos comunes:

• se ocupa de forma segura con el repositorio escribe durante la copia de seguridad
• Tamaño de copia de seguridad = tamaño del repositorio

Ventajas de copia en caliente:

• más fácil de configurar
• copias de seguridad de los ganchos y los archivos de configuración

Ventajas de svnsync:

• permite a Backup en una máquina diferente
• sólo las nuevas revisiones desde la última sincronización se han escrito para el la sincronización es muy rápida y esto significa que puede hacer copias de seguridad incrementales muy compactas

Answer 2

Gracias a las sugerencias de bahrep y the_mandrill, decidí ir con svnsync para estos repositorios. Pude configurarlo con bastante facilidad, y como no tenemos ningún gancho o archivo de configuración, no hay nada más que respaldar. Debido a los problemas que tuve con la copia en caliente (gracias a the_andrill para proponer una solución a estos problemas) decidí que svnsync sería la solución más simple para nosotros.

Además de lo señalado the_mandrill, svnsync tiene otras ventajas:

• En el caso de que el repositorio principal deja de funcionar, los usuarios pueden descargar desde el repositorio de copia de seguridad, siempre y cuando tengan el enlace.
• Las copias de seguridad están completamente controladas por la versión. Mi jefe me pidió que hiciera copias de seguridad nocturnas, pero solo guarde esas copias de seguridad que tienen una semana de antigüedad. Para hacer eso con una copia en caliente, tendría que escribir un guión. Con svnsync, no tengo que preocuparme por nada de eso.

Para configurar svnsync, tuve que completar los siguientes pasos. Disculpe cualquier error tipográfico. Todos nuestros repositorios están alojados usando el Servidor VisualSVN.

1. Crear un nuevo repositorio, vacío:

   svnadmin create \\computerB\C$\repositories\mirror

2. crear el archivo, \mirror\hooks\pre-revprop-change.bat.Es sólo los contenidos es ésta una línea:

   exit 0

3. inicializar la sincronización

   svnsync init https://computerB.domain.net/svn/mirror https://computerA.domain.net/svn/repo

4. sincronizar los dos repositorios

   svnsync synchronize https://computerB.domain.net/svn/mirror https://computerA.domain.net/svn/repo

Answer 3

A partir de VisualSVN Server 3.6, puede usar Backup-SvnRepository cmdlet de PowerShell para realizar una copia de seguridad del repositorio de Subversion. Para restaurar el repositorio desde la copia de seguridad, use Restore-SvnRepository cmdlet.

Además, la Edición Enterprise del servidor ofrece un scheduled backup feature. La copia de seguridad programada incorporada supports several backup types including incremental backups que es eficiente en términos de espacio de almacenamiento y tiempo necesarios para realizar la copia de seguridad.