On this page0
Guide
Restore from a backup
Roll your Zonitix database back to an earlier restore point after corruption or a mistake, with a second administrator signing off, and put the matching stored files back.
Before you start
- This guide assumes backups were set up by you or a colleague and that you can judge when rolling the whole database back is the right call; if you do not look after Zonitix for your company, pass it to the person who does.
- Two different administrators (or people whose role can approve system updates). One requests the restore, the other approves it. The same person cannot do both.
- A reason to restore. A restore replaces your whole live database. Everything changed since the backup was taken is lost.
- No other backup, restore or deletion waiting or running. Only one can happen at a time.
- Backups already set up. If you haven’t done that yet, see Set up backups first.
Request the restore
Step 1: Open Backups & Recovery
Go to SystemBackups & Recovery. Find the “Database backups & restore points” list. The newest backup is at the top.
Step 2: Choose the restore point
Pick the latest backup taken before the problem started. The “WHEN” column shows when it was taken, and “STORED” shows where it is: “local” means a copy is on your server, a green badge naming your storage means a copy is in your bucket.
Only rows with a “Restore” button can be restored from this screen. A backup that shows “no local” is no longer on your server, but it keeps its “Restore” button as long as your bucket is still connected and the copy is still there: Zonitix fetches it from your bucket first. Rows that say “off-box only”, “not available” or “PITR only” cannot be restored from this screen (see below).
Step 3: Confirm and request
Click “Restore”. The window “Restore the database to this point?” shows the backup you picked. Type RESTORE in the box, then click “Request restore”. For a backup that is only in your bucket, the window adds that the copy is fetched from your storage first, checked, and then restored.
Nothing happens yet. The row now reads “Restore pending — awaiting 2nd admin”, and people who can approve are emailed if email is set up.
Approve it (second administrator)
Step 4: Check the request
A different administrator opens SystemBackups & Recovery. A banner at the top names the backup and who asked for it.
Step 5: Approve or reject
Click “Approve” to run it, or “Reject” to stop it. The person who asked can click “Cancel request” instead. If nobody acts, the request expires after about 30 minutes.
Step 6: Let it finish
Once approved, Zonitix first takes a safety backup of your current data, so even a mistaken restore can itself be undone. Then it restores the backup you chose. A banner shows progress while it runs.
Put the stored files back too
Step 7: Restore the matching file backup
A database backup does not hold files. Signed documents and the signing key, compliance evidence and candidate résumés are in the “File backups” list, lower on the same page. After a database restore, restore the file backup closest to, and not older than, the database backup you restored. You can also do this on its own when files were lost or damaged.
Click “Restore” on that row. The window “Restore the files from this archive?” opens. Type RESTORE and click “Request restore”. A different administrator approves it from the banner, exactly as for the database.
Zonitix takes a safety copy of the current files first. Signing, recruiting and compliance pause for about a minute while the files are replaced. Files added since the archive was taken are kept; anything changed since is replaced by the archived copy. Afterwards, check that a signed document opens and a résumé downloads.
Backups you cannot restore from this screen
Step 8: Know which backups you can restore yourself
The rule is short: if a row has no “Restore” button that you can click, you cannot restore that backup. Use the most recent backup, taken before the problem, whose “Restore” button works, then enter again whatever was added after it. Zonitix does not perform restores on your behalf, on any plan. The rest of this step says why a row can be without a working button.
“off-box only” means the copy on your server was removed by the normal clean-up, only your bucket copy is left, and Zonitix cannot fetch it because no off-box destination is switched on. Switch the destination back on (see Set up backups) and the row gets its “Restore” button back.
“not available” means the copy is gone from your bucket as well, so there is nothing left to restore.
“PITR only” marks the larger weekly base backups. Zonitix keeps them, and the record of changes written after each one, because together they are what a recovery to an exact moment between two nightly backups (point-in-time recovery) would be built from. But no screen and no API call restores your live database to a chosen moment, and you have no login to the server, so a “PITR only” row is not something you can restore. It has no button, and there is nowhere else to do it. The tooltip on the row points to the server itself. That is not a route open to you: you cannot log in to the server, and Zonitix does not perform restores on your behalf.
A backup made on an older database version keeps its “Restore” button, but greyed out; hover over it and the tooltip names the two PostgreSQL versions and says such a restore must be a supervised migration. No screen does that, so it cannot be restored from this screen either.
Set this up before you ever need it
Step 9: Protect the two keys your data depends on
The same page has a “Key escrow” card with two keys: the “Backup encryption key”, without which your bucket copies can’t be read, and the “Application data key”, without which some data in a restored backup (for example stored passwords for connected systems and MFA secrets) can’t be read.
Each key lives only on your server. If the server is lost, the only way back is the key escrow: three trustees you chose each hold one part, and any two of them together can rebuild the key.
Step 10: Make sure each key reads PROTECTED and has been tested
Both keys should show “PROTECTED”. If one shows “NOT PROTECTED”, click “Set up escrow” (the Set up backups guide walks through it). Then test it, so you know the parts really work: two trustees open the offline Recovery Kit, rebuild the key with their own parts and read out the fingerprint (a short code that identifies the key). Click “Record offline test” on the key, tick the two trustees who took part, type the code into “Fingerprint shown by the Recovery Kit”, tick the box confirming they rebuilt the key offline, then click “Record test”. You may be asked for your password. Until then the key shows “NEVER TESTED”.
Keep a copy of the “Recovery tools” downloads somewhere other than your server. They are needed at the moment your server is gone.
What you should see
The progress banner ends in success, and the list shows a new safety backup taken just before the restore.
The “Backup activity log” records who requested the restore and who approved it.
Your data matches the moment the chosen backup was taken. Anything entered after that must be entered again.
If something goes wrong
- "A restore must be approved by a DIFFERENT administrator than the one who requested it."
- You asked for the restore, so you cannot approve it. Ask another administrator to click Approve.
- The Restore button is greyed out
- Hover it to see why. Usually another backup, restore or deletion is waiting or running, or your role cannot approve system updates. A message naming two PostgreSQL versions means that backup was made on an older database version and cannot be restored from this screen (step 8).
- The row says "off-box only"
- The backup is only in your bucket and no off-box destination is switched on to fetch it from. Open "Off-box destination", switch it back on, and the Restore button returns.
- The row says "not available" or "PITR only"
- That row cannot be restored, from this screen or anywhere else you can reach: "not available" means no copy is left, and "PITR only" rows have no restore action (step 8). Zonitix does not perform restores on your behalf. Restore the most recent backup before the problem that still has a working Restore button, and enter again what was added after it.
- A restore from the bucket fails with a message that the backup could not be fetched from off-box storage
- Nothing was changed. Check that the off-box destination still passes "Test connection", then request the restore again.
- A file restore ends with "File restore REFUSED" or "Safety copy failed"
- Nothing was changed: the archive did not pass its check, or there was no room for a safety copy of the current files. Try the next file backup in the list. If it keeps failing, contact Zonitix support.
- The request disappeared before anyone approved it
- Requests expire after about 30 minutes. Line up the second administrator, then request it again.
Still stuck? See When something goes wrong, or Contact Zonitix support.