3.9 KiB
Manual consistent backup
remote backend backup
remote backend backup backups/before-manual-maintenance.tgz
The default destination is a unique UTC-stamped filename under the repository's ignored backups/ directory. Existing files are never overwritten. The final file is owner-readable only (0600); incomplete downloads use a private temporary filename and are removed on failure. Keep this archive private: it contains tracking data and account state.
One SSH connection runs the operation under the shared deployment lock. It validates the managed Hostsharing runtime paths and matching current/deployed manifest, refuses pending deployments and transitional service states, and remembers whether the service was running and whether maintenance already existed. The immutable JAR is copied before downtime. The command enables maintenance when needed, stops a running service with the existing checked stop procedure, and copies the closed H2 directory. It restarts only a previously running service and checks application/Flow readiness. Existing maintenance is preserved; only maintenance created by this invocation is removed after successful restoration of the service state.
The archive contains regular files only:
data/*: the complete checked H2 data directory, includingwerkjournal.mv.db.release/werkjournal.jarandrelease/manifest.json: the matching application.backup.json: format version 1, creation time, release metadata and SHA-256 for every data/release file.
Server environment secrets and JDK binaries are not copied. The service environment remains managed separately in ~/.config/werkjournal/environment and covered by Hostsharing backups. No database schema change or rollback is performed by this command.
Compression and transfer occur after the prior service state has been restored. Local verification streams the archive without extracting it and checks allowed members, duplicates, required files, manifest consistency and all checksums. Only a successful SSH exit and successful verification publish the final filename atomically. A concurrent destination creation cannot be overwritten.
If copying fails after a successful stop, the previous running service is restarted and checked before the error is returned. Failed stop, failed readiness or an interrupted SSH process leave maintenance available for diagnosis; do not remove it until the service is healthy. Inspect remote backend status and remote backend log, then use the service controls to restore operation. A stopped service stays stopped if it was already stopped when backup began. A failed or interrupted transfer cannot change application data or the current release. Abandoned ~/opt/werkjournal/manual-backup-* directories after process termination may be removed by the operator after confirming no backup process is active; they are outside the public webroot.
This command is a manual operation, not an additional recurring backup policy. The restore command and isolated probe are documented in operator-restore.md. A representative restore from Hostsharing’s own backup system remains a separate acceptance task.
Automated validation: all 47 operations tests passed. Eight backup tests cover shutdown-flushed data, the matching JAR, stopped/running state, existing maintenance, copy and readiness failures, pending deployment, private local publication, overwrite refusal, truncated/failed transfer and checksum corruption.
Live Hostsharing validation, 2026-09-09: the first invocation encountered an active deployment lock and safely returned without a local archive. After the deployment succeeded, the second invocation created backups/werkjournal-20260909T121309Z-17b48c0d.tgz (60,719,515 bytes, mode 0600, ignored by Git), verified every archive checksum and matched application commit bb15cdd0da43fbce32c12d3b01481c2bec1596b0. The public HTTPS info endpoint returned version 0.1.17-SNAPSHOT afterward. This is a successful backup test, not yet a restore acceptance test.