Back up site files

A site's code lives in Git, and its database has its own backups. What is left are the files that only exist on the server: images that users upload, generated invoices, a WordPress wp-content/uploads folder, a Laravel storage/app directory. Lose them and nobody can recreate them. A file backup copies those folders to your own bucket on a schedule, using the same storage provider and the same retention rules as database backups.

This article creates a file backup configuration, explains which paths to choose and which to leave out, and shows how encryption works.

Before you begin#

• A verified storage provider. See Add an S3-compatible storage provider.
• A site on the server. File backups are tied to a site (or to the Linux user that owns one), because the archive is made, and later restored, as that user.
• Know where your data lives. For Laravel it is usually shared/storage/app (and shared/storage/app/public for public uploads); for WordPress, the uploads folder inside the site directory. Open the site's Overview to see its path.
• Permission to manage backups on the server.

1. Open the Files section#

Open the server, choose Backups, and then Files.

1. New configuration opens the form from step 2. A server can have up to 20 file backup configurations.
2. A configuration. The name, the site it belongs to (here Shop uploads of acme-shop.example), the paths it copies, the schedule, the next run, where it is stored and how many archives it keeps.
3. Recent file backups. Every run with its log. Download an archive or restore it into another directory (or over the original files) from the row menu. The status filter narrows the list to failed or running runs.

2. Create the configuration#

Press New configuration. The panel says: Directories are packed on the server as the site's own user, compressed and uploaded straight to your bucket. The server never sees your storage keys.

1. Site. The site whose files you want. The list shows each site with its Linux user. The archive is made as that user, so it can only read what the site itself can read.
2. Paths. One per line, up to 20. Every path must be inside the user's home folder (/home/<user>): Only paths inside /home/srvyard can be backed up. Symbolic links are saved as links, never followed.
3. The quick buttons. + Site directory adds the site's own folder, + Shared storage adds the shared storage folder of a Laravel site and + Whole home adds the whole home folder of the user. Use them as a start and edit the lines.
4. Leave out. One pattern per line, matched anywhere below the paths above: names or relative paths such as node_modules, storage/logs or *.log. The form starts with node_modules, vendor, .git, .env, storage/logs and storage/framework/cache: things you can rebuild or that must not travel.

Choose paths that are as narrow as possible. Backing up the vendor folder or the Git history wastes bucket space and time, and a whole-home backup of a server with many large sites can take longer than a single backup run is allowed to take.

3. Encrypt, schedule and store#

Scroll to the rest of the panel.

1. Encrypt archives (AES-256). Encrypted on the server, before upload. Switch it on and a Passphrase field appears. Leave it empty and SrvYard generates one; type your own and it must be at least 12 characters. SrvYard keeps an encrypted copy so scheduled backups can run and restores can decrypt for you, but it shows a generated passphrase once, in a dialog titled Save the passphrase now. Copy it into your password manager.
2. Frequency and Time (UTC). The same choices as for databases: Hourly, Daily, Weekly or Custom (cron), with the next three runs listed so you can check them.
3. Storage provider. The bucket to use, with optional Bucket and Directory to override the provider's defaults. Below it come Keep the last and And anything newer than for retention, Email when a backup fails and the Run on schedule switch. They behave exactly as described in Schedule database backups.

Press Create configuration. Open the row's menu and choose Back up now to take the first archive straight away, and check that its size looks right.

1. Encrypted. An encrypted configuration carries a lock badge under its name. The archives are encrypted before they leave the server, so the bucket only ever sees ciphertext. Scheduled runs and restores started in SrvYard use the stored copy of the passphrase; to restore an archive somewhere else you need the passphrase you saved.

4. Check the result#

A run turns Finished when the archive is packed, uploaded and its SHA-256 checksum is recorded. The row shows the duration and size. Compare the size with the folder on the server (du -sh): a backup that is a few kilobytes when the folder has gigabytes means your paths or exclusions are wrong.

A failed run shows the error in the list, for example tar: ... file changed as we read it. That message means files were being written while the archive was made. It is common for a busy uploads folder, and the next run usually succeeds. If it fails every time, back up at a quieter hour or exclude the folder that changes constantly (logs, caches, sessions).

Restoring is covered in Restore a database or files. Do it once, into another directory, before you need it.

Troubleshooting#

• "Only paths inside /home/…". A path points outside the site user's home. Use the site's own folders.
• The Site list does not show my site. The site is not on this server, or it is still being created. File backups belong to the server of the site.
• "Use a passphrase of at least 12 characters." Make the passphrase longer, or leave it empty to have one generated.
• The archive is far smaller than expected. Symbolic links are saved as links, not followed, so a path that is only a link to a folder elsewhere saves just the link. Use the real path.
• "tar: file changed as we read it". A file changed during the archive. Try again, or exclude that file or folder.
• The run says the backup is too large or runs out of time. Each step is limited to 25 minutes. Split a big folder into several configurations, or leave out what you can rebuild.

Related#

• Add an S3-compatible storage provider: where the archives go.
• Restore a database or files: bring files back, into another directory or over the originals.
• Retention, failure alerts and testing a restore: keep the right number of archives.
• Schedule database backups: the same form for databases.