Back up Rancher before you upgrade: three ways the backup step failed in my 2.15.2 lab

Every Rancher upgrade guide starts with "take a backup first". I ran that step in a lab in late October on Rancher 2.15.2 (biased, I work at SUSE) and it failed three different ways before it worked. Writing them down because none of them fails loudly.

1. The ResourceSet name. The Backup example I copied uses resourceSetName: rancher-resource-set. On my install that returned: resourcesets.resources.cattle.io "rancher-resource-set" not found. The operator ships two, rancher-resource-set-basic and rancher-resource-set-full. Run kubectl get resourcesets before you write the CR.
2. No storage, no backup. With no S3 details and no default storage location, the Backup sits in Retrying with "needs to specify S3 details, or configure storage location at the operator level". It doesn't go to Failed, so a quick look at the list can miss it.
3. The PVC needs a StorageClass. Installing rancher-backup with persistence.enabled=true alone left the PVC Pending on a cluster with no default StorageClass. Setting persistence.storageClass explicitly (local-path in my case) fixed it. With the right name and a volume, the backup reached Completed in under a minute.

Two more that are easy to skip:

• If you encrypt backups, the operator doesn't keep your EncryptionConfiguration. You need that same file to restore, so store it somewhere that isn't the cluster.
• Each Rancher chart declares a kubeVersion ceiling. helm show chart rancher-stable/rancher --version 2.13.3 | grep kubeVersion prints < 1.35.0-0. If the local cluster's Kubernetes moved ahead of Rancher, check this before the Helm upgrade.

What I didn't test: a restore, and a real minor-version jump (the lab already runs the latest release). If you've restored a Rancher backup for real, what surprised you?
First posted on r/rancher.