Skip to content
Manager for Craft

Backups

Encrypted Craft CMS database backups

Manager can ask a Craft site to back up its own database, on a daily or weekly schedule or on the day, encrypt the result on that server, and upload it to storage you control. It never holds a database password, and it cannot read the artefact it stores.

Start free trial Backups documentation

Fourteen days, no card. Craft CMS 5 and later.

The problem with backing up a fleet

Most tools that back up a database for you need the credentials to reach it. That means every site you manage puts a working database password into a third party, and a breach of that third party is a breach of all of them at once.

The alternative is a per-site cron job writing to a bucket somewhere, which works until it stops working. A nightly dump that has been failing since Tuesday looks exactly like one that ran, because nothing reports on it.

How a backup runs

  1. You authorise the site

    Backups are off until an administrator turns them on for a named site. That takes a recent password confirmation, the site name typed out, an acknowledgement of what a database backup contains, and a reason that goes into the audit log.

  2. You set a schedule, or ask on the day

    Daily or weekly, per site, at an hour you choose in your organisation's own time zone. The scheduler runs hourly and decides site by site, so a fleet of forty does not read forty databases at 03:00.

  3. Manager queues a job with no parameters

    The backup job carries no destination, no path and no command. There is nothing in it for an attacker to change, because there is nothing in it.

  4. The site backs itself up

    The connector asks Craft to run its own db/backup. No shell access, no mysqldump guesswork, no assumptions about where the database lives.

  5. The dump is encrypted before it moves

    The connector generates a fresh key, encrypts the dump as an authenticated stream in 1 MiB chunks, and seals that key to your recovery keys. Up to eight recipients, so more than one person can open it.

  6. Sizes and checksums are declared first

    The connector states what it is about to send and signs that statement. Manager then hashes the bytes as they arrive and keeps the artefact only if the two agree.

  7. The plaintext dump is deleted

    Whether the upload succeeded or failed, the unencrypted file does not stay on your web server.

What protects the backup

No database credentials, anywhere

There is no column in the schema to put one in. A test walks the live database on every run to keep that true.

Recovery key pinning

You pin the fingerprints of the keys allowed to receive a backup in config/manager-connector.php, in version control. The connector checks every key Manager offers against its own key material and refuses the whole backup before taking the dump if an unpinned key appears.

Pinning cannot be changed from the control panel

The fingerprint list is a config file setting only. A build check asserts it never appears in the settings template, so a hijacked control panel session cannot re-point your backups.

Retention you set, applied nightly

Two settings, and whichever keeps an artefact alive wins: 30 days and three copies by default. Pruning runs at 03:30 and destroys the keys as well as the data.

A schedule that refuses rather than queues

If there is no active recovery key, no live connector, no granted capability, or a backup still outstanding for that site, the scheduler skips it and says so. A nightly failed job whose real cause is an unset key is worse than a clear refusal, and two concurrent dumps of one database is how a backup schedule becomes an outage.

Offline recovery

manager-restore is a separate MIT-licensed command line tool that opens no network sockets. It verifies, inspects and decrypts an artefact on a machine that has never spoken to Manager.

No restore button, on purpose

Manager cannot write to your site. Retrieval is a deliberate command you run: manager:backups:fetch streams, decrypts, verifies against the checksum taken on your server, and writes nothing if verification fails.

The outcome

You get a backup of every managed site that you can open and nobody else can, taken by Craft itself, verified on arrival, and pruned on a schedule you set. Manager stores, verifies, serves and deletes something it cannot read.

Read how it works

The documentation lives in the public repository, next to the code it describes, and every page carries a link to edit it.

Backups documentation

Related

See your whole fleet in about ten minutes

Add a site, install the connector with Composer, paste the one-time code. The first report arrives on the next run. Fourteen days free, no card, and nothing on your sites changes.

Start free trial Read the setup guide

Craft CMS 5 and later. Read-only by default. AGPL-3.0-or-later.