Parity-ethereum: Moving cloud-providers

[mewwts]

• Parity Ethereum version: 2.1.6
• Operating system: Linux
• Installation: one-line installer
• Fully synchronized: yes
• Network: ethereum
• Restarted: yes

Hi Parity,

I'm moving my full archival Parity nodes from GCP to Digital Ocean, and was wondering if you could provide some quick guidance. I have a directory, say parity-data on an externally mounted ssd which I use with the -d flag on parity.

I've created a snapshot of the disk, created a new instance and mounted the snapshot as a disk on the new instance - all this in GCP. I've also created an instance / droplet on digital ocean and attached a sufficiently large (2.5T) disk there. I've then proceeded to try to rsync the entire parity-data folder. This seemingly does work except permission errors on some files. However, when I start parity on the new instance it starts syncing the entire chain. Is there anything I'm doing wrong? Is there perhaps some subset of the data I can transfer instead of the entire folder?

[joshua-mir]

I am not sure how well rsyncing parity's data dir and pointing parity at one created on a different instance will work. It sounds like it should work as you've expected, but those permissions errors sound suspicious, have you shut down parity before trying to rsync it's data directory? Are you by any chance using a custom chaindata directory, that is separate from your parity data directory?

The suggested way of doing this would be creating a "snapshot" of parity's db on your synced instance with https://wiki.parity.io/CLI-Sub-commands#snapshot and importing that on your new instance(s).

[mewwts]

Thanks @joshua-mir,
This looks like a better approach. I'll try this and move discussion to riot if it does not work!

Thanks :+1:

[5chdn]

do a

chown $USER:$USER /path/to/parity-data/ -R

to set correct permissions

[c0deright]

Just for clarification: This has absolutely nothing to do with parity. You can perfectly rsync ~/.local/share/io.parity.ethereum (or your data partition your -d flag is pointing to) to another machine and resume it's operation there.

You just have to make sure there are no permission issues, in your case most probably due to user/group mismatch between source and target host. That's simple linux 101. You might find rsyncs --numeric-ids useful in such cases.

[mewwts]

Actually, the two key files wouldn't be synced even after doing chown - I had to manually copy them (not even sure you need them?)

Might add in that it's wise to stop parity before you rsync. If not you'll have to remove some locks before starting parity at the destination.

But yes, can confirm - rsyncing to a different machine, albeit it does take some time, does work!

[c0deright]

The final rsync should be done when parity is stopped at the source machine: that's what I assumed every sane admin would do and didn't mention it explicitly. Without that you end up with a pile of garbage since files changed while rsync was running. The lock files would be your smallest problem.

But you could of course do a first rsync while parity was still running on the source machine. When that first rsync is done, stop parity on the source machine and redo the rsync. The second rsync will be much faster because only changed/modified files are transferred. This way you end up with a consistent copy of your data with only little downtime.