Festplatte Klonen um Zeit bei der Syncronisierung einer neuen Full-Node zu sparen?

Hallo, irgendwann kommt sicher der Moment in denen die Blockchain zu groß wird für ihre aktuelle Festplatte, als frage ich mich ob es möglich ist die alte Festplatte auf die neue Festplatte zu klonen was schneller geht als die Blockchain erneut komplett auf die neue Festplatte zu laden.

Könnte man dies tun oder führt kein Weg am erneuten laden vorbei ?

Ja, das geht sogar sehr einfach. Du könntest es auch ohne klonen machen und nur die Blockchain selbst kopieren.
Ich habe das bereits mit Umbrel und dem RaspiBlitz gemacht.

Ich vermute stark, @BsxXde würde gerne wissen, wie es funktioniert :grin:

Wäre auch interessiert, welche Daten kopiert werden müssen.
Ich vermute mal die Ordner

blocks
chainstate
indexes

kopieren.

Reicht das ?
Sind bei mir 545 GByte
Oder muss das nach dem kopieren nochmal indexiert werden ?

VG

Die Festplatte muss nicht kopiert sondert geklont werden. Ein kopieren reicht nicht.

Die Festplatten einfach via USB an den PC hängen und eine kostenlose Software z.B. von Chip.de installieren und dann alles von einer Platte auf die Andere CLONEN

Hi, bei mir bringt clonen nicht viel, hab jetzt ja ein komplett anderes System und will nur die BLOCKCHAIN von einem System zum anderen kopieren.
Weisst du wie das geht ?
VG

@Soapp

Nein, kann ich nicht beantworten wie es zwischen 2 verschiedenen Systemen aussehen muss.

Ja genau, diese 3 Ordner brauchst du.

Ich bin mir aber nicht mehr ganz sicher, ob du nicht die Dateien in dem diese 3 Ordner liegen, auch noch benötigst. Also z.B. „anchors.dat“, „mempool.dat“

Dann müsstest du alles haben, was du benötigst, um die Blockchain nicht erneut herunterladen zu müssen.

Hab gestern Nacht noch alle Ordner+Dateien aus dem bitcoin-Ordner auf das neue Gerät kopiert (auch die Dateien die du ansprachst), hatte allerdings noch ein Problem mit dem automatischen Start von bitcoind als service.
Das funktioniert jetzt auch, bitcoin läuft, Tor läuft…
Momentan rödelt er seit einer Stunde vor sich hin und macht: Checking all blk files are present…

VG

Für alle die es interessiert:

Transferability

The database files in the „blocks“ and „chainstate“ directories are cross-platform, and can be copied between different installations. These files, known collectively as a node’s „block database“, represent all of the information downloaded by a node during the syncing process. In other words, if you copy installation A’s block database into installation B, installation B will then have the same syncing percentage as installation A. This is usually ‚‚far‘‘ faster than doing the normal initial sync over again. However, when you copy someone’s database in this way, you are trusting them ‚‘‚absolutely‘‚‘. Bitcoin Core treats its block database files as 100% accurate and trustworthy, whereas during the normal initial sync it treats each block offered by a peer as invalid until proven otherwise. If an attacker is able to modify your block database files, then they can do all sorts of evil things which could cause you to lose bitcoins. Therefore, you should only copy block databases from Bitcoin installations under your personal control, and only over a secure connection.

Each node has a unique block database, and all of the files are highly connected. So if you copy just a few files from one installation’s „blocks“ or „chainstate“ directories into another installation, this will almost certainly cause the second node to crash or get stuck at some random point in the future. If you want to copy a block database from one installation to another, you have to delete the old database and copy ‚‚all‘‘ of the files at once. Both nodes have to be shut down while copying.

Only the file with the highest number in the „blocks“ directory is ever written to. The earlier files will never change. Also, when these blk*.dat files are accessed, they are usually accessed in a highly sequential manner. Therefore, it’s possible to symlink the „blocks“ directory or some subset of the blk*.dat files individually onto a magnetic storage drive without much loss in performance (see Splitting the data directory), and if two installations start out with identical block databases (due to the copying described previously), subsequent runs of rsync will be very efficient.

2 „Gefällt mir“