Migrate from RedundaNet 2

RedundaNet 3 runs beside your RedundaNet 2 stack. The old grid stays live until a stop date the maintainer announces, because its Tahoe shares still hold members' data. On a RedundaNet 2 node both tools exist: the Python redundanet on PATH is the legacy one, and the Go agent lives at /var/lib/redundanet3/bin/redundanet. Every command on a node below uses the full path. The long form is docs/migration.md on GitHub.

1. Identity on your laptop

Only the laptop ever holds your phrase. Install the agent there, create your identity and join the network with the public descriptor from the install page.

redundanet identity init --network redundanet      # the phrase, shown once; prints your member key
redundanet network join <descriptor>

2. The legacy attestation

Your RedundaNet 2 nodes are listed with GPG keys. Sign your new member key with one of them; that ties the new identity to the person the network already trusts. If the key lives on the node, run the command there.

printf '%s' <member key> | gpg --armor --detach-sign -u <fingerprint of one of your nodes' keys>

Keep the armored output and the 40-character fingerprint you signed with: both go into the join request.

3. The join request

Fill the join form with your member name, your member key, the disk you contribute, and, in the RedundaNet 2 section, the fingerprint and the signature. If you contribute disk, the form also wants your node's device key, which step 4 prints; most members do step 4's prepare first and send one request.

A workflow validates the request and opens a pull request; the maintainer signs the manifest offline and merges; every agent applies it within five minutes.

4. The agent on each node

The storage node flow: install.sh prepare on the node prints its device key, you certify it on your laptop, and install.sh finish joins and starts the service. The agent runs beside the Docker stack on the host's network and stores shares under STORAGE_PATH/redundanet3.

# on the node, as root
curl -fsSLO https://raw.githubusercontent.com/adefilippo83/redundanet/main/agent/deploy/node/install.sh
curl -fsSLO https://raw.githubusercontent.com/adefilippo83/redundanet/main/agent/deploy/node/redundanet-agent.service
sudo STORAGE_PATH=/mnt/storage bash install.sh prepare 3.0.0

# on your laptop
redundanet identity certify --network redundanet --device <KEY> --storage > node.cert
scp node.cert node:

# on the node
sudo bash install.sh finish node.cert

The runbook: agent/deploy/node/README.md. The node appears on the status page under your name once the manifest lists it.

5. Native backup sets and a restore test

Add a native backup set for every folder that backup-sync pushed to the old grid, on the device that holds the folder. The agent scans it daily and runs a restore test weekly.

# on a node
sudo /var/lib/redundanet3/bin/redundanet backup add NAME FOLDER [FOLDER...]
sudo /var/lib/redundanet3/bin/redundanet backup run NAME
sudo /var/lib/redundanet3/bin/redundanet backup verify      # a restore test now
sudo /var/lib/redundanet3/bin/redundanet backup list        # sets, runs and restore tests

Go on to step 6 only with a passed restore test on the native grid, listed by backup list and on the local page.

6. Retire the Docker stack

Not before the stop date is announced. A node's Tahoe shares hold other members' data too, and the old grid is 2-of-4. The wind-down is manual: no countdown and no automatic deletion exist.

migrate-node stops and removes the containers, whole, tinc first; files and shares stay on disk. It refuses while anything is missing from the native grid. Dry run first; --rollback brings every service back together.

sudo /var/lib/redundanet3/bin/redundanet migrate-node --dry-run    # the plan, and what is not yet on the native grid
sudo /var/lib/redundanet3/bin/redundanet migrate-node              # retire the stack
sudo /var/lib/redundanet3/bin/redundanet migrate-node --rollback   # every service again, tinc first
sudo /var/lib/redundanet3/bin/redundanet migrate-node --force      # past a refusal, on purpose

The agent keeps running through all of it and the node stays on the status page. A drill is migrate-node followed by --rollback within a few minutes, inside the old grid's tolerance of two servers down.