¿Es 'hotcopy' suficiente para las copias de seguridad SVN o debería preocuparme por los volcados completos e incrementales?

Question

Para mis cosas personales solo uso el comando svnadmin hotcopy una vez por semana, pero para más repositorios de misión crítica que incluyen muchos desarrolladores, ¿es suficiente? ¿O debería dedicar el tiempo necesario para armar una estrategia de copia de seguridad más rigurosa que incluya copias de seguridad completas y copias de seguridad incrementales?

hotcopy parece la forma más fácil de hacerlo, pero quiero poder restaurar un repositorio si, por alguna razón, se daña. ¿Solo haré un volcado a través de hotcopy, permítanme hacer esto?

Answer 1

¿Le preocupa la copia rápida o le preocupa hacer una copia de seguridad solo una vez a la semana?

Hotcopy producirá una copia de seguridad segura y completa de su repositorio, incluso si otros procesos (sus desarrolladores, por ejemplo) acceden al repositorio al mismo tiempo. Si aún no confía en él, cierre todos los accesos al repositorio y haga una copia de seguridad copiándolo en alguna parte con las herramientas habituales del sistema de archivos. (Los desarrolladores no van a trabajar día y noche, ¿o sí?)

Si le preocupa la parte de una vez a la semana: solo piense en lo que sucederá si el repositorio desaparece el día anterior a la siguiente copia de seguridad. programado. ¿Importa? En caso afirmativo, realice copias de seguridad con más frecuencia. Es así de simple.

¿Su repositorio es demasiado grande para guardar varios días o semanas de copias de seguridad completas? Implemente un esquema de respaldo rotativo que use copias de respaldo completas e incrementales. ¿Tienes suficiente espacio para copias de seguridad? Ahórrese el problema y haga copias de seguridad completas.

Answer 2

Tuve mala suerte en el pasado solo con copias en caliente. Si se trata de un código que se actualiza y se compromete muchas veces a lo largo del día, podría valer la pena una estrategia de copia de seguridad más profunda.

Answer 3

he implementado un plan de contingencia para el repositorio SVN 1.4.x de una empresa (con sede en Windows en el momento), haciendo uso de la escritura pythonsvn-backup-dumps.py

invoco svn-backup-dump.py de un gancho post-commit para activar las copias de seguridad incrementales para una revisión específica. Usé schtasks para programar una copia de seguridad "completa" semanal con el mismo script.

La recuperación (que hemos tenido que hacer dos veces debido a la eliminación de un directorio en el repositorio) es relativamente simple: obtenga la copia de seguridad completa más reciente, restaure. Aplicar incrementales hasta la última revisión.

No he investigado las mejoras/cambios para 1.5 en esta área, pero creo que un plan similar funcionaría bien para usted.

Answer 4

Otra buena estrategia es mantener un segundo repositorio SVN y sincronizarlo con el principal con svnsync, generalmente con un enganche post-commit.

La principal ventaja es que si el primer repositorio se cae por alguna razón, puede cambiar inmediatamente al de copia de seguridad y seguir trabajando sin tiempo de inactividad.

Answer 5

Si copia un repo dañado en la parte superior de la copia de seguridad no corrompida anteriormente, entonces sí, perderá la copia de seguridad no corrompida.

Si le preocupa esto, entonces, como han dicho otros, debe rotar las copias de seguridad.

También podría organizar la ejecución de 'svnadmin verify' automáticamente también.

Answer 6

Llámame old school, pero ¿qué pasa con la creación de versiones de una partición y luego la aparición de imágenes fantasma en un horario?

La opción svnsync sugerida por Davide Gualano también suena bien. Me inclino por esta opción para evitar la partición innecesaria de mis discos (esto también puede perjudicar a otros administradores de forma incorrecta y no tener sentido en algunos de mis entornos de VPS).

adición

He estado usando el svnadmin 'volcar' mandar mucho últimamente. Esto funciona muy parecido al comando de volcado mysql, ya que exporta su repositorio en los comandos de creación de bak. Este comando podría implementarse como crontab/tarea programada y luego copiarse a una unidad externa como un archivo. Ejemplos de comandos:

svnadmin dump c:\svn\project > c:\dumps\project.bak 

svnadmin load c:\svn\project < c:\dumps\project.bak 

A continuación, utilice robocopy/que copiar herramienta de elección para mover el archivo a otra ubicación. Esto es útil si desea mover los archivos completamente fuera del servidor de repositorio, pero no hay acceso externo a la subversión.

Todavía no he llegado a un arte. Cuando muevo estos archivos entre máquinas, de vez en cuando obtengo algo como 'UUID mismatch'. He estado resolviendo esto eliminando/submarcando la carpeta del proyecto, luego usando:

svnadmin create c:\svn\project 

svnadmin load c:\svn\project < c:\dumps\project.bak 

Esto debería eliminar el error. Es posible que necesite volver a crear o restaurar enlaces con Eclipse u otros proyectos. Si el UUID está roto, puede afectar a otras personas que usan el proyecto también, por lo que debería ser una consideración.

Puede utilizar este método como respaldo para Hotcopy. Entre ellos, deberías poder volver a almacenar el repositorio.

P.S. Ken, parece que svn-backup-dumps.py ha sido movido aquí: http://svn.apache.org/repos/asf/subversion/trunk/tools/server-side/svn-backup-dumps.py