A skipped backup run now triggers a backup problem alert, helping you spot when a run did not produce a recovery point. Alert emails link directly to the affected backup job so you can inspect its run history.

MySQL and PostgreSQL jobs can read their password from a file on the protected server during source checks and backups. The file contents stay on that server. This option requires agent v0.15.0 or newer.

New teams see a four-step checklist on the dashboard: connect a server, add storage, create a backup job, and save and confirm its recovery document. The checklist tracks progress and shows the next action until the first job is ready.

Add an SFTP storage destination for a backup job or an extra copy. Configure password or Ed25519 key authentication and verify the server's host key; backups, restores, and exports can use that destination.

Use Update agent from a server's menu when a newer release is available. Supported package installations wait for running work to finish before updating, and the server page shows progress and any failure that needs a retry.

Add another storage destination to a backup job to copy its recovery points there. Track copying and maintenance on each destination, restore or export from an extra copy, and promote it to the main copy when needed.

Team Owners can choose All apps, Specific apps, or No apps when inviting a Member, and edit an existing Member's app access from Teams. Specific apps keeps newly added apps off limits until you grant access.

Open a recovery point's Restore page to copy a command for restoring it directly on the protected server. The target must be an empty or new directory. File contents are placed there; a database restore produces an uncompressed SQL file. This requires agent v0.8.0 or newer.

Open a run from a backup job to read its log and investigate what happened. You can also download the log from the run history.

Include or exclude databases and individual tables when creating or editing a MySQL or PostgreSQL job. Source inspection checks that selected tables are accessible before the backup runs. A filtered SQL backup may need additional database objects during recovery.

Keep an important recovery point indefinitely or expire selected recovery points from a backup job. Backup Chief protects the latest complete recovery point while applying these choices.

When a requested export is ready, fails, or is cancelled, Backup Chief can email the requester with a link to its result. Enable Prepared download results in Settings → Activity notifications; ready emails also show when the download expires.

Prepare a ZIP download for a file, folder, or database artifact from a recovery point. Select only the data you need, then download the export when it is ready.

Open a recovery point to browse its files and folders before choosing what to recover. You can filter the current folder and inspect database backup artifacts from the job page.

Create a MySQL or PostgreSQL backup job for selected databases, or let the agent discover accessible databases. Each database is saved as its own SQL backup. The server needs the matching database client tools.

In Settings → Activity notifications, choose which emails you receive for this team. Alerts cover agent availability, backup failures and recoveries, and maintenance failures and recoveries. These preferences apply to your own team membership.

Connect a Linux server, add a local or S3 storage destination, and create a file backup job. Run it on demand or on a schedule, then follow runs and recovery points from the job page.

The team invoices API can filter invoices by app with app_id, sort them by invoice date with sort=asc or sort=desc, and include invoice lines with expand[]=lines. When an app supplies resource details, each line also identifies the billed resource by ID, type, and label.

If you lose access to your authenticator app, passkey, or security key, you can use a recovery code to complete sign-in. Open Two-factor and Passkeys from the Account menu, then select Generate recovery codes while you still have access to a second factor.

OAuth clients can use private_key_jwt to authenticate with a signed client assertion instead of a shared secret. Host the public keys at a jwks_uri, then send a short-lived assertion when calling the token, revocation, or introspection endpoint.