Topic: Git fuer blockchain backup, macht das Sinn? (Read 838 times)

Danke fuer das Angebot :-). Wie gesagt, das scheint jetzt zu funktionieren sodass ich nicht aufs Internet angewiesen bin (>10 GB als download sind fuer mich ein bischen viel). Ausserdem brauch ich ja noch diverse andere Chains  .

Nichtsdestotrotz, ich glaube fuer alle die gerade einsteigen und die Blockchain runterladen muessen und keinen Server bei sich daheim rumstehen haben waere dieser Link von Vorteil. Kannste Dir ja in die Signatur packen.

Ich habe das auf einem meiner Server implementiert. Dort wird jede Nacht eine Bootstrap.dat erzeugt und zwar bis zum letzten aktuellen Block. - Das dauert rund 1,5 Std und erzeugt derzeit eine 19 GB Datei. - Diese wird dann als RAR gepackt und kann heruntergelden werden.

Wenn der Client kaputt ist einfach die aktuelle Bootstrap.dat runterladen, in's Verzeichnis und schon ist alles wieder da. Man muss maximal die letzten 24 Std. neu synchen.

Bei Bedarf kann ich hier den Link posten. - Läuft übrigens als Pyhton-Scrypt auf einen Windows 2008 R2 Server und ist mit 1GB angebunden.

Gruss Carsten.

EDIT: Wenn Du mit Pyhton umgehen kannst kann ich Dir auch das Script zur Verfügung stellen, dann kannst Du die Bootstrap.dat lokal erzeugen.

(i) Weil ich nicht wusste, dass es sowas gibt und muss mich da nun erstmal einlesen. Bin da bestimmt nicht der Einzige.

(ii) Ausserdem, der Vorteil eines Repositories ist folgender: Ich koennte z.B. auch rsync benutzen um ein Backup zuerstellen und dies habe ich auch schon erfolglos versucht. D.h. ich oeffne die Wallet, der Blockchainsync laeuft fehlerfrei durch, ich schliesse die Wallet und erstelle mein Backup. Das Problem hierbei ist, dass meistens, obwohl alles auf den ersten Blick fehlerfrei durchgelaufen ist, beim Neustart ein Fehler in der Blockchain mockiert wird. D.h. die Blockchain war schon vor dem letzen Backup im Arsch und ist ueber dieses auch nicht mehr wiederherstellbar da die fehlerhafte Datei im Backup ist. Per Git-Repository kann ich aber nun auf das vorletzte Backup zugreifen. Dieses hatte damals funktioniert, da vorletztes Backup, und muss folglich auch jetzt ausgecheckt funktionieren.

Demnach sind alle Backupvarianten welche nur den letzen Punkt in der Versionshistory wiederherstellen koennen wertlos!

(iii) Ich fuehre mein Backup taeglich und automatisch durch damit der Abstand zum aktuellen Block mglst gering ist und ich mglst wenig Arbeit habe bzw faul sein kann und mich nicht aktiv kuemmern muss. K.a. wie gross die Bootstrap.dat ist, aber ich moechte die nicht 10-fach rumliegen haben. Schon weil meine Partition nicht uebermaessig gross ist. Der Git-Ordner ist zwar auch nicht grad klein, aber insgesamt rechne ich grob mit dem doppelten Platzverbrauch.

Ähm, mal ne bescheidene Frage: Warum erstellst Du nicht einfach regelmässig eine Bootstrap.dat ?

Gruss Carsten.

Noja, die oben angegebene Methode funktioniert ja nun zu meiner Zufriedenheit.

Trotzdem, irgendwas ist an den Wallets noch nicht ausgereift: Dienstag ging Bitcoin kaputt, Samstag Litecoin (Fehler das Datei nicht lesbar waere) und heute Namecoin (irgendne Exception). Ich werde wohl nun mal beginnen die Fehlermeldungen genauer zu protokollieren ...

Die letzten Beiden waren aber flux wiederhergestellt  .

Aber wie gesagt, die Distri ist nicht alltaeglich und die Daten liegen verschluesselt (cryptsetup) auf einem externen Datentraeger.

http://www.rsnapshot.org/

Vermutlich syncst du da die Datenbankindices auch mit, und das ist nicht so sehr zu empfehlen, besonders wenn inzwischen noch ein Block gefunden wird.

Mein Tipp:
Was auch immer du da treibst - lass es bleiben.

Die zweite Methode funktioniert auch. Ist natuerlich einfacher durchzufuehren.

Gestern hat er mir schon wieder ne blockchain zerhauen ... jedesmal scheinbar ein anderer Coin  .

Obs an der Distribution liegt?

So, Neuigkeiten von der git-Front. Also die obere Methode funktioniert auch nicht. So praktisch git ist, so mies ist die Beschreibung im Netz.

Wie auch immer, was diesmal zu funktionieren scheint ist:


Meine Vermutung ist, dass meine vorherige Methode die aktuelle Version mit der vorletzten Version gemischt bzw ueberschrieben hat. Was auch funktionieren koennte ist folgendes (habe ich aber nicht getestet es erscheint aber logisch):

Eine weitere Alternative - wenn man z.B. Rechner zur Verfuegung hat die staendig laufen (auf Arbeit/Uni u.ae.) - waere es, dort die Chain-Dienste laufen zu lassen. Die fressen ja nicht viel Leistung wenn die Blockchains aktuell sind.

Auf die entsprechenden Verzeichnisse koennte man per sshfs zugreifen. Dann ginge das alles Remote. Ich habe nur keine Ahnung wie lange dann das Laden der Blockchain mit den Clienten dauert.  

Mit git lokal auf einem externen Datentraeger. Also im Prinzip einfach nur


Wobei "git init" natuerlich nur beim ersten Mal durchgefuehrt wird.


Ich synchroniziere die Chains taeglich mit coin-qt um auf Marktaenderungen schnell reagieren zu koennen. Einem Marktplatz ueberlasse ich demnach und nachvollziebarerweise nur ungern meine Coins.

Das Problem ist nun, dass schon desoefteren die Bitcoinchain durcheinander gebracht wurde und das neue Runterladen der gesamten Chain keine Alternative darstellt. Desweiteren scheint insbesondere namecoin-qt in der Beziehung buggy zu sein.

Das ganze laeuft auf einer, wie soll ich sagen, nicht ganz alltaeglichen Linux-Distribution.

Ich habe natuerlich eine Art aelteres Backup auf einem Rechner liegen, welchen ich hochfahren und dann fuer ein paar Tage laufen lassen kann. Der frisst mir aber zuviel Strom und beim Minen kommt mit dem nicht viel rueber. Auch koennte ich die chains per coind kontinuierlich synchronizieren. Habe aber aktuell keine Lust die entsprechenden Wallets auf einem RaspberryPi zu kompilieren. Das ist ja ARM und da gibts nicht so einfach die Binaries fuer.

Mit Git kann ich - bzw. hoffe ich dass ich das kann - die Blockchain wenn fehlerhaft, mit wenig Aufwand wieder auf eine funktionierende Version zurueckdrehen.

warum aber überhaupt Versionen der Blockchain?
also was ist der Sinn dahinter?

wenn man die Blockchain zu einem bestimmten Zeitpunkt haben möchte, kann man ja einfach am ende was löschen.

Git mit Github oder Git mit eigenem Server?

Falls es jmd interessiert, mit gitk habe ich es hinbekommen, dass ich eine alte Blockchainversion wiederherstellen konnte. Zwar werden so scheinbar viele zusaetzliche alte Dateien erzeugt (k.A. warum), aber *coin-qt scheint das wieder aufzuraeumen.

In gitk den entsprechenden alten Commit mit der rechten Maustaste anklicken, dann "zuruecksetzen" auswaehlen und bei den drei verschiedenen Methoden die dritte auswaehlen. Alle juengeren Commits werden so aber geloescht. (Getestet mit der feathercoin-Blockchain und feathercoin-qt)

Wie das per Kommandozeile geht: k.A..

Hallo,

ich spiele gerade mit Git rum um Blockchains zu backupen. Leider haut das nicht hin wie es soll. Wenn ich ein revert mache dann ist die resultierende aeltere Version der Datenbank kaputt.

Kennt sich jmd derart mit Git aus so dass er weiss ob man das korrigieren kann?

Gruss,
cu