Backup verification and in-place restore

An in-place restore replaces the data of the running tracker with data from a backup on the storage server. The backup must be verified first; an encrypted backup requires the key file. A verification is valid for an hour. Moving to an empty server is covered on the Restoring on a new server page.

The Settings → Backups («Настройки → Резервные копии») tab is visible to the owner and the admin. It works only for the installation owner — the owner account created during installation — when logged in with a login and password. For admins, other owners and in Log in as a user mode, the tab shows “Backups are available only to the installation owner” («Резервные копии доступны только владельцу установки»).

Backup list

1. Open Settings → Backups.
2. In the Storage servers («Серверы хранения») block, click Backups and restore («Копии и восстановление») in the row of the server you need.

The Backups («Копии») block with the server name opens below: only completed backups, newest first. Each one has a date, a size and two labels. A backup whose date the tracker cannot confirm shows “Date not confirmed” («Дата не подтверждена») instead of a date; such backups are at the end of the list. The first label is one of four, the first that applies in this order:

• “pinned” («закреплена») — protected from cleanup, see Backup retention, pinning and cleanup;
• “used for restore” («используется для восстановления») — the backup is being verified or restored, or its verification is still valid;
• “backup of this installation” («копия этой установки») — created by this tracker through this server connection;
• “external backup” («внешняя копия») — the other backups in the folder: from another installation or created before the server was reconnected.

The second label is about encryption: “encrypted” («зашифрована»), “encrypted · previous key No. …” («зашифрована · прежний ключ № …»), “encrypted · another tracker's key No. …” («зашифрована · ключ другого трекера № …»), “failed authenticity check” («не прошла проверку подлинности») or “not encrypted” («не зашифрована»). What each one means is in the Backup labels section.

A backup's row has three buttons: Pin («Закрепить»), Check integrity («Проверить целостность») and Verify for restore («Проверить для восстановления»).

• For a backup labeled “failed authenticity check”, the check buttons are inactive and it cannot be pinned either: it was not created by this tracker or it was changed on the storage server.
• For a backup labeled “encrypted · another tracker's key”, the Check integrity button is inactive: integrity is checked only for this tracker's backups.

Integrity check

The Check integrity button checks a backup on the storage server without the key file. Traffic is not stopped. The backup is not written to the tracker's disk, but it is read from the storage server in full, so checking a large backup takes time. The result is the “Backup is intact” («Копия цела») status in the Integrity check («Проверка целостности») banner.

The integrity check does not allow a restore and does not check whether the backup is compatible with the installation. More details are in the Integrity check section.

Verifying a backup

1. Click Verify for restore in the row of an encrypted backup. The “Verify backup for restore” («Проверить копию для восстановления») window opens with the date and size of the backup and the number of the key it is encrypted with.
2. Click Choose file («Выбрать файл») in the Key file («Файл ключа») field and select the file of that key. Instead of the file, you can paste its text into the or paste the file contents («или вставьте содержимое файла») field.
3. Click Verify backup («Проверить копию»).
4. Wait until the status in the Backup verification («Проверка копии») banner at the top of the tab changes from “Downloading and decrypting the backup” («Скачивание и расшифровка копии») to “Backup verified” («Копия проверена»).

The tracker downloads the backup to its disk, decrypts it and checks file integrity, archive safety and compatibility with the installation. Traffic is not stopped. The tracker's disk needs free space: the size of the backup plus 2 GB. If the connection drops while an encrypted backup is being read, reading starts over: up to three attempts in total.

The key file is needed only for the duration of the verification: it is not saved on the server, and you upload it again for each verification. The tracker rejects an unsuitable file and a backup with an invalid signature right away, before downloading.

The tab shows the Backup passed verification («Копия прошла проверку») card with the backup date and the Restore… («Восстановить…») button. The verification is valid for an hour after it finishes: the download time does not count toward this hour. After an hour, the verification in the Operation history («История операций») block has the result “Verification expired” («Срок проверки истёк») — verify the backup again.

Unencrypted backup and backup from another server

Use an unencrypted backup only if you alone had access to the storage server. Use a backup from another server only if it is a backup of your previous server and you kept the key file.

An unencrypted backup that appeared on the storage server after encryption was enabled is not verified by the tracker: the tracker does not create such backups itself.

Which backup will work

A backup passes verification if the tracker's data structure, database versions and server keys have not changed on the installation since the backup was created. Server keys are the installation keys from the server configuration file, not the backup encryption key. A backup from another installation, or one made before an update that changed the data structure, gets the result “The backup does not match this installation: the schema, database versions or server keys differ.” («Копия не подходит к этой установке: отличаются схема, версии баз или серверные ключи.»)

A backup from another installation is deployed on an empty server — see Restoring on a new server.

Starting the restore

1. In the Backup passed verification card, click Restore….
2. In the Restore tracker data («Восстановить данные трекера») window, compare a line like “Backup created 3 October 2026, 04:01 — 8 days ago. Anything that changed in the tracker later will not be restored.” («Копия создана 3 октября 2026, 04:01 — 8 дней назад. Всё, что изменилось в трекере позже, восстановлено не будет.») with the date of the backup you need.
3. Select the I understand and confirm replacing the data of all workspaces («Понимаю и подтверждаю замену данных всех рабочих пространств») checkbox.
4. In the Type ВОССТАНОВИТЬ («Введите ВОССТАНОВИТЬ») field, type ВОССТАНОВИТЬ — in Cyrillic, in capital letters.
5. Click Start restore («Начать восстановление»).

The key file is not needed at this step: the backup was decrypted during verification.

The Restore («Восстановление») banner appears at the top of the tab. Progress is visible even while the tracker is stopped, and you can leave the tab open. Other sections of the panel do not load data during the pause.

Stages and the emergency backup

The status in the banner changes in this order:

The length of the pause depends on the amount of data.

An error before traffic is stopped does not affect the data: fix the cause and verify the backup again. If an error occurs after the stop, the tracker returns the previous data by itself, starts and opens traffic. The banner shows the “Rolling back to the emergency backup” («Возврат к аварийной копии») status and the text “The restore did not finish. Data has been returned from the emergency backup; the tracker is running. The postback queue needs checking.” («Восстановление не завершилось. Данные возвращены из аварийной копии; трекер запущен. Очередь постбэков требует проверки.»)

The downloaded backup and the emergency backup remain on the tracker's disk in the Local restore backups («Локальные копии восстановления») block — see Backup retention, pinning and cleanup. They are stored unencrypted.

What is replaced and what stays

Replaced with the backup data:

• campaigns, streams, offers, landing pages, sources and settings;
• users and their passwords;
• statistics;
• uploaded (hosted) landing pages and offers;
• the click queue and event delivery tasks;
• the license key.

Kept as they are now:

• the panel domain and the tracking domain set during installation;
• HTTPS certificates;
• connected storage servers, the credentials for them and the operation history;
• the backup encryption key: encryption stays the same as before the restore.

Postbacks after a restore

The tracker does not run delivery tasks that were queued or in progress in the backup by itself: the recipient may have received the event before the restore. These are S2S postbacks, CAPI events and conversion records. In the delivery log they have the result Restored from backup · needs reconciliation («Восстановлено из копии · нужна сверка»).

1. Open Logs → Event delivery («Логи → Доставка событий»).
2. In the All states («Все состояния») list, choose Needs review («Нужна проверка»).
3. Click Find («Найти»).
4. Check with the recipient whether each event arrived.
5. Click Retry («Повторить») only where the recipient does not have the event — see manual retry.

The log opens for the last 7 days. If the backup is older, widen the period in the From («С») and To («По») fields — up to 93 days per search. The same applies to tasks after an automatic rollback to the emergency backup.

Checking the result

1. Log in to the panel if it asks you to log in again. Logins and passwords come from the backup.
2. Expand Operation history on the Backups («Резервные копии») tab. The “Restore” operation should have the result “Done”.
3. Make sure the campaigns and statistics match the backup date.
4. Open Admin panel → Status («Админ-панель → Состояние») and check that the services show Available («Доступен») — see System status.

If the “Tracker access closed” («Доступ к трекеру закрыт») screen opens instead of the panel, enter a valid key in the License key («Ключ лицензии») field and click Activate («Активировать») — see Getting a key and activation.

If something went wrong

Verify the backup again and confirm the data replacement («Проверьте копию заново и подтвердите замену данных»)

More than an hour has passed since the verification finished. Click Verify for restore again and start the restore right after the verification.

Key file and backup messages

Wait for the operation to finish. If a manual restore is required, contact the server administrator. («Дождитесь окончания операции. Если требуется ручное восстановление, обратитесь к администратору сервера.»)

The tracker runs one operation at a time: creating a backup, verifying, restoring or checking disk space. While it is running, the buttons on the tab are inactive. During a tracker update, verification and restore finish with the text “A server update is in progress. Try again after it finishes.” («Сейчас идёт обновление сервера. Попробуйте после его окончания.»)

Not enough free space on the tracker server. («Недостаточно свободного места на сервере трекера.»)

Verification needs the size of the backup plus 2 GB. A restore needs the size of the tracker's current data with a 20% margin plus 2 GB: an emergency backup is saved to disk. How to see what takes up the disk is described on the Backup retention, pinning and cleanup page.

Checksums do not match. The backup cannot be used. («Контрольные суммы не совпали. Копию использовать нельзя.»)

The backup files on the storage server are damaged or changed. Choose another backup.

The operation was not completed. Check access to the storage and the server state. («Операция не завершена. Проверьте доступ к хранилищу и состояние сервера.»)

Any other error is shown this way: for example, the tracker could not connect to the storage server. Check the storage server connection and start the verification again.

Automatic rollback was not completed. Server administrator help is needed; new operations are blocked. («Автоматический возврат не завершён. Нужна помощь администратора сервера; новые операции заблокированы.»)

The restore and the rollback to the emergency backup did not finish. Traffic intake stays closed, and new operations on the tab are unavailable. This cannot be fixed from the panel — the server administrator takes over from here.

cd /opt/micator
sudo docker compose --project-name micator --env-file .env.production -f docker-compose.prod.yml restart backup