Auparavant, nous sauvegardions chaque nuit notre dump SVN complet, mais le référentiel est devenu trop volumineux.
Si j'étais prêt à couper l'historique des révisions à disons 2 semaines, comment pourrais-je faire un script batch pour effectuer ce dump ?
Je réalise svnadmin dump peut prendre une plage de révision, mais je ne suis pas sûr de savoir comment écrire un script pour obtenir le numéro de révision correspondant à un moment dans le passé, par exemple il y a 14 jours.
Le texte d'aide ne le montre pas, mais vous pouvez spécifier une plage de révision en utilisant des dates ou quelques mots-clés, de la même manière qu'avec la commande normale svn les commandes. Pour vider commits du mois précédent jusqu'au HEAD actuel :
svnadmin dump /path/to/repo/ -r {2011-05-20}:HEAD > /path/to/dumpfileGardez à l'esprit que cette méthode signifie que vous devez vous assurer que vos instantanés capturent chaque révision et ne se chevauchent pas, puisque les fichiers dump ne contiennent pas d'informations explicites sur la numérotation des révisions. La méthode de restauration de svnadmin load va simplement rejouer et renuméroter vos révisions s'il y a des manques ou des chevauchements.
Je dois mentionner svnadmin hotcopy comme option de sauvegarde, car ils sont beaucoup plus rapides que les dumps. (Vous pouvez effectuer des vidages réguliers, hors ligne, à partir de la copie à chaud si les vidages de texte sont ce dont vous avez besoin).
Merci, très utile. Je pense que je vais aussi opter pour l'option hotcopy, je ne me souviens plus pourquoi je l'avais rejetée auparavant.
Quand je suis passé à hotcpy, les seuls inconvénients que j'ai pu voir étaient que 1 : la BD était un format propriétaire au lieu d'un dump en texte clair, donc potentiellement plus difficile à récupérer. (Bien que je compressais les dums, de toute façon.) et 2 : la restauration nécessitait la même version de svn que celle utilisée pour créer la hotcopie (ce que je ne voyais pas comme étant trop difficile à gérer, puisque nous ne faisions pas de mises à jour si fréquentes.). Les gains de temps étaient trop importants pour être ignorés (les sauvegardes étaient de ~30 minutes au lieu de ~5 heures)
Lancer une série de révisions comme ça ne fonctionne pas. Voir les problèmes décrits ici : serverfault.com/questions/895315/ Il semble également être extrêmement lent.
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.
