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:

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.

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.

Sharing files between two of your own sites (optional)

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:

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, the intentional cross-site link for <site> is left in place instead of being replaced with a separate copy. Remove the file to go back to independent copies.

Two things worth remembering:

  • A clone always gets its own copy, share file or not — a freshly cloned site never inherits a share.
  • 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.

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.