J'ai configuré un cron pour faire une sauvegarde de mon repo SVN( 8 GB) sur un autre serveur. Mais parfois j'obtiens des erreurs et je pense que ce n'est pas la bonne façon de sauvegarder un svn sur un serveur distant.
J'ai utilisé la commande rsync -avz myrepo.
Veuillez me suggérer un bon moyen de faire une sauvegarde svn sur un serveur distant. Je ne peux pas zipper les fichiers et les transférer quotidiennement car ils font 7 Go.
Merci
Resumen: rsync devrait convenir parfaitement à la sauvegarde d'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 référentiel actif, ce qui est problématique.
Détail :
Vous ne dites pas quelles erreurs sont signalées, ce qui rend toute tentative de diagnostic difficile. C'est une chose pour laquelle je me plains régulièrement de nos utilisateurs - si une application vous donne un message spécifique signalez ce message spécifique aux personnes à qui vous demandez un diagnostic ou une assistance. même si le message est en fait "une erreur est survenue" ou un message similaire (comme cela arrive).
Je suppose que les problèmes signalés sont liés à des fichiers manquants (ils étaient présents lors de l'analyse initiale mais 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.
Bloquer tous les accès au référentiel pendant l'exécution de la sauvegarde peut ne pas être une option pour vous, même si elle est effectuée 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
Utilice hot-backup.py pour faire une sauvegarde complète du référentiel pendant qu'il est en direct comme 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. Cela ne conviendra pas directement pour votre sauvegarde à distance, car le repo complet sera envoyé sur la ligne à chaque fois, mais vous pouvez effectuer la sauvegarde sur une zone locale temporaire et exécuter la procédure 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 aquí y aquí par exemple la documentation de la technique. Cela signifie qu'il faut arrêter l'accès au service SNV pendant un court instant, le temps que l'instantané soit créé, 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 -mais elle n'est pas disponible pour vous sans un gros travail et un apprentissage supplémentaires, à 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 ne soit très volumineux. très L'activité et les performances reviendront de toute façon à la normale à la fin de l'exécution de la sauvegarde lorsque vous abandonnerez le snapshot.
En 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émentielles 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émentielles pour construire une copie complète du repo à l'autre bout (plutôt que de simplement stocker les informations incrémentielles). 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 à la sauvegarde d'un dépôt svn (comme beaucoup d'autres techniques, mais je suis plutôt fan de rsync dans la plupart des cas d'utilisation moi-même) tant que vous ne sauvegardez pas un dépôt qui est actuellement actif. - vous devez arrêter le service ou faire une sauvegarde à partir d'une forme de snapshot.
Copier directement un dépôt svn vivant n'est jamais une bonne idée.
Vous pourriez vous pencher sur svnadmin dump --incremental dans un dossier et rsync cela. De cette façon, vous n'aurez à transférer que les incréments.
Une alternative est svnadmin hotcopy qui fait une copie identique du dépôt en ligne, et vous rsynchronisez le tout.
Vous pouvez sauvegarder en direct un dépôt SVN actif, également avec rsync, à condition que :
Il est également inutile de copier le contenu du sous-répertoire transactions/, car la transaction en cours ne peut être copiée de manière fiable.
Le référentiel copié de cette façon sera cohérent et contiendra les données jusqu'au dernier commit avant la copie du fichier db/current.
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
