Hello, i have one node “A” on raspberry pi 4 and i think to migrate on amd64 supermicro debian 10.9.
I have one first question, running actually on my amd64 a new 1 week storagenode “B” can i stop it without worry for my old node (on the same IP address) ? My IP will not be blacklisted ?
Second question is about my process of migration, do you see other tasks or work like modifying config files inside storj directory, renaming some links, or files owner modifications to to achieve it ? (see bellow)
I would like to migrate from raspberry to amd64 linux debian 10.9, what i plan to do is :
Hot Rsync all data from my amd64 : source = raspberrypi /storj / destination = amd64 /storj
Your IP won’t be blacklisted. All nodes are separate, so shutting down node B won’t affect node A’s reputation.
This seems like the correct procedure for migration. You’ll need to move the identity files, and then run the storagenode install on the new amd64 (I guess this is the relaunch process).
That probably goes without saying but you’ll also have to make sure all configurations of the moved storagenode are okay and up-to-date (data destination, identity files location, …)
I’d recommend watching very closely the node (for a couple of days) after migration and final restart, to make sure your audit scores stay good. If anything starts dropping, you should immediately extract its logs and probably stop your node while figuring out what’s going wrong.
If after migration your node shows some activity (ingress/egress), is shown as “online” and keeps high scores, then everything should be fine
Finaly migration is done with 100% success !
All is fine ! “Setup” wasn’t necessary as it reject me with error /app/config already exist.
Simply do thoses steps to achieve a successfull migration on Linux (/storj is my storage dir on source and target and all commands are launched from target) :
Synchronize during storagenode uptime with rsync (hot sync) : # rsync -rtuvp --progress --bwlimit=100000 root@source_ip:/storj/ /storj/
Synchronize during storagenode uptime a second time with deleting files that are not anymore on source : # rsync -rtuvp --delete --progress --bwlimit=100000 root@source_ip:/storj/ /storj/
Synchronize during storagenode is stopped (downtime) a third time with deleting files that are not anymore on source again without bwlimit (cold sync): # rsync -rtuvp --delete --progress root@source_ip:/storj/ /storj/
Synchronise identity files with scp over ssh from source to target : # scp -r -p root@source_ip:/source/identity/path /target/identity/path
Check quickly files on source and target
Check or review firewall NAT/PAT/DNS settings
Relaunch storagenode on new platform without the “setup” step (directly docker run)
For Microsoft Windows kindly look for “robocopy” and you can run rsync in a screen in linux for more safety.
Hope this will help Best regards to the community.