SupportConsole
llms.txtSign in

Import and export a database

llms.txt

Moving data in and out of a database is a daily job: a copy for a developer, a dump from your old host, a safe place to test a risky migration. SrvYard has no "Import" or "Export" button on the Databases tab, but it gives you everything you need to do both without guessing: backups that produce a downloadable SQL file, a restore that can write into a brand-new database, and a safe tunnel for your own tools.

This article shows how to export with a backup, how to import a dump you already have, and how to use Into a new database to check a backup before you rely on it.

Before you begin

1. Export: take a backup and download it

The export of a database is a backup run. Open the server and choose Backups. The Databases section holds the backup configurations on top and every run below.

The Backups tab of a database server
The Backups tab: the schedules on top and every run below, each with its size.
  1. New configuration creates a schedule. You need one before you can take a backup, even if you only want a single export.
  2. A configuration is one row: its name, which databases it covers, the schedule, where the files go and how many it keeps. The menu at the end of the row has Back up now, Edit, Pause schedule and Delete configuration.
  3. Recent backups lists every run with its status, start time, duration and size. Press the menu at the end of a finished row for View log, Restore…, a Download section with one entry per database (with its size), and Delete backup.
The New backup configuration panel
To export on a schedule, create a backup configuration: choose the databases, when to run and where to store the dumps.
  1. Databases. Leave All, including new ones on, or switch it off and tick the databases you want.
  2. Frequency. Hourly, Daily, Weekly or Custom (cron). Times are in the server's timezone, which is UTC unless you changed it. The panel prints the next three run times so you can check them.
  3. Storage provider. The bucket the dumps are uploaded to. Bucket and directory can be left empty to use the provider's own.

Press Create configuration, open the configuration's menu and choose Back up now. The dump is compressed on the server and uploaded straight to your bucket. SrvYard never sees your storage keys on the server. When the run shows Finished, open its menu and choose the database under Download: SrvYard hands your browser a signed link straight from the bucket, valid for five minutes, and the file arrives as one .sql.gz per database, named like shop_production-20261024-023000.sql.gz.

Note

Every download is written to the audit log. A very large database can be too slow for a single run: each remote step (dump, upload, restore) is limited to 25 minutes. If a backup of a huge database keeps timing out, export it with your own tools through a tunnel instead.

2. Import a dump you already have

SrvYard does not upload SQL files for you, because a safe import needs your own tool and your own database user. Choose one of two routes.

Through an SSH tunnel from your computer. Open the tunnel as described in Remote access, phpMyAdmin and SSH tunnels, then load the file from another terminal. For MySQL and MariaDB:

gunzip < shop_production.sql.gz | mysql -h 127.0.0.1 -P 3306 -u shop_user -p shop_production

For PostgreSQL, use psql with the tunnel on port 5432:

gunzip < shop_production.sql.gz | psql -h 127.0.0.1 -p 5432 -U shop_user shop_production

On the server. Copy the file up with scp, sign in with SSH and run the same command with -h 127.0.0.1 against the local engine. This is faster for big files because the data never leaves the machine again.

Create the target database and a user first, with Full access so that the dump can create tables. An import into an existing database adds to what is there: it does not empty it first. For a clean start, create a new database.

Tip

If the dump is larger than a few hundred megabytes, compress it (gzip) before you upload it and import on the server. It is quicker, and a dropped connection does not leave a half-finished import.

3. Restore a backup into a new database

The restore dialog is also the safest way to look at old data. Open a finished run's menu and choose Restore….

The Restore a backup dialog
Restore over an existing database (you type its name to confirm) or into a new database.
  1. Database in the backup. When a run holds several databases, choose the one you want. The size is shown next to each.
  2. Over an existing database. Writes the backup into a database that already exists. SrvYard warns that tables and rows from the backup replace the ones in the target, that anything else stays, and that changes made since the backup are lost for those tables. You must type the database name to confirm.
  3. Into a new database. Creates a database and fills it. Nothing existing is touched.
Restoring into a new database
Into a new database creates a fresh database and loads the backup into it; nothing existing is touched.
  1. Name of the new database. Pre-filled with the old name plus _restored. Use letters, numbers and underscores, up to 48 characters. The name must not exist yet and must not be one the engine reserves.
  2. Restore. Queues the restore. The archive is downloaded to the server, checked against its SHA-256 and then loaded. Watch it in the run log, or on the Databases tab, where the new database appears.

The new database has no user yet. Add one on the Users tab to connect an application or a tool to it. The backup can only go into an engine of the same family it came from: a MySQL dump goes into MySQL or MariaDB, a PostgreSQL dump into PostgreSQL.

Tip

Restoring into a new database now and then, and checking that the tables and the newest rows are there, is the best test that your backups work. See Retention, failure alerts and testing a restore.

Troubleshooting

  • The download does nothing, or the link has expired. The link is valid for five minutes. Choose the database under Download again.
  • "This backup has no archive of that database." The run failed, or it is older than the retention you set and its files were deleted. Choose a newer run.
  • The restore button is greyed out or says the server must be ready. The server is installing, rebooting or disconnected. Wait for the Ready badge.
  • "A database named … already exists on this server." Pick another name for the new database, or restore Over an existing database.
  • The import stops with "Access denied". The user lacks the privileges, or you connected as another user. Use a user with Full access to the target database.
  • "ERROR 1153: Got a packet bigger than 'max_allowed_packet'". The dump has very large rows. Increase max_allowed_packet in the engine's configuration, restart, and import again.
  • Characters look broken after the import. The new database uses another character set than the old one. Create it with the same character set and collation, usually utf8mb4.
Last updated 2026-10-247 min readNeed help? Contact support
PreviousRemote access, phpMyAdmin and SSH tunnelsNextRedis, Memcached and cache services