Je recommande d'abord d'installer une instance de SVN 1.7.0 sur le nouveau serveur. Ensuite, vous pouvez commencer à copier toutes les informations stockées dans votre ancien référentiel SVN vers le nouveau.
Comme l'explique David Spillet sur ce site réponse , rsync devrait parfaitement convenir pour sauvegarder / copier un dépôt svn, tant que vous ne sauvegardez pas un dépôt qui est actuellement actif. Je soupçonne que vous essayez de sauvegarder un dépôt actif, ce qui est problématique.
Je suppose que les problèmes signalés sont liés à des fichiers manquants (ils étaient présents lors de l'analyse initiale mais ont été déplacés/renommés/supprimés avant que la sauvegarde ne soit terminée), verrouillés ou apparemment modifiés pendant que rsync les lisait. Vous verrez des erreurs similaires (ou bien pire : des problèmes liés mais non signalés) avec la plupart des techniques de sauvegarde si vous sauvegardez un service svn actif et que vous n'arrêtez pas complètement le service svn avant de lancer la sauvegarde.
Arrêter tout accès au référentiel pendant l'exécution de la sauvegarde peut ne pas être une option pour vous, même si cela est fait en pleine nuit (car vous pouvez avoir des développeurs distants qui travaillent à des heures différentes). Si c'est le cas, il existe quelques options, dont les suivantes
-
Utilisez hot-backup.py pour faire une sauvegarde complète du référentiel pendant qu'il est en direct en tant que décrit dans cette section de la version librement disponible Contrôle de version avec Subversion qui est généralement considéré comme une lecture recommandée. Cette méthode ne conviendra pas directement à votre sauvegarde à distance, car elle entraînera l'envoi du repo complet sur la ligne à chaque fois, mais vous pouvez effectuer la sauvegarde sur une zone locale temporaire et exécuter l'opération suivante rsync (ou quoi que ce soit d'autre) basé sur cette sauvegarde plutôt que sur le référentiel actif.
-
Si vous êtes sous Linux et que vous utilisez LVM pour le partitionnement de vos disques, vous pouvez utiliser la fonction snapshot de LVM pour réaliser un exploit similaire à celui décrit dans l'option 1. Voir ici et ici pour des exemples de documentation de cette technique. Cela implique l'arrêt de l'accès au service SNV pendant un court moment, le temps de la création de l'instantané, mais c'est presque instantané et donc beaucoup moins susceptible d'être un problème que de devoir l'arrêter pendant toute l'opération de sauvegarde.
-
Utilisez les sauvegardes incrémentielles du dépôt actif, également mentionnées dans le livre SVN ci-dessus.
La technique LVM sera plus rapide que hot-backup.py -then-sync, mais n'est pas disponible pour vous sans une bonne dose de travail supplémentaire et d'apprentissage, à moins que vous n'utilisiez déjà et ne soyez familier avec LVM. Ses avantages sont qu'il sera presque certainement beaucoup plus rapide et qu'il utilisera moins d'espace disque (bien que l'espace disque soit plutôt bon marché de nos jours). Les instantanés LVM affectent les performances d'écriture lorsqu'ils sont présents, mais il est peu probable que la différence soit perceptible à moins que votre référentiel soit très très occupé et les performances reviendront de toute façon à la normale à la fin de la sauvegarde lorsque vous abandonnerez l'instantané.
Le site hot-backup.py Si vous stockez la version "hot copy" sur une autre machine, vous pouvez la restaurer beaucoup plus rapidement que la copie distante si la machine principale meurt dans un événement qui n'affecte pas l'autre (une panne de contrôleur de disque, par exemple). Il est également probable que cette solution soit plus simple à mettre en œuvre, à moins que vous n'utilisiez déjà LVM et que vous soyez familier avec cette technologie.
Les sauvegardes incrémentales seront plus rapides que ces deux techniques, mais moins simples que le hotcopy-then-sync et la restauration après un désastre complet est potentiellement plus complexe à moins que vous n'utilisiez les sauvegardes incrémentales pour construire une copie complète du repo à l'autre bout (plutôt que de simplement stocker les informations incrémentales). La reconstruction du repo à l'autre bout est recommandée de toute façon, car c'est un moyen de tester que votre sauvegarde est en fait valide - même avec les autres techniques, vous devriez tester vos sauvegardes régulièrement (mantra : une sauvegarde n'est pas une bonne sauvegarde si elle n'a pas été testée).
En résumé, rsync devrait parfaitement convenir pour sauvegarder ou copier un dépôt svn tant que vous ne sauvegardez pas un dépôt qui est actuellement actif - vous devez arrêter le service ou sauvegarder à partir d'une forme d'instantané.
N'oubliez jamais de tester si tout va bien en comparant les informations dans les deux dépôts SVN, en utilisant les options de relocalisation, en vérifiant les fichiers journaux, etc.
