Backup encryption
How to create an encryption key, where to keep the key file, what is stored on the storage server and how to open a backup.
The tracker encrypts a backup on its own server before sending it to the storage server. The encryption key is created on the Settings → Backups («Настройки → Резервные копии») tab, in the Backup encryption («Шифрование копий») block. An encrypted backup can be opened only with the key file: the panel gives it to you once, and it is not stored on the tracker server.
Key basics
- The key is created by the installation owner. The panel asks for that account's password: an open session is not enough.
- The key file
micator-backup-key-….txtis given out once, in the key creation window. Only the part of the key that can encrypt a backup but cannot open it stays on the tracker server. - Encryption is turned on after you upload the downloaded file back and the tracker checks it.
- From that moment, every new backup on all storage servers is encrypted. Encryption cannot be turned off.
- A new storage server can be connected only after the key has been created and confirmed.
- The key file is needed to verify a backup for restore and to restore the tracker on a new server. Backups are created without it, and the Check integrity («Проверить целостность») button also works without it.
If the key file is lost, encrypted backups cannot be restored. There is no fallback: the tracker does not store the file and cannot issue it again.
Save the file in two places, for example in a password manager and in cloud storage. Do not keep it on the tracker server or on the servers where the backups are stored.
Creating the key
- Open Settings → Backups.
- In the Backup encryption block, click Create key («Создать ключ»).
- In the “Backup encryption key · step 1 of 2” («Ключ шифрования копий · шаг 1 из 2») window, enter Your account password («Пароль вашей учётной записи»).
- Click Create key and download file («Создать ключ и скачать файл»). The browser downloads a file like
micator-backup-key-2026-10-11-3F9A1C2B.txt. - Move the file from the downloads folder to a permanent place and click Next («Дальше»).
- In step 2, click Choose file («Выбрать файл») in the Key file («Файл ключа») field and select the downloaded file. Instead of the file, you can paste its text into the or paste the file contents («или вставьте содержимое файла») field.
- Select the The file is saved outside the tracker server and the storage servers. I understand: without it, backups cannot be restored. («Файл сохранён вне сервера трекера и серверов хранения. Понимаю: без него копии не восстановить.») checkbox.
- Click Verify and enable encryption («Проверить и включить шифрование»).
The tracker encrypts a test archive with your key and opens it with the uploaded file. If everything matches, the line “Encryption enabled · key No. 3F9A-1C2B. The next backup will be encrypted.” («Шифрование включено · ключ № 3F9A-1C2B. Следующая копия будет зашифрована.») appears. Below it are two buttons: Done («Готово») and Create backup now («Создать копию сейчас»). If there are no storage servers yet or the window was opened with the + Storage server («+ Сервер хранения») button, the second button is Connect storage server («Подключить сервер хранения») instead.
Two more buttons open the same window:
- Enable encryption («Включить шифрование») in the “Backups are not encrypted” («Копии не зашифрованы») banner — it is shown when storage servers are connected but encryption is not enabled yet;
- + Storage server, while encryption is not enabled. The window then shows the line “Create an encryption key first — it takes a minute.” («Сначала создайте ключ шифрования — это займёт минуту.»)
Things to keep in mind:
- If the download did not start, click Download again («Скачать ещё раз») or Copy as text («Скопировать как текст») — these buttons are shown right after the key is created.
- Until the file is confirmed, encryption is not enabled and backups are created as before.
- If you close the window before confirming, the browser asks: “Close the window? You will not be able to download this file again. If it is not saved, the key will have to be created again.” («Закрыть окно? Скачать этот файл ещё раз будет нельзя. Если он не сохранён, ключ придётся создать заново.»)
- While a backup operation is running — creating a backup, verifying, restoring or checking disk space — the block's buttons are inactive. If a scheduled backup started between step 1 and step 2, the confirmation responds “Wait for the operation to finish. If a manual restore is required, contact the server administrator.” («Дождитесь окончания операции. Если требуется ручное восстановление, обратитесь к администратору сервера.») Do not close the window: repeat step 2 when the operation finishes.
- An unfinished setup is visible in the Backup encryption block: “Encryption is not enabled: key No. 3F9A-1C2B was created on 11.10.2026 at 14:05, the file has not been confirmed yet.” («Шифрование не включено: ключ № 3F9A-1C2B создан 11.10.2026 в 14:05, файл ещё не подтверждён.») The Upload file and enable («Загрузить файл и включить») button opens step 2. The Create key again («Создать ключ заново») button creates a different key; after that, the file downloaded earlier no longer works.
Key file and key number
The file name is micator-backup-key-DATE-NUMBER.txt: the key creation date in UTC and the first eight characters of the key number. In the panel, the same number is written with a hyphen: the file …-3F9A1C2B.txt belongs to key No. 3F9A-1C2B.
The number is shown in the Backup encryption block, in the Create backup («Создать резервную копию») window and in the backup list — for backups encrypted with a key other than the current one. It tells you which file a backup needs.
The file is a text file smaller than 4 KB. It contains lines with the key number, the creation date and the panel address, plus the line with the key itself.
When encryption is enabled, the Backup encryption block shows:
- “Enabled · key No. 3F9A-1C2B · since 11.10.2026” («Включено · ключ № 3F9A-1C2B · с 11.10.2026») — the number of the current key and the date it was confirmed;
- “File checked 11.10.2026.” («Файл проверен 11.10.2026.») — the date the file was last uploaded, when confirming the key or with the Check key file («Проверить файл ключа») button;
- the Check key file and Replace key («Заменить ключ») buttons.
What is stored on the storage server
An encrypted backup is a folder inside tracker-backups with two files:
| File | What it contains |
|---|---|
snapshot.age | The whole backup as a single encrypted file: databases, statistics, pages, the click queue and the server configuration files |
index.json | The backup number, creation date, key number, and the size and checksums of the encrypted file. Signed with this installation's key |
The backup contents and the versions and sizes of the individual archives are inside the encrypted file. Anyone with access to the storage server can delete or corrupt an encrypted backup, but cannot read it and cannot pass off their own backup as one encrypted by this tracker:
- a backup with an invalid signature gets the “failed authenticity check” («не прошла проверку подлинности») label in the list; it cannot be verified or pinned;
- a modified or incomplete
snapshot.agefile is detected by the Check integrity and Verify for restore («Проверить для восстановления») buttons.
The backup is encrypted while it is being transferred: the encrypted file is not written to the tracker's disk. After the upload, the tracker reads the file back from the storage server and compares it with what it sent.
What stays unencrypted
- Backups created before encryption was enabled. They are stored on the storage server unencrypted and are not re-encrypted. They have no signature: the tracker cannot confirm that it created such a backup and that it was not changed. Above the backup list is the line “This storage server has unencrypted backups: N. Delete them once you have verified the first encrypted backup.” («На этом сервере хранения есть копии без шифрования: N. Удалите их, когда проверите первую зашифрованную копию.»)
- Local backups on the tracker server: the emergency backup made before a restore, a backup downloaded for verification, a snapshot that failed to upload, and pre-update backups.
- The data of the running tracker on its server. Encryption protects the backups in storage, not the server itself.
There is no button in the panel for deleting an individual backup. Old unencrypted backups of this installation are deleted by the retention rule, the same way as other old backups. Without a rule, delete them on the storage server itself.
Installation without encryption enabled yet
If storage servers are connected but the key has not been created or confirmed, backups are created unencrypted:
- the “Backups are not encrypted” banner with the Enable encryption button is shown at the top of the tab;
- each storage server's row has the “unencrypted” («без шифрования») label;
- the Create backup window says “The backup will be created without encryption.” («Копия будет создана без шифрования.»);
- in the Operation history («История операций») block, the backup has the result “Done · not encrypted” («Готово · без шифрования»).
You cannot connect another storage server in such an installation until encryption is enabled. After the key is confirmed, all subsequent backups on all storage servers are encrypted, both manual and scheduled.
Checking the key file
The check tells you whether you are keeping the right file. Keys and backups do not change, and the file is not saved on the server. If the file matches the current key, the date in the “File checked …” («Файл проверен …») line is updated.
- In the Backup encryption block, click Check key file.
- Choose the file or paste its text.
- Click Check («Проверить»).
| Response | What it means |
|---|---|
| “The file matches: this is the current key No. 3F9A-1C2B.” («Файл подходит: это действующий ключ № 3F9A-1C2B.») | New backups open with this file |
| “This is the file of the previous key No. 3F9A-1C2B. It opens only backups created before 11.10.2026.” («Это файл прежнего ключа № 3F9A-1C2B. Он открывает только копии, созданные до 11.10.2026.») | The key was replaced. The file is needed for backups created before the replacement |
| “This is the file of the new key No. 3F9A-1C2B. It is not confirmed yet: close this window and click ‘Upload file and finish replacement’.” («Это файл нового ключа № 3F9A-1C2B. Он ещё не подтверждён: закройте это окно и нажмите «Загрузить файл и завершить замену».») | The key has been created but not confirmed |
| “This file does not match this tracker's keys.” («Этот файл не подходит к ключам этого трекера.») | The file belongs to another installation or to a key that was created again before confirmation |
If more than 90 days have passed since the key was confirmed or since the last check with the Check key file button, the block shows the line “The file has not been checked for more than three months — make sure it is still there.” («Файл не проверяли больше трёх месяцев — убедитесь, что он на месте.») Uploading the file when verifying a backup for restore does not reset this period.
Replacing the key
Replace the key if the file may have fallen into the wrong hands, if it is lost, or if the block shows “The encryption key on the server is damaged.” («Ключ шифрования на сервере повреждён.»)
- In the Backup encryption block, click Replace key.
- In the “Replace encryption key · step 1 of 2” («Заменить ключ шифрования · шаг 1 из 2») window, enter Your account password and click Create new key («Создать новый ключ»).
- Save the downloaded file and click Next.
- Upload the new file, select the checkbox and click Verify and replace key («Проверить и заменить ключ»).
The line “Key replaced · No. 7C4E-90AB. There are no backups with the new key yet.” («Ключ заменён · № 7C4E-90AB. Копий с новым ключом пока нет.») appears.
What happens to backups:
- Subsequent backups on all storage servers are encrypted with the new key.
- Backups already created do not change. Only the previous file opens them; in the list they are labeled “encrypted · previous key No. 3F9A-1C2B” («зашифрована · прежний ключ № 3F9A-1C2B»). Keep the previous file as long as you need these backups.
- If the previous file is lost, these backups cannot be restored. Create a new backup right after the replacement.
- If the previous file may have fallen into the wrong hands, change the storage server password and delete the old backups once a new one appears.
- The previous key confirms only backups created before the replacement.
- The Last N («Последние N») retention rule counts unencrypted backups and backups of the current key. Backups of the previous key are not counted and are deleted once N newer backups have accumulated — see Which backups the rule counts.
Until the new file is confirmed, backups are encrypted with the previous key. The block then shows the line “Key replacement not finished: new key No. 7C4E-90AB was created on 12.10.2026, the file has not been confirmed. Backups are encrypted with the previous key No. 3F9A-1C2B.” («Замена ключа не завершена: новый ключ № 7C4E-90AB создан 12.10.2026, файл не подтверждён. Копии шифруются прежним ключом № 3F9A-1C2B.») and the Upload file and finish replacement («Загрузить файл и завершить замену») and Create key again buttons.
If the key on the server is damaged
The Backup encryption block shows “The encryption key on the server is damaged. Backups are not being created. Replace the key.” («Ключ шифрования на сервере повреждён. Копии не создаются. Замените ключ.») In this state:
- the Create backup («Создать копию») button in the creation window is inactive;
- scheduled backups finish with the text “The encryption key on the server was not found or is damaged. The backup was not created; nothing was sent unencrypted. Open ‘Backup encryption’ and replace the key.” («Ключ шифрования на сервере не найден или повреждён. Копия не создана; без шифрования ничего не отправлялось. Откройте «Шифрование копий» и замените ключ.»);
- the tracker does not send an unencrypted backup to storage.
Replace the key. Backups created earlier remain on the storage server: to verify them you need the files of their keys. If the record of the previous key on the server did not survive, after the replacement its backups get the “encrypted · another tracker's key” («зашифрована · ключ другого трекера») label: they can be verified for restore with the previous key file and the I understand, verify a backup signed by another server («Понимаю, проверить копию, подписанную другим сервером») checkbox, while the integrity check and the retention rule do not apply to them.
Backup labels
In the Backups («Копии») list, the ownership label is followed by an encryption label:
| Label | What it means | Check integrity | Verify for restore |
|---|---|---|---|
| “encrypted” («зашифрована») | Encrypted with this installation's current key, the signature is valid | Yes | With the current key file |
| “encrypted · previous key No. …” («зашифрована · прежний ключ № …») | Encrypted with a key of this installation that was later replaced | Yes | With the previous key file |
| “encrypted · another tracker's key No. …” («зашифрована · ключ другого трекера № …») | Encrypted with a key this installation does not know, for example a backup from your previous server | No | With its key file and confirmation |
| “failed authenticity check” | The signature did not match: the backup was not created by this tracker or was changed on the storage server | No | No |
| “not encrypted” («не зашифрована») | An unencrypted backup | Yes | Right away while there is no key; after encryption is enabled, with confirmation |
A backup labeled “encrypted · another tracker's key” and a backup that failed the authenticity check show “Date not confirmed” («Дата не подтверждена») instead of a date: there is nothing to confirm the date of such a backup with. These backups are placed at the end of the list, after backups with a date.
An unencrypted backup that appeared on the storage server after encryption was enabled is rejected by the tracker in both the integrity check and the verification for restore: the tracker does not create such backups itself.
Integrity check
The Check integrity button in a backup's row checks the backup on the storage server without the key file. Traffic is not stopped. The backup is not written to the tracker's disk, but the tracker reads it from the storage server in full, so checking a large backup takes time.
- Click Backups and restore («Копии и восстановление») in the server's row.
- Click Check integrity in the backup's row.
- Wait until the status in the Integrity check («Проверка целостности») banner changes from “Checking the file on the storage server” («Проверка файла на сервере хранения») to “Backup is intact” («Копия цела»).
For an encrypted backup, the tracker checks the signature and compares the entire encrypted file with the signed size and checksum. The result is “Backup is intact: the file on the storage server matches what this tracker created.” («Копия цела: файл на сервере хранения совпадает с тем, что создал этот трекер.») For an unencrypted backup, the archives are compared with the backup's own manifest, and the result is “Backup files are intact.” («Файлы копии целы.») This check does not confirm that the unencrypted backup was created by this tracker.
This check does not allow a restore and does not check whether the backup is compatible with the installation. For a restore you need the Verify for restore button — see Backup verification and in-place restore.
Which backups can be restored
| Backup | What you need to verify it |
|---|---|
| Encrypted by this installation | The key file whose number is shown in the verification window |
| Encrypted by another tracker | Its key file and the I understand, verify a backup signed by another server checkbox |
| Unencrypted, created before encryption was enabled | The I understand, verify an unencrypted backup («Понимаю, проверить копию без шифрования») checkbox |
| Unencrypted, appeared after encryption was enabled | Cannot be verified: this tracker does not create such backups |
| Failed the authenticity check | Cannot be verified |
The steps are on the Backup verification and in-place restore page.
Opening a backup without the tracker
The snapshot.age file is a regular file in the age format, and the key file is a key file of the same utility. You can decrypt the backup on any computer with age installed:
age -d -i micator-backup-key-2026-10-11-3F9A1C2B.txt snapshot.age | tar -xf -The files manifest.json, postgres.tar, clickhouse.tar, redis.tar, hosted.tar, ingest.tar and server.tar appear in the current folder. The sizes and SHA-256 checksums of the six archives are recorded in manifest.json.
The server.tar archive contains the .env.production file with the installation's server keys. It is needed for the terminal restore option.
The key after a restore
The encryption key is not included in the backup.
- After an in-place restore, encryption stays the same as it was on this server before the restore.
- After a restore on a new server, there is no key on it. Create a new key and connect a storage server. The previous server's backups will get the “encrypted · another tracker's key” label: keep the previous key file as long as you need them.
If something went wrong
Wrong password («Неверный пароль»)
The Your account password field contains a password other than the one you use to log in to the panel. Failed attempts are counted together with wrong passwords on the login page. After 20 errors in 15 minutes, “Too many failed attempts. Try again later.” («Слишком много неверных попыток. Попробуйте позже.») appears — wait up to 15 minutes, see Login attempt limits.
This is not a backup encryption key file. («Это не файл ключа шифрования копий.»)
A different file was chosen. The panel names obviously unrelated files: “This is an SSH key. A backup encryption key file is needed here.” («Это SSH-ключ. Сюда нужен файл ключа шифрования копий.»), “This is a license key. A backup encryption key file is needed here.” («Это ключ лицензии. Сюда нужен файл ключа шифрования копий.»), “The file is too large — it is not a key file.” («Файл слишком большой — это не файл ключа.») Choose the micator-backup-key-….txt file.
If the file looks like a key file but its text is damaged, the Check key file and “Verify backup for restore” («Проверить копию для восстановления») windows respond: “This is not a backup encryption key file, or it is damaged. You need the micator-backup-key-….txt file downloaded when encryption was enabled.” («Это не файл ключа шифрования копий, или он повреждён. Нужен файл micator-backup-key-….txt, скачанный при включении шифрования.»)
This is the file of a different key. You need the last downloaded file — its name contains 3F9A1C2B. («Это файл другого ключа. Нужен последний скачанный файл — в его имени 3F9A1C2B.»)
The uploaded file belongs to a key other than the one awaiting confirmation: for example, the key was created several times and you chose the file from one of the earlier attempts. Find the file with the given characters in its name. If you do not have it, click Create key again.
The file failed verification. Encryption is not enabled. Create the key again. («Файл не прошёл проверку. Шифрование не включено. Создайте ключ заново.»)
The tracker did not accept the uploaded file: the key text was changed or the file did not open the test archive. Click Create key again and repeat both steps. When replacing the key, the text says “Key not replaced” («Ключ не заменён») instead of “Encryption is not enabled” («Шифрование не включено»).
The key has already been confirmed or created again. Refresh the page. («Ключ уже подтверждён или создан заново. Обновите страницу.»)
While the window was open, the key was created again and confirmed in another tab: the uploaded file belongs to the previous attempt and is no longer needed. Refresh the page and check the state in the Backup encryption block.
Create a backup encryption key first (Settings → Backups). Refresh the page. («Сначала создайте ключ шифрования копий (Настройки → Резервные копии). Обновите страницу.»)
The storage server is being connected while encryption is not enabled. Create and confirm the key and connect the server again.
Key file lost
There is nothing to open this key's backups with, so they cannot be restored. While the panel is working, replace the key — the previous file is not needed for the replacement — and create a new backup right away: the new file will open it.