Full app backups
Use the Backup tab in your app to save encrypted backups to Caliber Node Backup Storage, your own SSH server, or S3-compatible storage. You can run backups manually or schedule them every 24 hours or every 7 days.
Full app backups are currently in beta on supported Caliber Node app hosts, with a limit of 100 GiB of persistent app data. Attached App Storage counts toward this limit.
What is includedβ
- Persistent app files and managed databases belonging to the deployment.
- Attached App Storage.
- App settings and container images needed for recovery.
Databases hosted outside the deployment need their own backup. Files stored outside the app's persistent volumes, such as objects in an external S3 bucket, are not included.
Connect Caliber Node Backup Storageβ
- Sign in at portal.calibernode.com.
- Open My apps, choose your app, and select Backup.
- Click Add destination and enter a name.
- Select Caliber Node Backup Storage, then choose an active storage account you already own.
- Choose a backup mode and how many backups to keep, from 1 to 30.
- For Stop app during backup, confirm the downtime checkbox.
- Click Save destination.
The panel adds a separate SSH key to your storage account automatically. This does not purchase another storage account or increase its capacity. Your existing storage and transfer allowances still apply.
Click Test destination. If the SSH key is still being installed, the job waits automatically. Wait for the test to show Complete before starting a backup.
Connect your own SSH storageβ
Choose My SSH / rsync storage when adding a destination. Enter:
| Field | What to enter |
|---|---|
| Hostname | Your publicly reachable storage server hostname or IPv4 address |
| SSH port | The server's SSH port, usually 22 |
| SSH username | The account that will store the backups |
| Destination directory | A directory accessible to that account |
| Verified SSH host fingerprint | The server's SHA256 host fingerprint, obtained from its console or your provider |
The server must support rsync and SFTP. Its SSH account needs permission to write, read, and remove backup files in the destination directory. Private network addresses are not supported by this connection method.
After saving, expand SSH public key on the destination card. Add that generated public key to the destination account's authorized SSH keys, then click Test destination. The public key grants access to storage; it is different from your backup recovery key.
Connect S3-compatible storageβ
Choose S3-compatible storage to use a bucket you own. Enter its HTTPS endpoint, bucket, region and credentials, then test the destination. See Back up an app to S3 storage for the full setup guide, provider details and required permissions.
Choose a backup modeβ
Stop app during backup is the recommended mode. The app stops while its data is captured, then previously running services restart before the archive uploads. Allow for downtime during capture; the time needed depends on the app and its data.
Keep app running is available only for qualified app versions. During the initial beta, qualification is limited to the tested Nginx 1.31.3 image. Other apps should use the stop-app mode. Files can change during a live capture, so a live backup is not a single frozen moment. An unsupported live backup does not silently switch to stopping your app.
Save your recovery keyβ
Click Download recovery key and keep the downloaded JSON file somewhere safe, separate from the backup destination. Each destination has its own key. The key is needed to decrypt its encrypted archives; do not share it in a public post or support screenshot.
Run and schedule backupsβ
After a successful destination test, click Back up now. Follow the job in the destination's history and wait for Complete.
Under Schedule, choose Manual only, Every 24 hours, or Every 7 days. Choose Manual only to stop future scheduled runs. These are interval schedules, not a choice of a particular clock time.
The Backups to keep setting controls retention for that destination. Older backups are removed after a new backup completes and passes verification. Leave enough free space for a new archive before older copies are removed.
Storage and transfer usageβ
Each archive is encrypted before upload. Verification downloads the archive again and checks it, so a backup uses both upload and download transfer. Container images are included, so archive size is not just the size of your app's files. Restore tests also download an archive.
Check your destination's available space and transfer allowance when choosing a schedule and retention count.
Test recoveryβ
Beside a completed backup, click Test restore. The panel restores it into isolated containers to check recovery without replacing your current app.
A test checks that the archive can start. The test containers are removed afterward. To open a copy and inspect your saved data, use Preview under Recover your app.
Open a backup previewβ
- Open your app's Backup tab and find Recover your app.
- Find the completed backup you want to inspect and choose Preview.
- Wait for the preview to be ready, then open its link and enter the password shown in the panel.
- Sign in to the app using the credentials saved in that backup.
- Choose Close preview when finished. It expires automatically after one hour.
The preview is a separate copy. Changes there do not change your running app or the saved backup. Internet access, outgoing email, webhooks and connections to other apps are blocked. Features that depend on those connections will not work in the preview. External sign-in providers may also be unavailable.
You can have one active preview at a time. Previews require available host capacity and a supported HTTP web interface. Keep the preview link and password private.
Restore your appβ
Restoring replaces your app's persistent data with the selected backup. Changes made after that backup will no longer be present in the restored app.
- In Recover your app, choose Restore this backup next to the completed backup.
- Read the confirmation and type your app's current name exactly.
- Confirm the restore and leave the app unchanged while the job runs.
- Wait for Complete, then open the app and check its data.
Before replacement, the panel creates and verifies a fresh safety backup. If that backup fails, replacement does not proceed. The app is unavailable during data replacement and startup checks. If startup validation fails, recovery attempts to put the previous data back. A Recovery required result needs support; do not retry changes to the app while it is locked.
The app keeps its existing address and container configuration. The selected backup and safety backup are protected from automatic retention cleanup for at least seven days. To undo a completed restore, select its safety backup from the completed backups and restore it using the same confirmation process.
Which backups can be restored here?β
Self-service restore currently requires a Stop app during backup archive whose services, container image versions, settings and persistent volume layout still match the app. It restores data into the existing deployment; it does not change the app to an older image or configuration.
If the app has been upgraded or its storage or configuration has changed, contact support with the app name and backup date. Apps with private networking or dedicated network listeners also need a coordinated restore through support. These checks prevent a backup being applied to an incompatible deployment.
Troubleshootingβ
| Issue | What to do |
|---|---|
| Back up now is unavailable | Run Test destination and wait for Complete. |
| Preparing the backup SSH key | Allow setup to finish; the queued test starts automatically. |
| rsync exit 255 | For external storage, check the SSH port, username, authorized key, fingerprint and firewall. Retry Test destination. For Caliber storage, contact support if it persists after key setup. |
| Keep app running is unavailable | Use Stop app during backup; live backups are not qualified for that app version. |
| Data or staging-space limit reached | The beta permits up to 100 GiB of persistent data and also requires temporary space on the app host. Contact support if the limit blocks your backup. |
| Backup failed or recovery required | Read the job's error and contact support with the app name and job time. Do not assume a failed run created a usable backup. |
You can configure up to three backup destinations per app. The Backup tab appears only where full backups are enabled for the app host.