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
• 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.

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 toward 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 Restoring with 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.

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 Restoring with mybackup page walks through the offsite side — picking a provider, the credentials you drop in, and pulling copies back down again.

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 Restoring with 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 the fast-backup option

If you've turned on BOA's super-fast cloning and migration option (the ~/static/control/MyQuick.info file, covered under Cloning and moving a site), there's one trade-off worth knowing here: with that option on, a site's 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 still run — the dump is just kept split into per-table files (in a timestamped subfolder) rather than one file. It's a deliberate speed-for-convenience trade; if you rely on the one-click Restore task, leave MyQuick.info off.

There's a way around it too: run the on-demand Backup task and pick Site files with classic mysqldump DB under Backup Mode. That one archive bypasses MyQuick.info and carries a conventional single-file dump the Restore task can use — and it's the only Backup Mode that Restore accepts. 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 last page in this topic 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 toward 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.

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

Where to go next

• 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.