Impreza app backups save supported deployment data to the Impreza S3 storage associated with your account. You can request a backup, check its result and restore a completed copy into the original app or a compatible destination through the platform’s app backup tools.
Before your first backup
Use an app managed by the Impreza Agent on a supported server. The app must be running to start a backup, the agent must be available, and another backup or restore must not already be running for that app. Check the S3 service and its available capacity in your account. The first manual backup can attempt to prepare storage when an eligible service is available; review the resulting storage status rather than assuming it is ready.
This integrated flow uses Impreza S3. It does not ask you to connect an arbitrary external S3 bucket. Check your current storage plan for capacity and pricing.
Know what the backup covers
The current backup format includes the deployment’s data directory and named volumes detected from its Compose configuration. Review custom bind mounts, external databases and remote file storage separately. Files outside the covered paths need their own recovery plan.
An app backup does not capture the whole operating system, every application on the VPS or every external integration. Keep deployment configuration and access recovery information in a secure place. Do not delete the source app’s deployment record: the integrated restore currently needs it to identify the original application.
Database recovery needs an extra check
The integrated job copies files while the app is running. Copying a database volume is not the same as making a database-native consistent backup. For stateful production apps, use the database’s supported backup procedure as well and validate recovery for the exact engine and version. A completed upload alone does not prove database consistency.
Create and check a recovery point
- Identify the app and server, then inspect the existing backup history, schedule and storage capacity.
- Request a backup for that specific app. Save the returned job or backup ID.
- Follow the job until it reports success or failure. Do not treat an accepted request as a finished backup.
- Record the successful backup ID and timestamp. Check the reported size and result before a restore or maintenance change.
For an assistant, start with a read-only request:
Show the backup history and schedule for my selected app. Check the storage status and tell me what needs attention before creating a backup.
Then authorize the specific operation you intend to perform. Keep secrets out of prompts and use an authorized connection with the required permissions.
Review the schedule and retention
Check the app’s actual schedule and retention settings. Scheduled runs depend on the app, agent, storage and scheduler being available. They do not create storage for an account that has none, so complete and verify the first manual backup before relying on the schedule.
Scheduled retention removes older scheduled copies after a new scheduled backup succeeds. Manual backups are handled separately and still consume storage. Review the latest successful run regularly, including when you use an account without email; do not rely solely on an email alert.
Restore and verify
Choose a completed backup and confirm the target app. Plan a maintenance window, manage application writes and workers, and ensure the target has room for staged restored data plus the data displaced by the restore. The operation can restart or recreate containers and interrupt service.
The restore checks the backup parts against their SHA-256 checksums before applying the restored files. These checks detect integrity problems; they are not an encryption guarantee. The previous data is moved aside on the target disk. That local copy uses space and is not a separate off-server backup.
After the operation, inspect app status and logs, sign in, open representative files or records, and test the features your users depend on. Resume traffic and writes only after validation. Remove displaced data only when you have confirmed recovery and no longer need it.
If the operation fails
Check the job result, agent connectivity, storage quota and destination disk space. A failed or incomplete backup is not a usable recovery point. Preserve the last successful copy while investigating. If the app does not recover correctly, retain the job ID and logs and contact support before removing data or repeatedly restoring over the same target.
For a different server, follow the app migration guide. For recovery of the virtual machine itself, use the separate VPS management guide.