Laptop backup workflow

scripts/laptop-backup/ contains the laptop latest-backup workflow:

• deploy_laptop_backup.sh validates and installs the manual synchronization service.
• pmis-sync-latest-backups merges remote latest archives into one flat local directory.
• pmis-sync-latest-backups-follow starts or attaches to the systemd service, follows live progress, and returns the completed service result.
• pmis-backup-latest maintains the server-side latest links used as the synchronization source.
• restore_latest_backup.sh resolves a synchronized archive and delegates to the generic restore implementation.

Operator workflow

All five commands accept -h and --help without accessing configuration, connecting to remote hosts, or changing operational state. The synchronization command accepts no other arguments; configure it through the shared inputs and environment overrides. Options and relevant local paths are covered by the shared Bash completion.

Using the wrapper

Run the recommended interactive command from the _pmiconfig repository:

scripts/laptop-backup/pmis-sync-latest-backups-follow

The wrapper checks its dependencies, records the current journal position, and requests an asynchronous systemd start. sudo may prompt for authorization. The synchronization itself remains owned by systemd; the wrapper only follows its journal and monitors its machine-readable service state. It exits when that service invocation finishes and returns the service result.

If synchronization is already activating or running, the wrapper does not request another start. It shows a small amount of recent context and attaches to the existing invocation instead. Use --help to display its minimal command interface:

scripts/laptop-backup/pmis-sync-latest-backups-follow --help

Press Ctrl+C to stop following without stopping synchronization. The wrapper cleans up its journal follower, confirms that synchronization continues under systemd, and prints commands for reconnecting and checking status. TERM and HUP have the same service-preserving behavior.

The current account must be able to read the system journal. If it cannot, the wrapper prints a warning and continues monitoring the systemd result without silently retrying journalctl through sudo.

Wrapper exit statuses are:

Raw troubleshooting commands

Use the raw commands for troubleshooting or to reconnect manually:

# Start without waiting for synchronization to finish.
sudo systemctl start --no-block pmis-sync-latest-backups.service

# Follow host transfers and publication progress live.
journalctl -fu pmis-sync-latest-backups.service

# Inspect the final service status and recent journal entries.
systemctl status pmis-sync-latest-backups.service
journalctl -u pmis-sync-latest-backups.service -n 100 --no-pager

The same non-interactive progress output is visible when pmis-sync-latest-backups is run directly in a terminal.

The deployment command renders templates/systemd/rsync/pmis-sync-latest-backups.service.in and can validate it without installation by using --dry-run --no-ssh-check. The synchronization command and deployer source /srv/pmiverse/_pmiregistry/config/pmiverse.conf, or the trusted file selected by PMIVERSE_CONF. Its namespaced PMIS_BACKUP_REMOTE_HOSTS, PMIS_BACKUP_REMOTE_PATH, and PMIS_BACKUP_LOCAL_PATH values are the canonical persistent inventory. Per-process REMOTE_HOSTS, REMOTE_PATH, and LOCAL_PATH environment values override them; explicit deployer CLI options take the highest precedence for that deployment or validation run. Empty host elements, duplicate hosts, and invalid host names are rejected. Every remote host retains the same data/backups/ path. Separate host folders apply only to full-history rsync destinations on the local restore server. Standalone pmis-backup-latest resolves its default root through the instance registry; explicit --backup-root and BACKUP_ROOT still override it. The deployment command accepts the same list through --remote-hosts, validates every resolved host, renders one shared pmis-sync-latest-backups.service, and checks unattended SSH access to each host unless --no-ssh-check is explicitly selected. The unit contains no host or backup-path inventory: the canonical synchronization command reads shared configuration at runtime, so persistent inventory changes do not require unit regeneration or systemctl daemon-reload.

Each host is synchronized into a fresh private staging directory. The command requires every staged entry to be a non-symlink regular *_latest.zip file and rejects duplicate basenames across hosts. The published directory is untouched until every host succeeds and the merged staged set validates. Replacements are copied to destination-local temporary files and atomically renamed; stale managed *_latest.zip files are removed only after every replacement succeeds. The synchronization lock and staging state remain outside the flat published set, and traps clean staging on normal exit and signals.

The journal reports timestamped host staging, validation, per-file publication, stale-pruning, and completion phases. Each host transfer retains rsync's native aggregate byte count, percentage, transfer rate, and estimated remaining time when rsync can calculate it. Progress is per host; host and publication counters show overall workflow position without inventing a combined percentage. The same output format is suitable for both terminals and journald.

The restore command selects exactly <database>_latest.zip, refuses symlinked sources, and delegates database, filestore, locking, rollback, and neutralization behavior to scripts/restore/restore_database.sh.

Default operational inventory is defined in /srv/pmiverse/_pmiregistry/config/pmiverse.conf:

• Remote hosts: the registry's PMIS_BACKUP_REMOTE_HOSTS value
• Remote latest links: /srv/pmiverse/_pmisuite18/data/backups/latest/
• Laptop copies: /srv/pmiverse/_pmisuite18/data/backups-latest/
• Restore locks: /srv/pmiverse/.pmis-restore-locks

See the producer runbook for instance selection and the local full-history mirror layout. Remote paths stay unchanged.

Deployment, synchronization, backup, restore, and neutralization are operational actions; do not invoke these commands merely to verify the layout.