GuidesSet up backups
On this page0

Guide

Set up backups

Keep an encrypted copy of every backup in a storage bucket you own, so you can recover even if your server is lost. This guide uses Amazon S3; other destinations are listed below.

For: IT administratorPlan: All plans
A new instance stays locked until this guide is done as far as step 9. Until a first backup has reached storage you own and been verified there, only the screens needed to finish open. Both recovery keys then have to be shared out within 14 days (steps 10 to 12), or Zonitix locks again until they are. The details, and what an instance that was already in use sees instead, are under The two stages, and what is closed meanwhile.

Before you start

  • This guide assumes you can use your storage provider’s console (for Amazon S3, the AWS console) to create a bucket, a user and an access key; if you do not look after your company’s cloud account, do this together with the person who does. What to ask them for is in Hand the technical setup to whoever helps you with IT.
  • An administrator account in Zonitix, or a role allowed to approve system updates. Without it, the “Off-box destination” button is hidden.
  • An AWS account where you can create an S3 bucket and an IAM user, or an account with one of the other destinations listed under Say where.
  • For steps 10 to 13: at least three people with Zonitix accounts in total. Three of them are the trustees, and each must be a different person; a trustee needs no special role. Two of them are administrators, or hold a role that can manage compliance: you, who ask for the approval in step 11, and a second one, who gives it. Those two may also be trustees, so three people is the smallest team that can finish. What the screens do when you have fewer is under If something goes wrong.

The two stages, and what is closed meanwhile

Your data lives on your server, and Zonitix holds no copy of it. So every instance, on every plan, has to back up to storage its owner controls and prove that the backup can be read back. The app enforces this in two stages: a lock and an escrow deadline.

Stage one: a first verified backup unlocks Zonitix (steps 1 to 9). On a new instance, from the first sign-in, every screen except the ones listed below sends an administrator to SystemBackups & Recovery. A checklist at the top of that page is headed “Set up backups to start using Zonitix” with a red “Required” tag, and a red banner across the top of the app reads “Zonitix is locked until backups are set up: connect storage you own and run a first backup.” On the other screens that stay open the banner has a “Set up backups” button that brings you back; on “Backups & Recovery” itself it has none, and you use the checklist’s “Connect storage” button. The lock lifts when a backup has reached your storage and Zonitix has read it back from there, decrypted it and checked it is complete. A backup that was only uploaded does not count.

Stage two: both recovery keys within 14 days (steps 10 to 12, for both keys). From the moment the first backup is verified you have 14 days to share out the “Backup encryption key” and the “Application data key” to their trustees. Zonitix is open during those days. An amber banner reads “Your first backup is verified. Escrow both recovery keys by” followed by the date and the days left, and ends “after that Zonitix is locked until it is done. It needs two administrators and three trustees.” Its button is “Escrow the keys”. If the date passes first, Zonitix locks again: the banner turns red and reads “Zonitix is locked until both recovery keys are escrowed. Without them your backups cannot be restored on a new server.” It opens again as soon as both keys are shared out.

When both stages are done the checklist and the banner disappear. If it was your own “Check again” click that finished it, you also see the message “Backup setup is complete — a verified backup exists and both recovery keys are escrowed.” After that, nothing about backups locks Zonitix again: a backup that later stops arriving produces a warning, not a lock (see If something goes wrong).

The screens that stay open

These are the screens you need in order to finish: SystemBackups & Recovery, “System Health”, “Updates” and “License & Entitlements” under “System”; “Users”, “Groups” and “Roles” under “Administration”, for adding the second administrator and the trustees; “Security Settings”, which holds MFA and email; and “My Profile”. The rest of the menu is still shown, but each of its pages brings an administrator back to “Backups & Recovery”.

Someone who cannot do the waiting step sees a panel instead of the page they opened. It is titled “Zonitix is not ready to use yet” and reads “Your administrator needs to finish setting up backups for your organisation.” in stage one, or “Your administrator needs to finish securing the recovery keys for your organisation’s backups.” in stage two, followed by “Nothing is wrong with your account — this page will open as soon as that is done.” Stage one can be finished by an administrator, or a role that can approve system updates and can view the system pages; stage two by an administrator, or a role that can manage compliance and can view the system pages.

The banner is shown to administrators and to roles that can view the system pages, on every screen, and it cannot be closed. For a person who can see it but cannot do the step, it ends “You do not have the rights to complete this step — ask an administrator.” and its button reads “Open Backups”.

An instance that was already in use

An instance whose first-run setup was finished before this rule arrived is not locked on the day it arrives. It gets a 30-day grace period, counted from the update that brought the rule, and an amber banner: “Backups to storage you own become mandatory on” the date, with the days left, then “After that Zonitix is locked until storage is connected and a first backup is verified.” The checklist on “Backups & Recovery” is headed “Backups become mandatory on” the same date. In the last day the banner counts hours and names the time.

Finish stage one inside the 30 days and nothing ever locks for it. The 14 days for the keys still apply, and on such an instance that deadline is never earlier than the end of the grace period. If the 30 days end with no verified backup, the instance locks exactly as a new one does. An instance that already had backups in its own storage and both keys shared out is marked complete by itself once Zonitix has read a backup back from that storage: its banner goes within a couple of minutes of the update.

Emails go to the people who can approve system updates, once email is set up: for an instance in its grace period at the start, with 7 days left, the day before and on the day of the lock; for the keys when the first backup is verified, with 3 days left, the day before and on the day of the lock.

Which parts to do yourself and which to hand over

  • Steps 1 to 3: hand over, unless you look after your company’s cloud account. They are done on your storage provider’s own website, not in Zonitix. Your helper gives you back four things: the bucket’s name, its region, an access key ID and a secret access key. What to ask for, word for word, is in Hand the technical setup to whoever helps you with IT.
  • Steps 4 to 7: do them yourself, or with your helper beside you. They are in Zonitix, and need only those four things.
  • Steps 8 and 9: do them yourself. Two clicks in Zonitix, and a badge to look for.
  • Steps 10 to 13: yours, and they cannot be handed over, because they are about which people you trust. A helper can sit with you and work the screens. Each trustee’s own part is in Be a trustee for a backup key.
Your instance already backs up on its own: a database backup every night (02:30 server time), a larger base backup every Sunday, and a nightly archive of the files a database backup can’t hold (signed documents, uploaded compliance evidence and candidate résumés). You don’t set that schedule in the app. Until you finish this guide, those backups stay only on your server.
The server keeps nightly database backups for 14 days and the two newest base backups. Once your bucket is connected, an older backup is removed from the server only after its copy is confirmed in your bucket, which is why older rows show “no local”. Those rows keep their “Restore” button while your bucket stays connected: the copy is fetched from your bucket first. The file archives have their own list on the same page, “File backups”, each with a “Restore” button that works the same way as a database restore. Zonitix does not perform restores on your behalf.

Prepare your bucket in AWS

  1. Step 1: Create an S3 bucket

    Hand over or do: steps 1 to 3 happen in the AWS console (the website where your company’s Amazon cloud account is managed). If that is not yours to use, send these three steps to your helper and carry on from step 4 when they have given you the four things listed above; see Hand the technical setup to whoever helps you with IT.

    In the AWS console, create a new S3 bucket for Zonitix backups. Note its name and its region.

  2. Step 2: Optional: protect the bucket against overwriting and deletion (recommended)

    Hand over or do: this is extra protection, done by the same person as step 1. The steps below work with or without it.

    Turn on Bucket Versioning and Object Lock in governance mode. Versioning is a bucket setting that keeps the earlier copies of a file. Object Lock is a bucket setting that stops a copy being removed for a set time. Then a backup can’t be quietly overwritten, and a deleted backup can still be recovered.

  3. Step 3: Create a key that can only reach this bucket

    Create an IAM user (an AWS sign-in meant for a program, not a person) with an access key (an ID and a secret that work like that program’s username and password). Give it an IAM policy: a short list, attached to that sign-in, of exactly what it is allowed to do. The policy should allow four actions on this bucket and its contents, and nothing else in the account: upload (PutObject), read (GetObject), list (ListBucket) and delete (DeleteObject). Keep the access key ID and secret access key to hand.

    You don’t have to write the policy yourself. In Zonitix, the setup window shows the exact policy for your bucket, ready to copy. See step 6.

Connect the bucket in Zonitix

  1. Step 4: Open the backup destination

    Hand over or do: from here on you are in Zonitix, and you can do this yourself. Have the bucket’s name and region, the access key ID and the secret access key from steps 1 to 3 to hand.

    Go to SystemBackups & Recovery and click “Off-box destination”. A three-step window opens: “Where”, “Access & test”, “Turn it on”.

    Until backup setup is complete, a checklist sits at the top of this page with three numbered lines: “Connect storage you own”, “Run a first backup and verify it” and “Escrow both recovery keys”. Its “Connect storage” button opens the same window.

  2. Step 5: Say where

    Set “Back up to” to “Amazon S3”. Enter your “Bucket” name and “Region”. “Prefix (folder)” is optional. Click “Next”.

    “Back up to” also offers “Azure Blob Storage”, “Cloudflare R2”, “Backblaze B2”, “Wasabi”, “Google Cloud Storage” and “MinIO / other S3-compatible”. Pick one and the window shows what to create and what access to grant for that provider; most also ask for an “Endpoint”. The rest of this guide is the same, except that “Reuse an identity hook” is offered for Amazon S3 only.
  3. Step 6: Add the key and test it

    Under “Credentials”, choose “Enter keys manually” and paste the “Access key ID” and “Secret access key”. If you already connected AWS as an identity hook, you can pick “Reuse an identity hook” instead.

    Open “Setting up Amazon S3: what to create & what access” to see the IAM policy for your bucket. If someone else did steps 1 to 3, this is the text to copy and send them: it is the policy step 3 asks for.

    Click “Test connection”. Nothing is saved yet. Five checks run: bucket reachable, credentials valid, can write, can read back and can prune (delete a file it wrote). When all pass you see “Verified — a backup can be written here”. Click “Next”.

  4. Step 7: Turn it on

    Leave “Upload backups off-box” switched on. Also keep “Automatically test that these backups restore” on and choose “How often”. This test restores your newest backup into a temporary database and never touches your live data. If it fails, everyone who can approve system updates gets an email.

    Click “Save destination”. From now on every new backup is copied to your bucket, and recent ones are caught up too.

Run a backup now and check it

  1. Step 8: Back up now

    On SystemBackups & Recovery, click “Back up now”, then “Back up now” again to confirm. Administrators’ backups start straight away. For other roles, the request waits for an administrator to approve it. The checklist’s own “Back up now” button, on its second line, does the same without the confirmation; keep the page open, because it reads the backup back for you when the upload lands.

  2. Step 9: Check the copy reached your bucket

    In “Database backups & restore points”, the new backup appears at the top. A green badge naming your storage means a copy is in your bucket. “not off-box” means it exists only on the server. Click “Re-check storage” to check again right now.

    A copy in your bucket is not yet a verified one. The checklist’s second line shows the uploaded file and, if it has not been read back yet, “Not verified yet — press Check again.” Click “Check again”. Zonitix reads the backup back from your storage, decrypts it and checks it is a complete database backup. A green message reads “Backup verified — it was read back from your storage and decrypted.” and the line is ticked. On a new instance this is the moment Zonitix unlocks, and the 14 days for steps 10 to 12 start.

Protect the backup encryption key

  1. Step 10: Choose three trustees and collect their public keys

    What happens in steps 10 to 13, and who does each part

    1. You pick three people and send each of them one file.
    2. Each of the three opens that file on their own computer, makes a key in it and sends you back one block of text.
    3. A second administrator approves with one click.
    4. You download three files, one per person, and give each person their own.
    5. Two of the three rebuild the key once, as a test, and you record the result.

    You go through this twice, because two keys are protected this way. Step 12 says when to start the second round.

    Hand over or do: steps 10 to 13 are yours. Only you can choose the people; what to arrange with them, in plain words, is under step 4 of Hand the technical setup to whoever helps you with IT. Two words come up from here on. A public key is a block of text that can only lock something, so it is safe to send by email. A private key file is its other half, the only thing that unlocks it; the person who made it keeps it and shows it to nobody.

    Zonitix encrypts every off-box copy before it leaves your server. Without that key, the copies in your bucket can’t be read. On the same page, find the “Key escrow” card. Key escrow means giving parts of a key to people you trust for safekeeping, so that it can be rebuilt later and no one person holds all of it. If “Backup encryption key” shows “NOT PROTECTED”, click “Set up escrow”. A four-step window opens: “Choose trustees”, “Lock each share”, “Issue”, “Save the kits”.

    Under “Choose trustees”, pick three trustees from your users and click “Next”. The key is cut into three parts, one per trustee (the app calls each part a share). Any two trustees together can rebuild the key later; one part on its own opens nothing.

    The three boxes, “Trustee 1” to “Trustee 3”, each list your Zonitix users, and “Next” stays greyed out until three different people are chosen. If two of them report to the same manager, an amber message names them and suggests people in different reporting lines; you can still continue.

    Under “Lock each share”, each trustee’s part is locked so that only that person can open it. For this, each trustee makes a pair of matching files on their own computer: a private key file, which they keep and show to nobody, and a public key, which is a block of text that can only lock, never unlock, so it is safe to send by email. Click “Download the blank Recovery Kit to send them”. The Recovery Kit is one file, named “zonitix-key-recovery.html”, that opens in a web browser and works with no internet connection; the blank one has no key in it yet, and the trustee makes their pair of files in it. Send that file to each trustee with a link to Be a trustee for a backup key, which tells them what to do with it.

    Each trustee sends you back their public key. Paste each one, whole, into that person’s “Their PUBLIC key” box, including the lines that start “-----BEGIN PUBLIC KEY-----” and “-----END PUBLIC KEY-----”. Those two lines only mark where the block starts and ends, and the box needs them. Nothing secret is pasted. If someone sends the private file by mistake, the box says so; ask them to make a new pair, because a private key that has been sent to anyone is no longer private. Click “Next”.

  2. Step 11: Get a second administrator to approve

    The “Issue” step shows “Two-person arm required”. “Arm” is the app’s word for a one-time permission to cut this key into its three parts. One administrator cannot give it alone: you click “Request arm”, and a different administrator opens SystemBackups & Recovery, finds “Arm issuance” on the “Key escrow” card, and clicks “Approve arm”. They do not have to go through the window you have open.

    Your window updates by itself and shows “ARMED”. Now click “Split and seal”. That cuts the key into the three parts and locks each one with its trustee’s public key. The permission is used up by this one click.

  3. Step 12: Hand out the kits

    Under “Save the kits”, click “Download kit” for each trustee and give each person only their own. A kit is one file that holds that trustee’s locked part and the tool that opens it. The kits are shown once and are not kept on the server, so “Done” stays greyed out until all three are downloaded. Never store two kits in the same place. Write down the fingerprint shown: a short code that identifies the key and is safe to write down. It is not the key, and step 13 uses it to check the test.

    Repeat steps 10 to 12 for the “Application data key”. This is a second key: it locks the most sensitive details inside the database itself, such as the sign-in details of the systems you connect and people’s second-factor secrets, so a restored backup also needs it. It needs its own “Request arm” and “Approve arm”, and the trustees can reuse the public keys they already made.

    When both keys are shared out, the third line of the checklist is ticked. Click “Check again” there to finish backup setup now. This is what the 14-day deadline asks for; the test in step 13 is still yours to do, and has no deadline in the app.

  4. Step 13: Test once that two trustees can rebuild each key

    Until a test is recorded, each key shows “NEVER TESTED”. The test is done away from the server, in the Recovery Kit: two trustees rebuild the key there and read out the fingerprint it shows. Their side of it is in Be a trustee for a backup key.

    Then, on the “Key escrow” card, click “Record offline test” on that key. Tick the two trustees who took part, type what they read out into “Fingerprint shown by the Recovery Kit”, tick the box confirming they rebuilt the key offline, and click “Record test”. You may be asked for your password. If the fingerprint does not match the one recorded for the key, nothing is recorded.

What you should see

The checklist at the top of “Backups & Recovery” and the banner about backups are both gone, and every page in the menu opens.

The restore-points list shows a green off-box badge on your newest backups, and a count of how many are off-box. The “Backup activity log” records who asked for each backup, restore and deletion.

Both keys in “Key escrow” show “PROTECTED”, and neither shows “NEVER TESTED”. Under each key the card prints the date of the last recovery test and who recorded it.

Restoring. Each restore point has a “Restore” button. It overwrites the whole live database, so use it only after corruption or a deliberate rollback. You type RESTORE and click “Request restore”. A different administrator must approve it. A safety backup of the current data is taken first. Deleting a backup works the same way. Stored files are restored separately, from the “File backups” list. See Restore from a backup.

If something goes wrong

Every page you open brings you back to Backups & Recovery
Zonitix is locked until this guide is done as far as step 9, or, after the 14 days, until both keys are shared out (steps 10 to 12). The screens that stay open are listed under The two stages, and what is closed meanwhile.
The checklist says "Not verified yet — press Check again."
The backup is in your storage but has not been read back yet. Click “Check again”. A large backup takes a while to read back; if the page says the check is taking longer than usual, give it a few minutes before checking again. Without that click, it is checked automatically within the hour.
The checklist shows a red box starting "The last check failed:"
The backup could not be read back, decrypted or recognised as a complete database backup, and the box gives the reason. Zonitix stays locked. Check the destination with “Test connection” (step 6), click “Back up now” again, then “Check again”.
Both keys are with their trustees, but the red banner about recovery keys has not gone
The checklist is headed “Both recovery keys are escrowed — finishing setup”. Click “Check again” to finish now; otherwise Zonitix confirms it by itself within the hour.
A red banner starts "Backups are failing.", or a window is titled "Your backups are not reaching your storage"
This is a warning, not a lock: Zonitix keeps working. It appears when the destination has been switched off or removed, when your storage has stopped answering, or when no backup has reached it for more than three days. The window is shown to the people who can approve system updates and has two buttons, “I understand” and “Open Backups & Recovery”; it cannot be closed any other way, and it comes back once in each new browser session while the problem lasts. Fix the destination (steps 4 to 7) and run a backup (step 8). While the warning is up Zonitix checks again every 5 minutes, and straight after you save the destination, so the banner goes within a few minutes of the fix. The banner’s own text still says it can stay up to an hour; it does not. The same people are notified in the app, and by email where email is set up, again every three days while it lasts.
A check fails in Test connection
The failing check shows the reason. "Bucket reachable" usually means a wrong bucket name or region. "Credentials valid" means the keys are wrong. "Can write", "Can read back" or "Can prune" means the IAM policy is missing an action. Compare it with the policy shown in the window.
You have fewer than three people with Zonitix accounts
The "Choose trustees" step cannot be finished: choosing one person twice shows "Each share must go to a different person. Two shares held by one person are just one share.", and "Next" stays greyed out. Add the people you trust as users first (see Add users), then come back. A trustee needs an account but no special role.
You are the only administrator
You can click "Request arm", but the approval has to come from a different person: if you click "Approve arm" yourself, the app refuses, saying the approver cannot be the administrator who requested it, and "Split and seal" stays greyed out. Give a second person the administrator role, or a role that can manage compliance (see Add your admins), and ask them to approve.
There is no Off-box destination button
Your role can’t approve system updates. Ask an administrator to set it up, or to give you that right.
A backup shows "off-box MISSING"
The copy was removed from the bucket outside Zonitix. If the server still has a local copy, click "Re-upload" under the badge.
Back up now is greyed out, or a banner says a request is awaiting approval
Only one request can wait at a time. An administrator must click "Approve" or "Reject" in the banner. If you made the request, you can "Cancel request". It also expires on its own.
The restore test says it failed or has never run
The test runs on the server itself, which Zonitix hosts. Check your bucket settings first, then contact Zonitix support.

Still stuck? See When something goes wrong, or Contact Zonitix support.

Where next