ShippedBackups
Plan for more than the next release. Keep recoverable copies of important application data and know what restoring them will change.
Match protection to the resource
Review the backup and retention settings for each data service your application uses. Database records, object files, and queue state are different resources with different recovery needs. Keeping an old application image does not back up its database, and a database backup does not automatically include uploads stored in a separate storage service.
Choose the right recovery point
Before restoring data, identify the problem and the point you need to recover. Consider records written after that point and any outside actions, such as sent messages or completed payments. A restore changes stored state; it cannot reverse those external events. Confirm the restore’s scope and the application behavior you expect afterward.
Verify the recovered application
Check important records, relationships, access rules, and normal application workflows after a restore. Make sure the deployed application is compatible with the recovered schema and data. Keep recovery copies protected for the agreed retention period, and include their storage use in planning rather than deleting them simply because the live application is healthy again.
A little more detail
Questions about Backups?
Are backups the same as rolling back a deployment?
No. Backups protect stored data. Deployment rollback restores an earlier compatible application release. A problem may require one operation, the other, or a coordinated recovery using both.
Will restoring a backup preserve every newer record?
Not automatically. Restoring an earlier state can omit later writes. Review the recovery point and plan how to preserve or reconcile newer records before replacing an active data resource.
From your workspace to the web