PM2 cross-version upgrade risks dump resurrection failure

Direct answers

• Reliability: No. pm2 resurrect is best-effort whenever the PM2 version reading the dump differs from the one that wrote it. Patch-level moves usually work; crossing major versions risks partial restores, stale metadata (cwd, interpreter, environment frozen at save time), or processes silently missing from pm2 ls.
• Snapshot practice: Run pm2 save on every intentional topology change and immediately before any PM2 upgrade, and keep dated copies of dump.pm2 — at minimum one pre-upgrade snapshot per version you leave behind, plus the last 3–5. Retention is manual; PM2 keeps exactly one live dump.
• Startup scripts: No auto-update. The init script embeds the PM2 binary path captured when pm2 startup ran. Re-run pm2 startup (then pm2 save) on each host after the binary path changes.

Confirmed behavior vs. likely failure mode

Well-established: dump.pm2 under PM2_HOME (default ~/.pm2) is a JSON snapshot of PM2's in-memory process table written by pm2 save; pm2 resurrect replays it; there is no built-in rollback or dump-migration command. pm2 startup generates an init script whose launch command points at the absolute pm2 path at generation time, and upgrading PM2 does not rewrite it.

Likely, but verify per version pair: the dump schema is an internal format, not a documented contract, and it has drifted across major releases. That is consistent with the partial or silent restores reported after major upgrades. Which fields break differs by release, so treat "same major line = safe" as an assumption to test, not a guarantee.

Upgrade sequence for this case

1. Record ground truth first: save pm2 --version and pm2 ls output next to your snapshot.
2. Snapshot: cp ~/.pm2/dump.pm2 ~/.pm2/dump.pm2.$(date +%F-%H%M). The dump captures environment variables, so store copies with restrictive permissions (e.g., chmod 600) in a private location.
3. Upgrade PM2, then run pm2 update — PM2's daemon refresh, which restarts the daemon and reloads the saved dump.
4. Compare pm2 ls count and statuses against the pre-upgrade record and hit one canary endpoint. An empty or partial list means the dump did not survive the format change.
5. Re-run pm2 startup for your init system and user, then pm2 save, so the unit file points at the new binary. On systemd, confirm with grep ExecStart /etc/systemd/system/pm2-*.service.
6. If resurrection fails, stop iterating on the old dump: rebuild from ecosystem.config.js (pm2 start ecosystem.config.js && pm2 save). This is the real reason to keep that file current.

A pm2 kill && pm2 resurrect rehearsal in staging before the production window is worth the time, since it is disruptive by design.

Snapshot frequency and retention

Save on events, not on a timer: every deploy that adds or removes processes, every environment change, and always immediately before upgrading PM2. A blind cron of pm2 save can overwrite your last good dump with a degraded process table, so pair any automation with dated copies rather than trusting the single live file. Also keep PM2_HOME stable — resurrection reads the dump for the effective user and home, so switching users or homes strands the dump entirely.

One detail that changes this advice

Which PM2 versions are you moving between (from → to)? A cross-major jump pushes me from "rehearse resurrect in staging, then proceed" to "plan to rebuild from the ecosystem file regardless of whether the dump loads."

Assumptions: written against PM2 5.x/6.x-era behavior with systemd as the init example. The dump schema is internal, so the exact breakage points for your specific version pair should be verified on staging before production — flag this piece for review if your versions differ materially.