How to Back Up and Restore MySQL or MariaDB Safely

A database backup must represent a consistent database state. Copying a live MySQL or MariaDB data directory as ordinary files—even through a stable Windows volume snapshot—does not by itself guarantee a recovery point the database can use.

SaveState’s Windows client includes a database-specific workflow. It runs the native MySQL or MariaDB dump tool, streams the logical dump directly into an encrypted Kopia snapshot, and can stream a selected backup into the native restore client. No intermediate plaintext SQL dump file has to remain on disk.

Set up the native database profile

Open Databases in SaveState Vault and add a database backup. The app searches the Windows PATH, common MySQL and MariaDB installations, and XAMPP directories for compatible dump-and-restore tool pairs.

Enter a connection without the password in the URL, for example:

mysql://backup_user@127.0.0.1:3306

The password goes in its own field and is protected by Windows Credential Manager after the profile is saved. SaveState requires a successful connection test before it enables the save action. That test confirms the chosen native client can reach the server and returns the databases available to the account.

Choose the smallest useful recovery scope

The profile can protect:

• every non-system database, optionally including databases created later;
• one or more selected databases; or
• selected tables from one database.

The dump uses transaction-safe logical-export settings and includes routines, events, triggers, binary values, and UTF-8 data. Compatible MariaDB tool bundles can also export users and grants. Review the selected database account’s permissions rather than running the backup with unnecessary administrative access.

Schedule, retain, and monitor it

Add one or more local backup times, choose a repeat interval, and decide how many restore points to retain. A profile can also remain manual-only.

Temporary service or network failures receive bounded retries. Problems that require a person—such as an invalid database password, a missing native tool, or a full storage plan—stop retrying and appear as needing attention. Database jobs also report privacy-limited status to the SaveState dashboard.

Restore into an isolated target first

Choose a database snapshot in the app and start its restore. SaveState reads the encrypted Kopia snapshot and streams the SQL output into the native MySQL or MariaDB client configured for the profile.

For a recovery rehearsal, restore into a separate database instance or safe test environment. Then check:

1. Important tables and row counts.
2. Application login and critical queries.
3. Routines, events, and triggers used by the workload.
4. User and grant restoration, if that option was included.
5. Character encoding and binary columns.

A successful backup proves that SaveState captured and stored the dump. A successful isolated restore proves that the complete recovery procedure works for the application.

Boundaries to keep explicit

The built-in workflow currently targets MySQL and MariaDB on Windows. Other database engines and stateful applications should use the vendor’s supported dump, snapshot, or quiescing method and then place that recovery output inside a SaveState file-backup profile.

SaveState calls its security model client-side encryption. Backup contents are encrypted before upload and the hosted service does not receive the plaintext vault master key. Account authentication still sends the account password to the SaveState API over HTTPS, so this is not a claim of strict zero-knowledge authentication.