Plan upgrades and recovery
Before changing an AgReady instance, identify what you need to preserve, create a backup you can inspect, and decide how you will verify the instance afterward. Treat an application upgrade, a data backup and a restore as separate operations.
On this page
This guide describes the source associated with v0.0.1. Download scripts can change independently. Check your installed controls and current release instructions before making changes; no recovery drill is reported here.
Record the starting point
Record the running version, operating system and architecture, installation method, database type, configuration and data locations, and how the service is started. Keep credentials out of that record. Choose a maintenance window and tell affected users before interrupting running work.
Read the target release notes and license terms. Keep a recoverable copy of the current data and configuration before an upgrade. A link to an older executable is not a data backup.
Create and check a backup
Where Backups is available to your administrator, configure an approved S3 or WebDAV repository using its actual endpoint and credentials. Use Test connection and save the intended settings. Before Initialize, check the destination carefully: initialization establishes the repository identity, and its remote root and encryption key cannot then be changed through ordinary configuration.
- Download recovery.yml and store it in an approved secure location outside the instance you are protecting. It contains repository credentials and the decryption key. Do not attach it to support messages or publish it with deployment files.
- Use Back up now. A queued or skipped notification is not a completed snapshot.
- Inspect Backup jobs for the final state and Complete snapshots for the expected version, time and snapshot. Investigate a failed or interrupted job rather than assuming partial uploads are recoverable.
- If enabling a schedule, check its timezone and retention setting. Confirm that a scheduled job actually completes before relying on it.
- Plan a separate recovery drill in an isolated, authorized environment. The presence of a complete snapshot does not by itself prove your full service can be recovered.
Know what is outside the backup
The application snapshot covers selected AgReady data and required configuration; it is not a whole-machine image. Do not assume arbitrary files, external tools, provider accounts or connected business systems are included.
If the instance uses PostgreSQL, arrange a separate database backup and restoration plan with its administrator. The application file snapshot must not be treated as a PostgreSQL database dump. Coordinate the database and file recovery points, and verify them together before accepting a restored instance.
Keep recovery credentials available even if the original host is lost. Protect them as carefully as production credentials, and confirm which administrator is authorized to use them.
Upgrade with a clear rollback boundary
The automatic Server upgrade procedure reviewed for v0.0.1 is for Linux installations managed by the installer and the agready-server systemd service. It requires elevated privileges, validates release downloads, switches the executable and restarts the service. It attempts to return to the previous executable if startup fails; that attempt can also fail.
Do not interpret this as a guarantee that application data or database changes can be rolled back. Review the target release and your backup before proceeding. Do not apply the Linux automatic-upgrade procedure to macOS or an unmanaged installation; follow instructions appropriate to that installation.
After an authorized upgrade, check the reported version, startup result, browser access, model configuration and a small non-sensitive task. Check required tools separately. Server upgrades do not establish that separately distributed plugins or Runtime Assets have been updated or are ready.
Prepare a restore before replacing live data
Prepare restore downloads and verifies a chosen complete snapshot and prepares its files. Ready for cutover means preparation is finished; it does not mean the running instance has been restored.
Recovery has distinct stages:
- Select the intended complete snapshot and check version and platform compatibility. Have the administrator verify the target locations and database recovery plan.
- Prepare the snapshot and inspect the result. Do not start another restore merely because preparation takes time.
- Stop AgReady through the installation's approved procedure before switching the prepared data into place. Protect the pre-restore state until validation is complete.
- Start the instance and validate access, configuration, expected data and a bounded task. Include the separate database checks where applicable.
- Confirm the restore only after validation. Confirmation cleans up recovery control and rollback material. If validation fails, stop the instance and have the administrator assess rollback rather than confirming or deleting recovery files.
Use the recovery commands documented by the installed version with the correct recovery configuration. These operations replace data; they are not routine troubleshooting steps. A stopped task in the chat interface is not a stopped Server service.
If maintenance fails
Preserve the error, installed version and the last completed stage. Do not repeatedly rerun upgrades, remove recovery-control files or initialize a new repository to suppress an error. Share only redacted diagnostic excerpts with the administrator.
For initial startup and connection problems, begin with Install and start and the first-use diagnostic checks.
Start with installation and human oversight when planning changes.