How your site's files are stored

Every file your site writes — everything users upload, plus the image derivatives, aggregated CSS/JS, and private files Drupal generates — lives in your files and private directories. On this platform those two directories are kept safe for you, in a way that means they survive platform rebuilds and upgrades without you doing anything.

This page explains what's happening behind the scenes, what you'd notice if you went looking, and — the short version — why it's nothing you ever have to manage.

The short version

Your uploads are stored in your account's own file store and linked into each site. Drupal reads and writes them exactly as normal, and because the real data lives in your account (not inside the site's code folder), it stays put when the platform underneath your site is rebuilt or upgraded. It's automatic, and there's nothing to switch on.

What you'd notice if you looked

If you connect over SSH or SFTP and look inside one of your site directories, you'll see that files and private are symbolic links (shortcuts) rather than plain folders — something like:

TXT

files    -> .../static/files/<your-site>/files
private  -> .../static/files/<your-site>/private

That's expected and correct. The link points at where your real files live in your account's store, and Drupal follows it automatically. Your uploads, image styles, generated CSS/JS, and private files all work exactly as they always have — you won't see any difference on the site itself.

You never have to create, repair, or point these links yourself. New sites are set up this way the moment they're created, and the platform keeps them tidy for you.

Why this keeps your uploads safe

When your site's code is redeployed — a new platform, a Drupal core update, a migration to a fresh codebase — the site's code folder is replaced, but your files are not, because they were never inside that folder in the first place. They live in your store, and the link is simply re-created pointing at the same data. So:

A platform rebuild or upgrade doesn't touch your uploads.
Your backups stay fast and consistent, because your files sit in one stable place.
You don't have to copy, export, or re-import anything to protect them.

When you clone a site

When you clone one of your sites, the clone gets its own separate copy of the files. It never shares the original's uploads: change or delete files on one site and the other is completely unaffected. A freshly cloned site always starts with its own independent copy — even if the original was set up to share files with another site (see below), a clone never inherits that arrangement.

If cloning is new to you, the how-to lives in Cloning and moving a site.

When you migrate or rename a site

Moving a site to another platform, or renaming it — for example promoting a staging site onto your live domain — works the same gentle way. The moved or renamed site keeps its own files, linked into its own store. You don't lose your uploads and there's nothing you need to do to bring them along. After a rename the old name's store is set aside into the same dated archive a delete uses, at once (the task log says RENAME/STORE/ARCHIVED); as on a delete, a store another of your sites still reads — through a share you set up, or because the renamed site's own copy could not be completed — is left where it is instead, and the task says so.

Reusing an old site's name is safe too: if you delete a site and later create a new one with the same name, the new site starts clean with its own fresh files. Anything left over from the previous site of that name is set aside for you automatically and is never mixed into the new one — so there's nothing to clean up first.

When you restore a backup

Restoring a backup from the panel puts the files the archive carries into the site's own store, and whatever the store held before the restore is set aside rather than deleted — so a restore you regret has not destroyed anything. A database-only backup carries no files at all: restoring one brings the database back and leaves your current uploads exactly as they are, which is usually what you want when it is the content you are rolling back, not the pictures. A share you set up deliberately (below) is never forced open by a restore: unlike a clone, the restore task never breaks a share on purpose. It can still end one by accident — a backup taken with files in it followed the link when it was made, so restoring that archive hands the site its own copy of what it was reading. Restore a database-only backup and the link, and the share, stay exactly as they were.

When you delete a site

Deleting a site removes its code folder and the two links, never the uploaded data. The Delete task itself sets the site's store aside into a dated archive under static/files/.archived/ at that moment (its log says DELETE/STORE/ARCHIVED), so nothing is left at the site's name; a store that another of your sites reads through a share (below) is left in place instead and the task says so (DELETE/STORE/LEFT), because that is a decision for you. The nightly maintenance on the servers we host archives any leftover the same way as a safety net (on a self-hosted server that nightly pass is an opt-in your operator turns on per box). Pruning the archive is a job for the people who run your server, after review — nothing there is removed by a schedule. Reusing the name is safe either way (above): whenever a new site of the same name is created, whatever is left at that name is archived aside first, so the new site never inherits the old one's files.

Sometimes you may actually want a second site to read another site's files — a staging copy that should show the live site's uploads, say. By default each site keeps its own copy, so to make a share deliberate and lasting you create a small control file in your account's static/control directory, named for the site whose files are being shared:

BASH

touch /data/disk/your_username/static/control/share.files.<site>.info

Replace your_username with your account name and <site> with the site whose files you want the other site to use. While that file exists, day-to-day maintenance leaves the intentional cross-site link for <site> in place instead of replacing it with a separate copy. Remove the file to go back to independent copies.

Two things worth remembering:

Site-copying tasks always produce an independent copy, share file or not: a clone, a migrate or rename to another platform, and the Backdrop upgrade task each give the resulting site its own files. So if you migrate or rename a site that was sharing, re-create the share afterwards if you still want it — the moved site otherwise simply carries on with its own full copy.
This is an advanced, deliberate choice. If you're not sure you need it, you don't — the default (each site with its own files) is the right setting for almost everyone.

There is also an account-wide opposite: if you prefer your new sites to get plain directories instead of the managed files/private symlinks altogether, create /data/disk/your_username/static/control/no_native_files_symlink.info — while it exists, newly created sites use plain directories; remove it to restore the default for sites created afterwards. Same advanced-choice warning applies, doubled: the managed symlinks are what your account's storage layout is designed around.

If something looks wrong

In normal use there is nothing here for you to fix — the linking and cleanup are automatic. If a site's files or private link ever looks broken, or uploads seem to have gone missing after a platform change, that's a job for the people who run your server, not something you can repair from your account. Open a support request and describe what you're seeing, and they'll sort it out.

For everything else about protecting your data, see Backing up and restoring in the UI and the shared Reference.