Restore a database or files

A backup is only worth the day you can restore it. SrvYard restores straight from your bucket onto the server, with a checksum test on the way in and a confirmation step before anything is overwritten. You can restore over the original, or into a brand-new database or directory to look first. The second is almost always the better first move.

This article walks through both kinds of restore, explains what each one overwrites and leaves alone, and gives you a short checklist for the minutes after a restore.

Before you begin#

• A finished backup. Only runs with the status Finished can be restored. Runs whose archives were removed by retention are Expired and cannot.
• A server in the Ready state. A restore on a server that is installing, rebooting or disconnected is refused with the current status.
• The same kind of engine. A MySQL or MariaDB dump goes back into MySQL or MariaDB, a PostgreSQL dump into PostgreSQL. If the engine on the server changed in between, SrvYard says so.
• Permission to restore backups. It is a separate permission from creating them.
• For an encrypted file backup: nothing extra when SrvYard holds the passphrase, which is the normal case. If you restore elsewhere, you need the passphrase you saved.

1. Find the backup#

Open the server, choose Backups and look at Recent backups.

1. Recent backups. Every run with its log. Download an archive or restore it into a database from the row menu. Use the Status filter to show only finished runs.
2. A finished run. Check the date (Started) and the size. A run that is much smaller than usual is a warning sign: do not restore it blindly.

The actions menu is the button at the end of the row. If your window is narrow and the table scrolls sideways, scroll right to reach it. It holds View log, Restore…, a Download list (one entry per database) and Delete backup.

2. Restore a database over an existing one#

Choose Restore… on the run. The dialog says which backup it is (Nightly - all databases from 24/10/2026, 03:30:05) and how it works: The archive is downloaded to the server, checked against its SHA-256 and then loaded.

1. Database in the backup. A run can hold several databases. Pick the one to restore; each shows its archive size.
2. Database to write to. The databases of this server that are ready and of the same engine. It starts on the database with the same name as the archive.
3. The warning. Tables and rows that exist in the backup replace the ones in the database. Anything else in it stays. Changes made since the backup are lost for those tables. Read it twice: a table that exists in the backup is replaced by the backup's version; a table that is only in the live database is left as it is.
4. Type the name to confirm. The button stays disabled until you type the exact database name.
5. Overwrite and restore. Starts the restore. The red colour is intentional.

The restore runs as a job. Follow it in the operation log, where it appears as Restore … into …. The action is also written to the audit log with the backup it came from.

3. Restore into a new database#

1. Into a new database. The second tab of the dialog. The database is created and filled; nothing existing is touched. Add a database user for it afterwards.
2. Name of the new database. Pre-filled with the old name plus _restored. The name follows the usual rules (letters, numbers and underscores, up to 48 characters, not reserved, not already taken).

Use this to check that a backup is good, to recover a single table by copying it out with a SQL client, or to compare old and new data before you decide. Create a user for the new database on the Users tab to connect to it (see Create a database and a user). To make an application use the restored copy, point its DB_DATABASE at it and deploy; to keep the old name, delete or rename the original afterwards.

4. Restore files#

Open Backups > Files, open the actions menu of a finished run and choose Restore…. The dialog lists what the archive Contains and repeats the safety checks: The archive is downloaded to the server, checked against its SHA-256, and every member is inspected before anything is written.

1. Into another directory. The safe choice. Nothing existing is touched.
2. Directory to restore into. Pre-filled with a new folder named after the time, for example /home/srvyard/restores/202610240924. It must be inside the site user's home, and it must not exist yet or be empty. The files come back under their own names, so a site directory lands in <directory>/<site>.
3. Restore. Starts the restore. If the archive is encrypted, a Passphrase field appears: optional: SrvYard has it when the configuration is still in SrvYard.

When it is done, sign in over SSH, look in the folder, and copy back only what you need.

1. Over the original files. Writes the files back where they came from.
2. The warning. Files in the backup replace the ones in /home/srvyard. Files that are not in the backup stay. Changes made since the backup are lost for the files it contains.
3. Type the site user to confirm. The user name, here srvyard, must be typed before Overwrite and restore is enabled.

The files are written as the site's own user, so ownership and permissions stay right. Every member of the archive is inspected before anything is written.

5. After a restore#

Run through this list for a site:

1. Clear caches. php artisan cache:clear and php artisan config:clear, or deploy the site again (Environment > Save and deploy also works).
2. Restart workers so that queue workers do not keep old state: php artisan queue:restart.
3. Check the application. Log in, open a few pages and look at the newest records. If the newest data is missing, you restored an older backup than you wanted.
4. Check migrations. If the backup is older than your latest deployment, the restored database may miss tables or columns the code expects. Run php artisan migrate --force for Laravel.
5. Watch the logs on the site's Logs tab for a few minutes.

Troubleshooting#

• "This backup has no archive of that database." The run failed, the database was not part of it, or retention already removed it. Choose a newer run.
• "Type the name of the database to confirm that it is overwritten." The confirmation does not match. Type the name of the target database exactly.
• "This archive was made on a different database engine than the ones installed now." For example a PostgreSQL dump, with only MySQL installed. Install the right engine from Services, or restore on another server.
• "The server must be ready before you can restore." Wait for the server to be Ready, or reconnect it.
• A new database name is refused. It already exists, is reserved by the engine, or contains characters other than letters, numbers and underscores.
• A files restore says the directory is not empty. Choose a new directory, or empty it first.
• The restore fails in the middle. Open the operation log and read the last lines. Because a restore over an existing database replaces tables one by one, a failure can leave a mix: restore again, or restore into a new database and swap.

Related#

• Schedule database backups: where the archives come from.
• Back up site files: file archives and encryption.
• Retention, failure alerts and testing a restore: practise a restore before you need one.
• Provider snapshots: restore a whole server instead.