Backing up & restoring

Losing a site is the thing that keeps every site owner up at night — so BOA is built to make sure you almost never can. Copies of your sites and files are made for you, automatically, every night, and you have more than one way to get a site back when you need it.

This topic is about all of that:

• what's kept for you without you lifting a finger
• the backup and restore buttons in your control panel
• sending copies offsite to your own cloud storage
• pulling files back when something goes wrong
• reading those offsite copies from your own computer, with no server involved at all
• and, at the end, a look at where your uploaded files actually live and why they stay safe through rebuilds

The good news up front: the everyday backups just happen. Your active sites' databases are dumped for you every night and kept in your own account. You don't schedule anything, you don't run a command, and you don't touch the server.

What this topic adds is the rest — how to make a fresh backup on demand, how to roll a single site back to an earlier copy from the web UI, how to keep copies offsite, and how to recover files if you ever need to.

Two worlds: the control panel and your shell

Backups in BOA live in two places, and it helps to know which is which from the start:

• The Ægir control panel (web UI). This is where you make an on-demand backup of one site, roll a site back to an earlier backup, download a backup archive to your own computer, or clean up old backups you no longer need. Point-and-click, one site at a time.
• Your own shell and files (the oN.ftp login). This is where your nightly database copies land inside your account, where you set how long they're kept, where you drop cloud-storage credentials to send copies offsite, and where you run a restore of your account files from that offsite storage. All of it from your own login — no root, never the server.

Most of the time you'll live in the first world. The second is there for the bigger "put it back" moments and for keeping copies somewhere other than the same account. And for the day neither is reachable, there's a third place: your own computer, reading the offsite copies directly from your cloud storage — that's Disaster-proof access, the last page in this topic.

What's already kept for you

You start out protected without doing anything:

• Nightly database backups. Every night, the database of each of your active sites is dumped and saved inside your account, under ~/static/files/dbackup/. These are kept for 14 days by default. (Databases belonging to sites you've disabled are still backed up at the system level, but they're not added to your own dbackup folder.)
• A backup before risky moves. When you restore a site to an earlier copy from the control panel, BOA quietly makes a fresh backup first — so the state you're leaving is never lost. Deleting a site keeps a final pre-delete backup too.

That's the safety net you get by default. The pages in this topic are about using it and adding to it.

These backups count towards your space. The nightly database copies in ~/static/files/dbackup/ live inside your account, which means they count against your plan's file-space limit like everything else you store. If you're getting close to your quota, the simplest lever is to shorten how long they're kept — that's a one-line file you control, covered on the Off-site backups & mybackup page.

Making and restoring a backup from the control panel

Everything a single site needs is on that site's node in the Ægir web UI, under its task links:

• Backup — makes a backup of that site right now, that you can restore to later.
• Restore — rolls the site back to one of its earlier backups. BOA takes a fresh backup before it does this, so you never lose the current state by rolling back.
• Delete backups — clears out old backups for the site that you no longer want taking up space.

Once a backup exists, you can also export and download it to your own computer from the Backups tab on the site node — handy for keeping a copy off the platform entirely, or moving a site somewhere else. None of this needs your shell; it's all in the browser.

Sending copies offsite (optional but recommended)

The nightly copies live in the same account as your sites — great for quick rollbacks, less great if you want a copy somewhere completely separate. BOA can also push encrypted backups to your own cloud storage — Amazon S3, Backblaze B2, Wasabi, DigitalOcean Spaces, Google Cloud Storage, Azure, and more.

Hosted and PRO only. This extended off-site subsystem is included with every hosted BOA account; on self-hosted servers it unlocks with a BOA PRO licence — it's the one extra that isn't part of the free stack. Everything else on this page works everywhere.

You turn this on by dropping a small credentials file for your chosen provider into a folder in your own account (~/static/control/remote_backups/credentials/) and locking it down so only you can read it.

From then on your backups are encrypted and copied offsite for you on a schedule — you don't run the upload yourself. The Off-site backups & mybackup page walks through the offsite side — picking a provider, the credentials you drop in, and pulling copies back down again.

And because those offsite copies are standard encrypted Duplicity archives sitting in your own bucket, they stay readable even with no BOA server in the picture at all — the truly disaster-proof route, covered on Disaster-proof access to your off-site backups.

Getting your files back with mybackup

When you need to pull files back from that offsite storage, you use one simple command from your own oN.ftp shell:

mybackup restore <service>

where <service> is the provider you set up (for example aws, b2, or wasabi). BOA doesn't run the restore on the spot — it queues it and the system carries it out shortly after, then emails you when it's done.

Restored files always land in a safe, separate folder in your account (~/static/restores/), so a restore never overwrites what you already have — you get your files back beside your live ones and decide what to do with them.

You can restore everything, or just one folder, or a folder as it was a few days ago — all with the same command. The Off-site backups & mybackup page has the exact patterns.

mybackup restore is your login only. You run it as oN.ftp, it only ever reaches your account, and it can't touch anyone else's. There's no "backup" verb to run by hand — the making of backups is automatic; mybackup is purely for getting things back.

A note on fast database dumps

Your account uses BOA's super-fast per-table database dumps by default (the ~/static/control/MyQuick.info file, created for you and covered under Faster cloning and migration), and there's one trade-off worth knowing here: a site's everyday archive no longer carries a single complete database dump, which means the control panel's Restore task can't rebuild that site from its archive.

Your nightly database backups aren't affected by this choice and still run: each night's dump lands under ~/static/files/dbackup/ as a single compressed archive per database, with the fast per-table dump packed inside. The archive behaviour is a deliberate speed-for-convenience trade; if you'd rather every archive on your account carried a classic single-file dump, opt out with ~/static/control/MyClassic.info.

When you want a snapshot that rolls the whole site back in one click, run the on-demand Backup task and keep the preselected Site files with classic mysqldump DB under Backup Mode. That one archive bypasses MyQuick.info and carries a conventional single-file dump alongside your files — the two partial modes are restorable too, each bringing back exactly the half it holds. Fast dumps keep working for everything else you do.

And where your files actually live

There's one more piece worth knowing, and it's the reason backups here are so painless: your uploaded files don't live inside your site's code folder. Everything your visitors upload, plus the image derivatives, aggregated CSS/JS, and private files Drupal generates, is kept in your own file store and linked into each site.

Because the real data sits outside the code, a platform rebuild or a Drupal upgrade replaces the code but leaves your files exactly where they were — nothing to export, copy, or re-import. It's automatic, and there's nothing to switch on.

The Your files & storage page walks through what you'd see if you went looking, and the one optional knob (sharing files between two of your own sites).

Good to know

• Backups are automatic; restores are on you. You never schedule or trigger a backup — nightly database copies and the pre-restore/pre-delete safety copies all happen for you. The commands and buttons in this topic are about getting things back, not making them.
• Restores never overwrite. Whether it's the control panel's Restore (which backs up first) or mybackup restore (which drops files into a separate restores folder), you never lose your current state by recovering an older one.
• Watch your quota. The local dbackup copies count towards your space. If you're tight, shorten retention with dBackupCycle.info, delete old per-site backups from the control panel, or send copies offsite and trim the local ones.
• Offsite is your storage, your keys. The cloud credentials you add are yours; BOA encrypts and ships copies to your bucket. If you ever suspect a key is compromised, rotate it in your provider and update the credentials file.

When it's not yours to do

Nearly all of this is yours from your own login and the control panel. A couple of things sit on the server side by design:

• Confirming the nightly/offsite backup schedule is actually running. If you're ever unsure that scheduled backups are firing for your account, that's a quick check your host does — open a support request and ask them to confirm.
• Reviewing a rejected line in your offsite backup config. If a line in your include/exclude or credentials file was rejected (for example, a path outside your own folders, or a forbidden character), the detail is logged where only your host can see it — describe what you set and ask them to check.
• Getting a copy of your off-site backup passphrase. BOA generates and guards it server-side; if you want the server-independent copy for your own password manager, ask your host to place a readable copy in your account — the exact request to send is on Disaster-proof access.

None of these is a workaround to go hunting for; one short support request and your host handles it.

Where to go next

• Reading your offsite backups from your own Mac, Windows PC or Linux machine — with no server involved — is Disaster-proof access.
• Cloning and moving whole sites — a close cousin of backup/restore — is under Cloning and moving a site.
• Getting into the oN.ftp shell where mybackup runs is covered in Connecting to your account.
• The retention knob and other control files you set yourself are also gathered under Tuning your site & platform.