How SaveState Uses Native MySQL Dumping for Client-Side Encrypted Backups
MySQL and MariaDB have an awkward backup boundary: the files are visible to ordinary backup software, but a live copy of the data directory is not automatically a logically consistent database backup. Asking every customer to maintain a separate dump script solves that boundary, but it creates a new failure point that is easy to forget, mis-schedule, or leave full of plaintext SQL files.
SaveState puts the native database export inside the backup workflow instead.
Why SaveState invokes the database’s own tool
The database engine understands transactions, tables, routines, events, triggers, users, and grants. A generic file copier does not. SaveState therefore discovers an installed mysqldump or mariadb-dump executable and its matching mysql or mariadb client.
The current Windows client searches:
- tools available on the Windows
PATH; - common MySQL and MariaDB installation directories; and
- common XAMPP MySQL or MariaDB locations.
It verifies the selected executable and requires a successful native connection test before a profile can be saved. The test returns the server version and available non-system databases, which become the selectable backup scope.
The dump is a stream, not a temporary file
At backup time, SaveState starts the native dump tool with settings intended for a consistent and portable logical export. Its standard output becomes the input stream for a Kopia snapshot.
The pipeline is conceptually:
native database dump → Kopia compression and deduplication → client-side encrypted repository → Backblaze B2 EU Central
There is no scheduled task writing an intermediate .sql file into a forgotten local folder. That reduces plaintext-at-rest exposure and removes the race between “finish the dump” and “start the file backup.” It also means a failed native dump cannot be mistaken for a newly completed backup file.
Database passwords do not appear in the saved connection URL. After setup, the Windows client protects them in Windows Credential Manager under an account-and-profile-specific entry.
What a profile can include
Customers can select every non-system database, a list of databases, or individual tables from one database. The generated logical dump includes:
- UTF-8 configuration and binary-safe values;
- a single-transaction, streaming read where supported by the workload;
- stored routines;
- scheduled events;
- triggers; and
- optional users and grants when the selected MariaDB tool supports that capability.
“Include databases created later” re-discovers the available non-system databases before each run. It avoids silently omitting a new application database from a profile that is meant to protect the whole server.
Restore uses the reverse stream
For a database restore, Kopia decrypts the selected snapshot through the customer’s vault and streams its contents to the native database client. A table-scoped backup targets its configured database; database-scoped dumps retain their database creation and selection statements unless the customer disabled those statements during setup.
SaveState deliberately does not claim that a green job is the same as a verified application recovery. Customers should restore into an isolated target and test the application after database version upgrades, major schema changes, or changes to backup-account permissions.
How encryption and storage accounting fit around it
The database stream enters the same client-side encrypted Kopia repository as file backups. Kopia applies zstd compression and content-defined deduplication, then stores encrypted repository packs, indexes, and metadata in Backblaze B2’s EU Central region in Amsterdam.
The SaveState plan is measured from that optimized encrypted repository footprint, not by adding the original size of every retained dump. The dashboard can therefore show all three useful numbers:
- original database and file data protected;
- optimized storage used; and
- bytes and percentage saved by compression and deduplication.
Results depend on the database output. Stable pages and repeated values can deduplicate well; compressed or highly changed data can save less space.
The exact security claim
Backup contents are encrypted on the customer’s Windows device, and the hosted service does not receive the plaintext vault master key. SaveState describes that as client-side encryption.
The account password is still sent to the SaveState API over HTTPS for account authentication. SaveState therefore does not describe the complete authentication system as strict zero knowledge. Keeping that distinction public makes the security statement more useful to customers and easier for independent reviewers to verify against the open-source client.