Back up files and databases and verify recovery.
Backups can include application files, a database, or both as one coordinated full backup. Store them locally, in S3-compatible object storage, or on an SFTP server.
Choose the source, destination, schedule, retention, and exclusions. Supported schedules include every 12 hours, daily, every two or three days, and weekly. Retention options range from three days to one month.
File backups can exclude selected application paths. Database backups can exclude selected tables when a partial data set is appropriate.
Production recovery should include at least one destination outside the source server and provider account.
Scheduled runs are handled by background workers. You can also start a configuration manually. The backup history shows stage, progress, size, duration, destination, and failure details.
Restore files, a database, or a coordinated full backup in place when supported, or recover into a new resource to inspect data before replacement. The recovery wizard shows the exact source and target before starting.
A successful upload is not proof that a backup is recoverable. Perform a test restore after creating the configuration and repeat it after major application or database changes.
Document the expected recovery time and the last verified backup. Keep application-level rollback and data recovery separate: reactivating a release does not reverse a migration, and restoring a database does not restore missing release files.
