How does BackupWall handle my data, and what leaves my server?
Your backups go from your server straight to your own destination. The only traffic to PortWall is a licence check-in every 6 hours (a key, an install id, a hash of the machine id, the build and file-check status) and signed update downloads. There is no other telemetry.
Where your data lives
- Backup data is on the destinations you choose. It never passes through a PortWall service.
- BackupWall's database (jobs, destinations, backup points, users, audit log) and the master key are on your server.
- Disaster Recovery bundles are stored on a destination you choose, sealed with your passphrase.
What goes to PortWall
Two hosts, over HTTPS port 443 only:
hub.backupwall.com(licence service): every 6 hours it receives the licence key, a random installation id, a hash of this machine's id, the build you run (for example0.9.0-beta.1+v278), the outcome of your last update attempt, and a check of BackupWall's own program files against the signed release (a status and counts, plus up to five file names if one was changed). Nothing about your accounts, backups, destinations or logs. The service sees the address the request comes from, because the licence is tied to it.dl.backupwall.com(release files): only when an update is offered; it redirects to GitHub's release storage.
There is no other telemetry.
How data is protected
- Optional end-to-end encryption. With Encrypt backup data on, contents are sealed with AES-256-GCM before upload, using a key that never leaves your control. See Encrypt your backups.
- Credentials at rest. Destination passwords, panel tokens and two-factor secrets are encrypted in the database with the master key.
- Integrity. Every object is checked against its hash when read back.
- TLS. The console serves HTTPS on port 8087 with a self-signed certificate. Panel plugins reach BackupWall on
127.0.0.1:8087over plain HTTP, a listener reachable only from the server itself. Connections to destinations and to peer servers are TLS-verified; an SFTP host key is pinned on first use; a peer's certificate is pinned when you register it. - Restores. Restores do not follow symbolic links out of the account's folder.
- Updates. Only signed releases are installed. The signature chain is checked against a key built into BackupWall, the check fails closed, older releases cannot be installed over newer ones, and a failed update is rolled back.
- Install attestation. A check-in tells PortWall whether BackupWall's own files still match the signed release.
- Support bundles redact passwords, tokens and keys. They can still contain host names, paths, account names, domains and email addresses, so check one before you send it. See Report a problem and make a support bundle.
- Audit log. Every action is recorded with the user and the time. The log is append-only: the database refuses changes and deletes to it.
- Sign-in protection. Two-factor login is available, and 10 failed logins lock that username for 15 minutes, then 30, doubling up to 24 hours. See Users, roles, two-factor login and API keys.
What you should do
- Restrict port 8087 to your own addresses in the firewall.
- Treat the destination as secret storage: a private bucket or a locked-down SFTP account. The destination's data is not browsable, but anyone who can write to it can tamper with it.
- Turn on two-factor login and keep a second admin.
- Do not edit files under
/opt/backupwall/app: a modified install is reported at the next check-in and gets no updates (licence and backups are unaffected).
Reporting a vulnerability
To report a security problem in BackupWall, write to [email protected] rather than opening an ordinary ticket. Include how to reproduce it.
Still stuck? Open a ticket at portwall.net/billing or write to [email protected], and attach a support bundle. See Report a problem and make a support bundle.