BackupKit 2026.8.2

If you already had encryption switched on, read this first

Encryption moved out of the compression settings and into its own step, and the old settings are not carried across. A job created before this release comes back with encryption switched off — and because the run still succeeds, nothing will warn you about it.

Open each backup that should be encrypted, tick Encrypt this backup with AES-256, and enter the password again. Until you do, that job writes unencrypted archives.

Snapshots you already have are untouched and still restore normally — the encryption method is read from the archive itself, not from the job's settings.

Encryption is its own step, and always AES-256

• • A dedicated Encryption step in the backup wizard, ahead of compression: one checkbox, one password field.
• • The protection-level dropdown is gone. It defaulted to a legacy ZipCrypto mode that is trivially breakable, so anyone who ticked the password box and left the dropdown alone got weak encryption. Ticking the box now means AES-256, with nothing to get wrong.
• • Encryption no longer requires compression. Encrypt without compressing, compress without encrypting, or both.

Where the password lives, and when you are asked for it

• • Backup passwords are now stored with Windows DPAPI, tied to your Windows user. They were previously held in an unencrypted local database, which meant a copy of that file was a copy of your passwords.
• • Restoring an encrypted backup asks for the password. It used to decrypt silently from the stored copy. Note that a password already entered can still be reused within the same running session, so it will not re-prompt every single time.
• • A run that cannot unlock its password now fails before uploading anything, rather than quietly writing an unencrypted archive.

Fixed

• • Successful backups disappearing from history. On a job with more than 50 runs whose snapshots were all still kept, the history trim deleted the run that had just started. The backup itself worked every time; it just left no record. Affected jobs may have snapshot folders on the destination with no history entry pointing at them — those need deleting by hand.
• • A folder at the root of a drive lost the first letter of its name inside the archive — E:\Badania was stored as adania, and restoring it faithfully recreated the wrong name. Backing up a whole drive or network share stored absolute paths, which some archive tools refuse to open. New archives are correct; re-run a backup once to get one.
• • The trial was described as 14 days in the app while the licence granted 30. It now says 30, in every language.

Smaller changes

• • The cloud sign-in screen now explains why the permission page says FTPie: it is the sibling app whose connector both products share.
• • The run-script and webhook cards now list the details BackupKit passes to them, with an example, instead of saying only that context is passed.
• • The activity page no longer offers filters that could never match anything.
• • A search that matches nothing now says so, instead of showing the "no backups yet" empty state to someone with twenty of them.
• • Backup cards keep their actions visible when selected by keyboard, not only while the pointer is over them.