Maintenance
Part of No-code deployment and maintenance
Backing up app data before a major update
Choose and verify a recoverable copy of app records, files and configuration before a major no-code update.
Before a major update, make a recovery point for the records and files the change could affect. Know what that copy includes, when it was made, who can use it and what recovery would do to work added afterwards.
A saved app version, an exported table and a platform snapshot protect different things.
Define what must be recoverable
List the affected tables, attachments, app configuration and connected systems. Ask whether the update will change existing rows, add columns, replace a source or trigger writes elsewhere. Decide how much newer work the team could re-enter if it had to recover an earlier state.
Choose a point close to the change after staff have finished or identified work in progress. Record its timestamp and the relevant record counts where available. Restrict access to recoverable copies because they may contain the same sensitive information as the live app.
Choose a method with its limits visible
| Method | What it may help recover | Limit to check |
|---|---|---|
| Platform snapshot or environment backup | A supported collection of app and data components | Included components, retention, restore target and effect on newer work |
| Table export | Selected record values | Filters, hidden fields, relationships and separate files |
| Copy or backup of an external source | Data held outside the app builder | The source product's own coverage, permissions and restore route |
Before relying on an Airtable snapshot, verify in current Airtable documentation what it covers, how restoration behaves and whether any history or other data is included.
Before relying on an Airtable view export, verify which records and fields it includes, whether attached files are included, and any expiry or retention limits in current Airtable documentation.
For Power Platform environments with Dataverse, Microsoft documents manual backups before major customisation. Manual backups are available for production and sandbox environments, but not the default environment; trial environments are not covered by system backup and restore.
Microsoft says a system backup cannot be restored over the default environment; admins can restore a default-environment system backup to a developer environment.
AppSheet can use spreadsheets, databases and other connected sources. Locate the actual source and establish its backup route separately. A copy of the app definition alone is not proof that records and uploaded files can be recovered.
Key Backup Considerations by Platform
- Airtable Snapshot Coverage
- Verified via current documentation
- Airtable View Export Limits
- Includes records and fields; attachments may not be included
- Power Platform Manual Backups
- Available for production and sandbox; not for default or trial environments
- AppSheet Data Source Backup
- Must locate and secure backup at source level
Check the recovery point
Have an authorised person confirm the backup or export's timestamp, location, scope and expiry. Inspect representative records by stable ID, including a related record and an attachment where relevant. Confirm that the person assigned to recover the app has the necessary access and instructions.
Where a safe isolated restore is supported, rehearse retrieving a sample without overwriting current work. Compare the retrieved sample with the current source by stable ID, and confirm expected field values and that any attachment opens. If the only restore route overwrites a broader environment, agree on that decision before the update.
Keep the recovery reference through the agreed observation period only if the platform's retention permits it. If it expires sooner, arrange another supported recovery point. After the update, check the changed task and the stored result before closing the release.
