Skip to content
BOA Documentation

Powered by Grav

Exporting your site

Exporting your site

Your site is yours, and that includes the freedom to take it somewhere else — to another host, to another Ægir or BOA server, or back to a plain standalone Drupal. Everything a site is made of sits inside your own account, reachable from your own oN.ftp login, so a complete export is something you do yourself, any time, with no permission to ask for. This page shows you where each piece lives and the exact commands that carry it out.

It's worth taking an export from time to time even if you're going nowhere: a full copy of your site on your own disk is the backup nobody can take away from you.

The three pieces of a site

A Drupal site, on any host, is three things:

  • The database — your content, users, and configuration.
  • The site's own directory — sites/example.com/ on its platform: the settings.php, everything your visitors uploaded, and any site-specific modules or themes.
  • The platform codebase — Drupal core plus the contributed modules and themes the site runs on.

Collect all three and you can stand the site up anywhere Drupal runs. Let's take them in turn.

Piece 1 — The database, in one line

The cleanest way to get the database out is a single command — and you don't even have to be logged in first. From your own computer, or straight from the server the site is moving to:

SH
ssh [email protected] 'drush @example.com sql-dump' > dump.sql

Replace o1.ftp with your login, server.example.com with your server, and @example.com with your site's alias. Your limited shell runs the one command non-interactively and the dump streams back into a local file. That's the whole export.

That's the Drush 8 spelling, right for legacy Drupal 6/7 sites. On a modern Drupal 8+ site, use drush11 and the hyphenated alias form — dots become hyphens except before the final extension, so @sub.example.com is written @sub-example.com (see Drush aliases).

Prefer the browser? The control panel's Backup task can produce a downloadable archive too — with one caveat worth knowing:

The backup archive and the missing database.sql. Your account uses fast, per-table database dumps by default (the MyQuick behaviour described under Cloning and moving a site). A side effect: the archives Ægir makes during everyday tasks no longer contain a single database.sql file to fish out. If you want one archive holding the files and a classic database dump, run Backup and pick the Site files with classic mysqldump DB mode — that one archive bypasses the fast method — then download it from the site's Backups tab as described in Backing up and restoring in the UI. For anything big, the sql-dump line above is still the lighter, faster route.

Piece 2 — The site's directory

Your login sees every site of yours through a set of shortcuts in your home directory:

  • ~/clients/ — one folder per client, holding a shortcut to each of that client's sites.
  • ~/platforms/ — one folder per platform release, holding each built-in platform's sites/ tree.
  • ~/static/ — your own space, where custom platform codebases live in full.

Those shortcuts (and plenty of paths behind them — a site's files/ folder, for one, is itself a link into your central file store) are symlinks, which is why one rsync flag is non-negotiable: -L, which copies the real files a link points to rather than the link itself. Forget it and you'll arrive home with a bag of shortcuts pointing at a server you just left.

So, from your own computer:

SH
rsync -avzuL [email protected]:clients/myclient/example.com ./

That lands a complete example.com/ site directory — settings, uploaded files, the lot — next to wherever you ran the command. The same works with a ~/platforms/... path to the site's folder in its platform's sites/ tree, or with the full system path to the platform (you'll find that path on the platform's page in the control panel, or from drush @example.com dd in your shell).

Piece 3 — The platform codebase

Which road to take depends on whose platform the site runs on:

  • Your own custom platform (under ~/static): the whole codebase is yours, so rsync it out directly. If other sites share the platform, their site directories ride along inside sites/ unless you exclude them:

    SH
    rsync -avzuL --exclude=sites/other.com --exclude=sites/another.com \
[email protected]:static/platforms/mysite ./

    One --exclude=sites/name per site you don't want. (And if you built the platform from a git repository or a Composer project, you may not need to copy it at all — rebuild it on the destination from the same source.)

  • A built-in platform: the codebase is a stock build your host manages, and what's genuinely yours on it is the sites/ tree — your site's directory (piece 2) plus anything you added at the sites/all level, both reachable through ~/platforms/. There's no need to haul the shared core and contrib across: note the exact core version (drush @example.com status tells you), build or download the same release on the destination, and drop your sites/ pieces into it.

Landing it somewhere else

With the three pieces in hand:

  • On another Ægir or BOA server you control, follow Importing an existing site — it's this page in reverse, including how to sort out hardcoded file paths after the move.
  • As a standalone Drupal site, place the codebase, put your site directory into sites/ (renaming it to sites/default is the usual move for a single-site setup), import the database, and review settings.php — the database credentials will differ on the new host, and an Ægir-written settings.php carries platform-specific include lines you'll want to replace with a plain one. If content still points at sites/your-old-name/files, a search-and-replace on the dump before importing settles it.

Nothing about the export changes anything on the source — your site keeps running here until you decide otherwise.

Where to go next

© 2026 BOA Documentation. All rights reserved.