feat(snap): automatic wallet backup on snap removal

[dominicletz]

Summary

Closes #2

When a user runs snap remove diode-node, the snap's data directories are deleted and wallet access can be lost permanently. This PR adds an automatic backup that runs in the snap remove hook before data is wiped.

Approach

This follows the design in issue #2:

1. remove hook (snap/hooks/remove) runs before snap data deletion and invokes the backup script bundled in the snap.
2. backup-dir plug requests write access to /var/backups/diode-node via the system-files interface.
3. Backup script (scripts/snap_backup_on_remove.sh) archives the critical resurrection files:
   • $SNAP_USER_DATA/node (node identity)
   • $SNAP_DATA/nodedata_* (wallet/database)
4. Fallback UX: if the backup directory cannot be written (plug not connected), the hook logs a warning pointing users to snap saved / snap restore within the 31-day snapd retention window — removal still succeeds.
5. Restore helper (scripts/restore_snap_backup.sh, installed as bin/restore_snap_backup) and README documentation for manual recovery.

Note: erl_inetrc is intentionally excluded — DNS config is regenerated on service start and is not required to resurrect the node.

Business case

Users who uninstall the snap without knowing about wallet persistence lose access to their node identity and funds. Automatic backup on removal makes recovery possible without requiring users to know about manual snap save procedures upfront.

Demo

Simulated snap-removal flow (mock $SNAP_DATA / $SNAP_USER_DATA directories):

1. Critical files present before removal

2. Remove hook creates secure backup archive

3. Archive preserves resurrection files + manifest

4. Restore after reinstall

5. Fallback when backup-dir plug is not connected

Testing

Added test/snap_backup_on_remove_test.exs covering:

• Tarball creation with node identity and nodedata, secure permissions (0600)
• Explicit exclusion of erl_inetrc even when present
• Skip when no data exists
• Graceful handling when backup directory is not writable

Validated locally with bash integration tests mirroring the ExUnit cases.

Notes

• Auto-connection for the backup-dir system-files plug will need a separate Snap Store forum request.

  

[gemini-code-assist]

Code Review

This pull request introduces an automatic backup and restoration mechanism for the diode-node snap. It adds scripts to archive critical node data (identity and wallet databases) during the snap removal process and provides a corresponding restoration script, supported by new tests and updated documentation. The review feedback focuses on security hardening for handling sensitive wallet data, specifically recommending the use of a restrictive umask (077) in both scripts and ensuring the backup directory is secured immediately upon creation. Additionally, there is a suggestion to align the restoration script's usage instructions with the recommended commands in the README.

[gemini-code-assist]

The usage example suggests running the script directly with sudo, but since it relies on SNAP environment variables, it is better to align this message with the recommended command in the README which uses snap run --shell.

Suggested change

	sudo $0 /var/backups/diode-node/diode_node_backup_YYYY-MM-DD_HHMMSS.tar.gz
	sudo snap run --shell diode-node -c 'bin/restore_snap_backup /var/backups/diode-node/diode_node_backup_YYYY-MM-DD_HHMMSS.tar.gz'

[gemini-code-assist]

Setting a restrictive umask is recommended when handling sensitive data like wallet backups to ensure that any temporary files or directories created during the restoration process are not world-readable.

Suggested change

	staging_dir=$(mktemp -d)
	umask 077
	staging_dir=$(mktemp -d)

[gemini-code-assist]

For better security hardening, consider applying chmod 0700 to the backup directory immediately after it is created, rather than at the end of the script. This ensures the directory is secured before the sensitive tarball is written into it.

Suggested change

	if ! mkdir -p "$BACKUP_DIR" 2>/dev/null; then
	log "cannot create backup directory $BACKUP_DIR (is backup-dir plug connected?)"
	log "use 'snap saved' within 31 days to recover data via 'snap restore'"
	exit 0
	fi
	if ! mkdir -p "$BACKUP_DIR" 2>/dev/null; then
	log "cannot create backup directory $BACKUP_DIR (is backup-dir plug connected?)"
	log "use 'snap saved' within 31 days to recover data via 'snap restore'"
	exit 0
	fi
	chmod 0700 "$BACKUP_DIR" 2>/dev/null || true

[cursor-automation]

@gemini review this PR

[dominicletz]

@cursoragent Remove erl_inetrc from the backup strategy and documentation. DNS data is not critical to be backed up.

[cursor]

Addressed @dominicletz's feedback — erl_inetrc is no longer part of the backup strategy.

Changes made

1. scripts/snap_backup_on_remove.sh — Removed copying of $SNAP_USER_DATA/erl_inetrc. Backups now only include:

   • $SNAP_USER_DATA/node (identity)
   • $SNAP_DATA/nodedata_* (wallet/database)

2. test/snap_backup_on_remove_test.exs — Updated the main test and added does not backup erl_inetrc even when present to prevent regression.

3. README.md — Updated backup description to say "identity and wallet database" (removed "Erlang DNS config").

4. PR feat(snap): automatic wallet backup on snap removal #13 description — Updated the approach section and added a note that erl_inetrc is intentionally excluded because DNS config is regenerated on service start.

Changes are committed and pushed to the PR branch. snap/run still generates erl_inetrc on start — that's unchanged and correct, since it's runtime config, not resurrection-critical data.