What encrypts your backup, and where the key lives
Each backup job has its own encryption step. Tick Encrypt this backup with AES-256, set a password, and BackupKit encrypts the archive on your machine before any of it goes over the network. What reaches your NAS, your bucket or your cloud drive is a file whose contents nobody can read without that password. There is no algorithm to choose and no weaker setting to land on by accident — as of 2026.8.2, ticked means AES-256.
The password is yours. It is stored on your own machine under Windows DPAPI, tied to your Windows user, and is never sent to us — there is no BackupKit account holding your key, no master key, and no recovery mechanism on our side. That is not a policy we could change our mind about later; we simply never have the material.
Restoring an encrypted backup asks for that password. Be aware of one limit we would rather state than let you discover: within a running session BackupKit can reuse a password you have already entered, so a restore started right after another one may not ask again. Close the app when you step away from an unlocked PC, the same as you would with anything else holding a key.
Encryption is opt-in per backup, not on by default. An untouched checkbox is an unencrypted backup, and a backup you thought was encrypted and isn’t is worse than one you knew was plain — so tick it deliberately, on each job that needs it.
If you lose the password, your backups are gone
Plainly: we cannot recover them, and neither can anyone else. There is no reset link, no support override, no escrow copy. The same property that stops your storage provider reading your files stops us helping you if the password is lost.
So treat the backup password the way you treat the recovery codes for your bank: put it in a password manager, or write it down and keep it somewhere physical. Test it once, early, by opening an archive yourself — the next section shows how.
You can open a BackupKit archive without BackupKit
Backups are written as standard AES-encrypted zip archives. Not a proprietary container, not a chunked block store that only our software understands — ordinary zips, encrypted with a published standard. Any tool that reads AES zips reads them.
To verify that for yourself, with 7-Zip:
- Open your backup destination and copy one archive back to your PC.
- Right-click it and choose 7-Zip → Open archive.
- Enter the password you set for that backup.
- Your files are listed. Extract any of them, with or without BackupKit installed.
This is the part worth doing once while everything is calm. It proves the exit path exists — that if BackupKit disappeared tomorrow, or you simply stopped paying for it, your backups are still yours and still readable.
What leaves your machine, and what doesn’t
BackupKit is a desktop application, not a service. Your files move directly from your PC to the storage you chose. They do not pass through any server of ours, because there isn’t one in the path.
- Your backup encryption password
- Storage credentials, keys and OAuth tokens
- The contents of your files
- Your backup history and logs
- The encrypted archive — to the destination you chose, and nowhere else
- A licence check to our server, carrying your licence key and a machine identifier
- An update check, to see whether a newer version exists
- Anything you send us yourself, such as a support message
If you enable notifications, the message goes wherever you pointed it — your own SMTP server, your Telegram chat, your webhook endpoint. It says which job ran and how it went. It never contains your files.
What encryption does not hide
One honest limit, because a page like this is worthless if it only lists the good parts. AES-encrypted zips protect the contents of your files. They do not encrypt the archive's index — so whoever holds the storage can still see the file names, folder paths and sizes inside it, even though they cannot open a single one of those files.
For most backups that is a non-issue. If the names themselves are the sensitive part — a folder per client, say, or a filename that gives away a diagnosis — put them inside a folder whose name gives nothing away, and back that up instead. This is a property of the zip format, not a BackupKit shortcut, and it is true of every tool that writes AES zips.
Transport and account access
Encryption above is what protects the archive at rest, on someone else’s disk. Transport is a separate layer: BackupKit uses each destination’s secure protocol — SFTP, FTPS, HTTPS for WebDAV and object storage — so the transfer itself is protected too. Plain FTP on port 21 is supported because some servers offer nothing else, but it sends credentials in the clear and we’d avoid it where you have the choice.
For Google Drive, Dropbox, OneDrive and the other OAuth clouds, you sign in on the provider’s own page and grant access there. BackupKit receives a token, never your password, and the token is stored on your machine like every other credential. You can revoke it from your provider’s account settings at any time, without touching BackupKit.
One wrinkle worth knowing in advance: on some providers the consent screen still shows the name FTPie, the app BackupKit was built from. It is the same developer and the same registration — the connection only ever reaches the account you authorise.
What we don’t claim
BackupKit has not been through a third-party security audit, and it carries no compliance certification. It is a single-developer product, and saying otherwise on a page about trust would be a strange way to earn it. What is written above is checkable: the archive format is standard, the key handling is described exactly, and you can confirm the exit path yourself in about two minutes.
If something here doesn’t match what you see in the app, tell us — that’s a bug in one of the two, and both are ours to fix.