Skip to content

← Documentation

Databases and applications

An open database file is not a backup: in the middle of a write, the copy comes out inconsistent. The plan runs the dump first and backs up the dump file. On Zimbra, the agent itself exports each account.

PostgreSQL, MySQL, MariaDB and MongoDB

In Plans → New plan, on a Linux server, the Commands before and after the backup section has ready-made recipes. Pick the database and click Fill in the commands: the panel fills in the command that creates the dump before the backup, the one that deletes it afterwards, and adds the dump folder to the plan. Check what was written before saving.

  • PostgreSQL: pg_dumpall as the postgres user, every database in one file, in /var/backups/arkame/postgres.
  • MySQL and MariaDB: mariadb-dump or mysqldump, whichever is there, with --single-transaction, in /var/backups/arkame/mysql.
  • MongoDB: compressed mongodump, in /var/backups/arkame/mongodb.

The recipes never put a password in the command. If your database needs one, put it in the database's own credentials file (.pgpass, /root/.my.cnf), with permission 600. Saving commands requires being the organization's owner or an admin plus the two-step verification code, and does not apply to the Docker agent.

SQL Server (Windows)

With Arkame agent 0.5.0 or newer, the SQL Server recipe takes a copy-only backup (COPY_ONLY), which does not interfere with SQL Server's own backups, in C:\ProgramData\Arkame\dumps\sqlserver. It asks for the database name and, if there is one, the instance (SQLEXPRESS).

The agent runs as Local System: in SQL Server, give the NT AUTHORITY\SYSTEM login the db_backupoperator role on the database. It needs sqlcmd on the server.

Zimbra

With Arkame agent 0.5.0 or newer on a Zimbra server, the Zimbra recipe shows up in the plan. The agent talks to Zimbra's own API on localhost and exports account by account, with no zmmailbox and no service stop.

What goes into the backup, per account

  • The mail from every folder, Trash and Junk included, one file per month: a closed month does not change and is not uploaded again.
  • Contacts, calendar, tasks and documents.
  • The account's settings (name, quota, preferences, aliases, class of service), incoming and outgoing filters, and signatures.
  • The list of protected accounts, so the panel can show which ones are in the backup, how many months each has, and which ones failed.

What does not

  • The password: Zimbra's API does not hand it out, and a backup holding everyone's password hash would be one more place for it to leak. A recreated account gets a random password; set a new one in the Zimbra console.
  • Message subjects and senders never reach the panel: it only sees account names, months and sizes.

How to set it up

  1. In Plans → New plan, choose the Zimbra server and, under Commands before and after the backup, the Zimbra recipe.
  2. Choose all mail or the last 1, 2, 3, 5 or 10 years, and the accounts to leave out (system accounts already are).
  3. Click Fill in the commands, check and save. The plan backs up /var/backups/arkame/zimbra.

The first export of a large server can take a few sessions: the command stops before its deadline (up to 2 hours) and the next session picks up where it left off, starting with the accounts that went longest without a backup. Every so often the agent re-checks a closed month and resends it if it changed: an old message migrated into the mailbox makes it into the backup.

On the plan page, the Zimbra accounts card shows each account from the last backup, its months, its size, and those that failed or left the backup.

Tested on Zimbra 8.8.15, 9 and 10.1. The folder keeps a copy of the mailboxes on the server's disk: check the free space before turning it on.

More than one mailbox server: install the agent and create the plan on each mailbox server. Each agent exports only the accounts whose mailbox lives on it (the zimbraMailHost attribute); the others show in the summary as skipped, with the server that holds them, not as failures. To restore, use the server where the account's mailbox is today: a deleted account may be recreated by Zimbra on another mailbox server, and then importing the mail is not guaranteed. This setup has not been tested on a real install yet; talk to support before you turn it on.

Restore a Zimbra account

  1. In the panel, under Restore, restore the account's contas/ folder (named after its address) to a folder on the server, for example /restauracao.
  2. On the server, run:
sudo arkame-agent zimbra restore --from /restauracao/contas/maria@empresa.com.br
  • An account that exists only gets the mail, contacts and calendar back. --settings also reapplies settings, filters and signatures (never the password).
  • An account that no longer exists is recreated with its previous settings, class of service, aliases, filters and signatures, and a random password.
  • Anything that sends mail out (forwarding, auto-reply, a redirecting filter) only comes back with --with-forwarding: a restore must not start sending someone's mailbox elsewhere unless you ask.
  • Into another account: --to brings the mail into an existing account without touching its settings.
sudo arkame-agent zimbra restore --from /restauracao/contas/maria@empresa.com.br --settings
sudo arkame-agent zimbra restore --from /restauracao/contas/maria@empresa.com.br --to arquivo@empresa.com.br

To see the accounts the backup protects on this server:

sudo arkame-agent zimbra list

In the cloud or in a local copy

The dump and the Zimbra export go to the plan's storage like any other folder: your cloud bucket. To also keep a copy on the server itself, for the fastest restore, create a second plan with Also copy to another storage and pick the local copy (agent 0.5.0 or newer).

Ready to protect the database?

Recipes live in the server's plan. Saving commands requires being an owner or admin plus the two-step verification code.

Create a plan →