After reading up on MFS, and pining, seems like
ipfs pin add -r --progress <peer ID>
should work, as the peer ID is (conceptually at least) the container for the hashes under it.
Unfortunately it doesn’t. So I’m left with using the ipfs files api to create a folder and populate it with the hashes for the server I’m replicating. I have all the hashes in a SQLite file so that should be easy, but likely very slow.
Then use ipfs pin add -r --progress \<hash of the MFS folder\>
What made you think that ipfs pin add -r --progress <peer ID> would work? A peer is an agent, not a set of data. Additionnaly, this would be an easy DoS vector.
But if you want to replicate all the data from a peer you control, you should have a look at IPFS Cluster :
Wishful thinking. My rationale was the peerID represented the contents of the server. I haven’t dug into the details to know what you just pointed out, but discovered it won’t work by trial & error.
I’ve been looking at ipfs-cluster today. My understanding is that it’s a separate service that runs along / in conjunction to the ipfs daemon to manage pins.
If so I don’t know why you suggested it as an alternative to ipfs-pack. If not then it isn’t apparent to me how it can be used to transfer between 2 ipfs servers.
If server A has acquired and pinned data via “ipfs add” server B can pin the hash of server A’s data, but I don’t think that copies the data to server B, it only creates a reference. That makes sense if the goal is space efficiency of the ipfs network, but so so much if you’re trying to migrate from one machine to another, such as when you change your hosting company.
If I am wrong about any of that I’de greatly appreciate being informed otherwise.
Thx