SupportConsole
llms.txtSign in

Schedule database backups

llms.txt

A database is the one thing on your server that you cannot rebuild from Git. A scheduled backup takes a dump of the databases you choose, compresses it on the server and uploads it straight to your own bucket, so a dead disk or a deleted server does not take your data with it.

This article creates a backup configuration: what to back up, when, where to put it, how long to keep it and who to tell when it fails. You set it up once per server and it runs by itself from then on.

Before you begin

  • A verified storage provider. See Add an S3-compatible storage provider. Without one the form has nothing to offer.
  • A database engine and at least one database on a Ready server. See Create a database and a user. MySQL, MariaDB and PostgreSQL are supported.
  • Permission to manage backups on the server. Members who can only view the server can read the list of runs but not change anything.
  • Free space on the server. The dump is written to a work folder in the SSH user's home (.srvyard/backups) while it waits for the upload, so keep some free disk space: at least the size of your largest database, compressed.

1. Open the Backups tab

Open the server and choose Backups. Three sections sit under the tab: Databases, Files and Snapshots. You are in Databases.

The backup configurations of a database server
Each configuration shows when it runs next, where it stores its dumps and how many it keeps.
  1. New configuration opens the panel of the next step. A server can have up to 20 configurations.
  2. Schedule and Next run. The table shows the schedule in words (Every day at 02:30) and the cron expression behind it (30 2 * * *), followed by the next run. All times are in the server's timezone, shown in the card heading (UTC unless you changed it).
  3. Storage shows the provider, and Keeps how many backups it keeps. The menu at the end of a row has Back up now, Edit, Pause schedule (or Resume schedule) and Delete configuration.

2. Choose what and when

Press New configuration. The panel opens from the right: Dumps are compressed on the server and uploaded straight to your bucket. The server never sees your storage keys.

The first half of the New backup configuration panel
The first half of the panel: which databases, how often and at what time.
  1. Name (optional). A label for the lists, for example Nightly - all databases. If you leave it empty the configuration is called Database backup.
  2. Databases. The switch All, including new ones backs up every database on the server, including databases you create later. Switch it off to tick the databases yourself. You must pick at least one: Choose at least one database, or back up all of them.
  3. Frequency. Hourly, Daily, Weekly or Custom (cron). Hourly asks for the Minute past the hour.
  4. Time (UTC). For Daily and Weekly, the time of day in steps of 30 minutes. A weekly schedule adds a Day field. The panel lists the next three runs in the server's time so you can check the result before you save.

Choose a quiet time. A dump reads the whole database and adds load, so avoid your busiest hours and avoid running every configuration of a server at the same minute.

The Custom (cron) frequency
Custom (cron) takes a five-field cron expression, and the panel prints the next three run times.
  1. Frequency: Custom (cron). Replaces the time with a field for a standard cron expression.
  2. Next runs. Check this box every time you write an expression. 30 2 * * 1-5 means 02:30 on weekdays (minute, hour, day of the month, month, day of the week). An invalid expression is refused with a message.

3. Choose where and how long

The second half of the New backup configuration panel
The second half of the panel: where the dumps go, how many to keep and who to tell when one fails.
  1. Storage provider. One of the providers you added, with its service name next to it. Bucket and Directory below are optional and empty by default: Leave empty to use the provider's own bucket and directory. Use them to keep one server's dumps in a folder of their own.
  2. Keep the last. How many backups to keep, from 1 to 365; the form starts at 7. And anything newer than adds an age in days (1 to 3650) so that recent backups are kept even beyond the count. Older archives are deleted from the bucket every night.
  3. Email when a backup fails. Up to five extra addresses, separated by commas. The note says what happens anyway: Owners and admins are always told in the app and by email. Also tell me when a backup succeeds sends a short message to these addresses after every good run.
  4. Run on schedule. On by default. Switch it off to create the configuration without starting the schedule, and use Back up now by hand.
  5. Create configuration. Saves it. The configuration appears in the table with its next run time.

4. Run it once and watch

Open the menu at the end of the new row and choose Back up now. A run appears in Recent backups with the status Running. SrvYard connects to the server, dumps each database, compresses it, uploads it with a short-lived signed link, and checks the result. When the run says Finished, its row shows the duration and the total size.

A few facts about how it works:

  • Each database becomes one .sql.gz archive, and every archive is checked with a SHA-256 sum.
  • The server never receives your storage keys. SrvYard hands it a one-time upload address.
  • Archives larger than 4 GiB are uploaded in parts, and one archive can be up to 1 TiB.
  • A run that is still Running after two hours belongs to a worker that died. SrvYard marks it failed during its regular check, and the next scheduled run starts normally.
  • Dump, upload and restore steps are each limited to 25 minutes. For a database so large that the dump takes longer, use your own tools.

5. Change or pause a configuration

  • Edit reopens the same panel. Changes apply from the next run. Retention changes also apply at the next nightly clean-up.
  • Pause schedule keeps the configuration and its archives but stops new runs. A paused row shows a Paused badge. Use Resume schedule to start again.
  • Delete configuration removes the schedule. The archives that already exist stay in the bucket and in Recent backups, where you can still download or restore them. They are no longer cleaned up automatically, so delete them from the bucket when you do not need them.
Tip

Two configurations are often better than one: a nightly one that keeps the last 14 backups, and a weekly one to a different provider that keeps 8. That gives you both a recent point and an older one when you notice a problem late.

Troubleshooting

  • "Choose one of your storage providers." No provider is selected, or it was deleted. Add one under Settings > Storage providers.
  • The run fails with a message about connection or "mysqldump lost connection". The database server restarted or was overloaded during the dump. Try again at a quieter time, and look at the failure email for the full message.
  • The run fails and the log says the disk is full. The dump needs space in the work folder before the upload. Free some space or move the large database to a bigger disk.
  • The next run time is wrong. The schedule uses the server's timezone, not yours. Compare it with the timezone on the server's Overview tab.
  • The configuration never runs. Run on schedule is off, or it is paused. A paused row shows Paused.
  • The upload fails with Access Denied. The keys of the storage provider changed or lost permissions. Press Verify again on the provider.
Last updated 2026-10-247 min readNeed help? Contact support
PreviousAdd an S3-compatible storage providerNextBack up site files