When you back up to a cloud, an FTP server, or a NAS, you're trusting whoever runs that storage with the readable contents of your files. BackupKit closes that gap: tick Encrypt this backup with AES-256, set a password, and the backup is encrypted on your machine before a single byte goes over the network. What the destination holds is an archive whose contents nobody can read without that password.
Encryption happens on your machine — nowhere else
Files are encrypted locally, before anything goes over the network. Whatever destination you chose — Google Drive, a NAS, an SFTP server — never receives a readable copy.
- Files gathered: BackupKit reads your selected files locally.
- Encrypted: written into a zip with AES-256, using your password, on your machine. Compression is a separate choice; encryption doesn't require it.
- Uploaded: the encrypted archive travels over a secure transport (TLS/SSH).
- Stored, unreadable: the destination holds an archive whose file contents cannot be opened without your password.
Worth being precise, because plenty of tools aren't: AES-encrypted zips protect the contents of your files, not the archive's index. Whoever holds the storage can still read file names, folder paths and file sizes inside the archive. They cannot read a single byte of what's in those files. If the names themselves are sensitive, put them in a folder whose name isn't.
Where to switch it on
Encryption is its own step in the backup wizard, ahead of compression. One checkbox — Encrypt this backup with AES-256 — and a password. There is nothing else to configure and no algorithm to choose: if the box is ticked, the backup is AES-256.
Compression is a separate switch in its own step. Encrypt without compressing, compress without encrypting, or do both — the four combinations all produce a single archive.
One mode: AES-256
There used to be a protection-level dropdown here, defaulting to a legacy ZipCrypto mode that is trivially breakable. It was removed in 2026.8.2. A backup you thought was encrypted and wasn't is worse than one you knew was plain, and a default nobody changes is not a choice — so the choice is gone and the strong option is the only one.
Only you hold the key
Your encryption password never leaves your PC. BackupKit has no master key, no account-recovery loophole, no way to decrypt your backups — even if we wanted to.
- No server-side storage of encryption passwords — nothing to leak if someone breaks into us.
- Stored with Windows DPAPI, tied to your Windows user — the backup password and your provider credentials alike. Copying the settings database to another machine does not carry the passwords with it.
- Asked for when you restore: though within one running session an already-entered password can be reused, so it will not always re-prompt.
- Lose the password, lose the data: by design. That's what zero-knowledge costs.
BackupKit cannot reset or recover your encryption password. Store it somewhere safe — a password manager is ideal.
Restoring asks for the password
Restoring an encrypted backup asks for the password — the archive cannot be unpacked without it, by anyone, including us. One caveat worth knowing: inside a single running session BackupKit may reuse a password you have already typed, so a second restore in a row can go through without asking.
Secure transport, open format
Even though the archive is already encrypted, uploads use the destination's secure transport — TLS for HTTPS/FTPS/cloud APIs, SSH for SFTP. Double wrapping.
Your backups are standard AES-encrypted zip files. If BackupKit disappeared tomorrow, you could still open them with 7-Zip, WinRAR, PeaZip, or any AES-zip tool. No proprietary format, no trapped data.
Back up anything, anywhere — today
Encrypted, scheduled, automated backups to storage you already own. Try every feature free for 30 days — no card required.