PostgreSQL backups
Production operations include PostgreSQL backup and restore scripts with checksum verification and explicit destructive-restore confirmation.
Backup and Restore.
Operational backup, restore and rollback boundaries for Limvero production deployments.
Backup controls
Backup and rollback are documented as implemented operator workflows, not as unsupported uptime or recovery guarantees.
Redis backup
Redis backup support exists for runtime data such as cache, rate-limit and realtime state where the deployment uses Redis.
Pre-migration backup
Production deploy flow performs a pre-migration PostgreSQL backup before applying database changes.
Release rollback
Rollback uses signed release manifests and image tags from the manifest to restart API, web and worker services consistently.
Tenant export snapshots
Tenant exports are stored with checksums and capped collections so offboarding and deletion preparation remain bounded and reviewable.
Provider boundary
External object-storage sync remains provider-specific and is enabled only after the storage provider is selected and reviewed.
Restore expectations
Restore behavior is intentionally explicit because restaurant production data requires careful operator confirmation.
Restore validation
Restore scripts require checksum validation by default and refuse destructive restore unless the operator confirms the target explicitly.
Recovery depends on incident scope
Restore timing depends on data volume, hosting environment, incident type, provider availability and the signed customer agreement.
Operator preflight
Operations tooling validates Docker, Compose, shell scripts, environment values, edge configuration and production security gates before deploy.
Backup and restore processes support continuity but do not replace a customer-specific SLA, disaster recovery agreement or provider-specific storage review.
Plan a clean restaurant rollout.
Talk through locations, POS devices, kitchen workflow, menu migration, API needs and security review before launch.