Peu importe comment je suis arrivé ici, je suis en mesure de restaurer un dépôt SVN à partir de la sauvegarde. Malheureusement, la sauvegarde a été légèrement corrompue et sur plus de 19000 révisions, environ 80 sont perdues. La sauvegarde était un fichier bzip2 et j'ai pu utiliser bzip2recover pour récupérer environ 99% des blocs. Ce sont des «biens connus» puisqu'ils se sont décompressés avec succès. Par conséquent, j'ai été en mesure de créer une liste des validations connues et des validations perdues.svn récupération - restauration des révisions individuelles
Le référentiel d'origine était également endommagé, mais de nombreux fichiers ont survécu. Malheureusement, le référentiel dans son ensemble est cassé. J'ai donc la chance d'avoir les fichiers des répertoires db/revs et db/revprops d'origine pour ces révisions manquantes. Les chances sont que la corruption du fichier de sauvegarde bz2 ne s'aligne pas avec la corruption des fichiers db/revs.
J'ai reconstruit tout jusqu'à r13892, mais je sais que r13893 est corrompu, donc je n'ai pas de sauvegarde pour r13893. J'ai les fichiers db/revs/13893 et db/revprops/13893 du dépôt d'origine.
J'ai créé et reconstruit le référentiel avec svn-1.4, mais j'ai migré vers svn-1.6 pour pouvoir utiliser la commande svnadmin verify sélective (sur une seule ou plusieurs plages de validation).
Je pensais peut-être que je pourrais déposer ces deux fichiers dans le nouveau référentiel, mettre à jour db/current [1], puis continuer. Cependant quand j'essaye de vérifier que j'obtiens cette erreur:
$ svnadmin verify new-svn
* Verified revision 1.
...
* Verified revision 13889.
* Verified revision 13890.
* Verified revision 13891.
* Verified revision 13892.
svnadmin: Can't read file 'svn/db/revs/13214': End of file found
Ainsi ceci évidemment n'a pas fonctionné. Je ne sais pas ce que 13214 a à voir avec quoi que ce soit ici.
Je suis revenu à svn-1.4.6 juste au cas où quelque chose d'étrange se produirait avec 1.6. Malheureusement, je reçois le même résultat - révision 13893 ne vérifie pas:
...
* Verified revision 13891.
* Verified revision 13892. svnadmin: Can't read file 'svn/db/revs/13214':
End of file found
Alors, voici ce que je sais:
- Je sais que les révisions 1-13892 sont 100% correct (à moins que, par hasard, extrêmement improbable un bloc bz2 a été décomprimé incorrectement mais a passé la somme de contrôle).
- Je ne sais pas si les fichiers r13893 du dépôt SVN original sont corrects - ils peuvent être corrompus, mais la quantité de corruption est si petite qu'elle est peu probable (mais possible).
Est-ce que quelqu'un a des idées sur la façon dont je pourrais combler ce trou? Notez que j'ai un r13894 100% confiant en ma possession, donc si je peux obtenir r13893 branché je peux continuer avec le reste de la restauration.
[1] Je mis à jour db/courant avec ce script: http://svn.haxx.se/users/archive-2005-12/att-0630/make-current-fix.py
Je l'ai testé cela sur d'autres dépôts SVN (! Après la désactivation de l'écriture à db/courant) pour vérifier qu'il produisait la même valeur comme cela déjà là. Cela fait.
Oui, en haut de r13893 il est dit: DELTA 13214 0 12567271 Il est donc un delta au-dessus de 13214, ce qui explique d'où ça vient de. Une chose que je remarque est que mon binaire reconstruit engage (en db/régime moteur) commencer par ceci: SVN^A^@^@<86>^@ Et mon r13893 d'origine commettras ressemble à ceci: SVN^@^@<86>^@ Notez que le premier octet après "SVN" est^@ (00) dans l'ancienne validation, mais^A (01) dans les nouveaux validations. Est-ce un numéro de version xdelta? Peut-être que j'ai besoin de reconstruire 1 à 13892 avec une version de subversion qui utilise le même format xdelta? –
meowsqueak
Je ne connais pas le^@ vs^A. Mais lors du chargement de la sauvegarde, il devrait vous dire quel était le numéro de rev original et quel était le numéro de rev nouvellement créé. Est-ce que ces deux chiffres correspondent? – retracile
Oui, ces chiffres correspondent. J'ai résolu ce problème en fait - c'était parce que j'avais créé le nouveau repo avec 1.4, mais les anciens fichiers ont été créés avec 1.3, donc le format xdelta était différent. J'ai recommencé avec svn-1.3 et ce problème est maintenant résolu. Malheureusement svnadmin segfaults plus tard, donc tout n'est pas très bien ... – meowsqueak