I have a much larger partition that can hold all the files and more, so I started a cp -R
That copies recursively all the files using the built in operating system (debian VPS)
So far, nothing that crazy. But due to the number of GB and files it was taking a while, so I decided to start an iguana sync from scratch. I havent done a BTC sync from scratch for a few months as it is not exactly a fast process, even on my fast VPS that has a 1gbps connection that can sustain 100MB/sec transfers.
I have slowed down the iguana processing a bit as most users dont have such fast connections so it is sustaining about 30MB/sec or 200mbits/sec which is within the possibility for a home connection. But it used to be 100MB/sec and faster during peaks, so a bit strange why it is so slow.
as I write this, the copy just finished and using the same disk for the copy and parallel sync is really not a good idea, but still the iguana has made decent progress:
BTC.RT0 u.0+c.0 b.0 v.0 (0+1253/2000 1st.170).s0 to 176 N[213] h.425653 r.344503 c.340000 s.344520 d.1 E.169 maxB.6 peers.21/64 Q.(3070 0) (L.425653 212:1653) M.425652 000000000000000001ec532cf96c58ffeb6a5886f232c9c5078f870b47a3bfe2 ledger.00000000 bQ.2499 0:29:54 stuck.0 max.43
169 bundles are already saved, out of 212, so around 340K blocks after 30 minutes. I just realized that I ran the minimal config version with max 64 peers, which is why it is so slow. For best speed better to have max peers at 512 and let it connect and optimize 128+ of them.
I was wondering why the bandwidth was so much lower than before. Anyway, looks like it still needs more time to finish and I dont want to restart it with a better config as it is already at 171 bundles. i will post a comment with the final completion stats. Keep in mind it should be going 50% to 100% faster if I ran it using the fast config.
James