Hallo Allerseits, für alle meine Projekte habe ich ein subversion-Repository auf einem kleinen Server eingerichtet. Neulich bekam ich beim frischen Auschecken eines Projektes eine seltsame Fehlermeldung, dass eine Datei nicht gefunden werden konnte. 'svnadmin verify <PROJEKT>' gab mir den Hinweis, dass eine Revisionsdatei keine Leerzeile am Dateiende besitzt. Als ich diese Datei (Revision 16 von 30 Revisionen, also mittendrin :( ) geöffnet habe, fiel mir auf, dass sich deren Inhalt von dem der anderen Revisionsdateien unterscheidet - hier war nur unleserlicher Binärkram enthalten. Von daher gehe ich aus, dass diese Datei defekt ist. Gibt es einen Weg, dieses zu reparieren?
Nachtrag: ich habe noch eine komplette Arbeitskopie dieses Repositories auf einem anderen Rechner - könnte ich evtl. daraus die korrupte Revisionsdatei neu generieren?
>hier war nur unleserlicher Binärkram enthalten. Von >daher gehe ich aus, dass diese Datei defekt ist. Die anderen waren lesbar? Ich dachte, SVN komprimiert... Wenn deine aufgezeichnete Änderung eine Binärdatei betroffen hat, so wird der Inhalt der Rivisionsdatei wohl auch binär sein. - Kannst du eine alte Revision auschecken? - Hast du mal nach der exakten Fehlermeldung im Web gesucht? - Bietet svn admin keine repair-Funktionen an? Ich habe selbst mit SVN noch nicht so viel gemacht... Gruß Kai
Du hast Recht: in allen Revisionsdateien sind unleserliche Stellen enthalten, nur zum Dateiende hin sind sind die Einträge wieder lesbar - in der korrupten Datei jedoch nicht. - Ich kann alle Teilprojekte bis Revision 15 auschecken, ein Projekt lässt sich sogar bis Revision 30 updaten. - Ja, ich habe aber noch nichts Brauchbares gesehen - Ich habe keine gefunden
Die Doku ist da ziemlich eindeutig: "that means that your repository has at least one corrupted revision and you should restore the corrupted revision from a backup (you did make a backup, didn't you?)." Auch wenn dir das nicht gefallen wird. Mach erstmal ein Backup von deinem defekten Repository () und versuch dann mal alle Revisionen ab und inklusive der defekten zu löschen. Und check dann deine working copy ein. Wenn das klappt (verify) hast du nur ein paar Revisionen verloren. Ist aber nicht vorgesehen und ich habe keine Ahnung, ob das für Langzeitschäden sorgt! Du wirst dem evtl irgendwie nach dem Löschen noch mitteilen, dass die aktuelle Revision eine andere ist. Zur Not: alles löschen und neu einchecken. Backup beschrieben in: http://svnbook.red-bean.com/en/1.4/svn-book.html#svn.reposadmin.maint.backup
Hmm, über eine vernünftige Backup-Strategie habe ich natürlich bis jetzt noch nicht nachgedacht... Danke für Deine Hinweise!
Nachdem mir nun bewusst ist, dass ich eine Backup-Lösung für meine Repositories brauche, stellt sich die Frage, wie man dieses effektiv angeht? Aus meiner Sicht müsste das Archiv über eine Historie verfügen, damit sich auch Probleme, die in der Vergangenheit liegen, beheben lassen. Andererseits möchte ich ungern jedesmal einen 'full dump' machen. Da ich mich mit meinen Basteleien ausschliesslich im Hobby-Bereich bewege, brauche ich keine Multi-k€ Backuplösung mit X redundanten Servern. Wie wird das von Euch gehandhabt? Einige Leute verwenden rsync, andere inkrementelle tar-Archive... Wie sind so die Erfahrungen mit rsync / tar?
Externe Platte am Linux-Server und folgende Scripts: Datei: backup-daily
1 | ./backup /mount/backup/daily/`date +%u-%A` |
Datei: backup-monthly
1 | ./backup /mount/backup/monthly/`date +%m-%B` |
Datei: backup
1 | rm -rf /tmp/backup |
2 | |
3 | mkdirhier /tmp/backup/svn-myproject |
4 | cd /tmp/backup/svn-myproject |
5 | svnadmin hotcopy /var/svn/myproject . |
6 | tar -czf $1/svn-myproject.tar.gz * |
7 | |
8 | rm -rf /tmp/backup |
backup-daily wird täglich aufgerufen und backup-monthly monatlich (soll es zumindest mal, wenn ich die Berechtigungen hingekriegt habe - im Moment starte ich die manuell). Die Platte muss insgesamt 7+12 = 19 Vollbackups fassen. tar kann aber auch inkrementell arbeiten, das ist wahrscheinlich das, was du suchst. Restore testen nicht vergessen. Keine Garantie für gar nichts - bin selber noch am lernen ;)
Benutze kein SVN, sondern GIT, aber: Die mit GnuPG verschlüsselten Repository-Backups brenne ich auf CD. Source-Code ist zu wertvoll. Der GnuPG-Archiv-Key ist übrigens an verschiedene Stellen hinterlegt (verschiedene Ortschaften!). Der Vorteil der gebrannten CDs ist mehrfach: - Kann nicht ausversehen gelöscht werden. - Kann nicht durch Überspannung zerstört werden. - CDs können auch in Bankschließfächern verwahrt werden. D.h. die Hütte kann sogar abbrennen, und ich kann meine (u.a.) Source-Codes wieder restaurieren. Das beruhigt die Nerven ungemein. So ein Bankschließfach kostet auch nicht die Welt, und die CD-Rohlinge erst recht nicht.
Hi denk aber daran das die Haltbarkeit von CDs (insbesondere von CD-R(W)) nicht so prickelnd ist. Wenn du ältere Backups (>1 Jahr) noch brauchst würde ich die einmal im Jahr auf einen neuen Rohling brennen. Matthias
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.