# How MySQL and MariaDB backups work > Physical backups with Percona XtraBackup or mariadb-backup, continuous binary log shipping, client-side encryption, the account and settings Rowsafe uses, and where everything lives. Source: https://rowsafe.sh/docs/concepts/mysql For MySQL and MariaDB, the Rowsafe agent does the work itself: it streams physical backups and the binary log from your server to your bucket, encrypting everything on the way. Nothing passes through Rowsafe's service. ## Backups The backup tool copies the data files while the server runs: **Percona XtraBackup** for MySQL (8.0 for MySQL 8.0, 8.4 for MySQL 8.4) and **mariadb-backup** for MariaDB. InnoDB tables are copied without locking them; tables of other engines (MyISAM, Aria) are locked for the moment they are copied. The agent reads the tool's output as it comes (`--stream=xbstream`), compresses it (zstd) and encrypts it (see below), and uploads it to your bucket in parts. Nothing is written to your server's disk on the way. | Type | What it copies | When | | ------------ | ----------------------------------- | ----------------------------------------- | | Full | everything | weekly, and the first backup | | Differential | pages changed since the last full | daily | | Incremental | pages changed since the last backup | on request (`rowsafe backup --type incr`) | A restore needs one full plus the backups built on it. Rowsafe keeps as many full backups as the database's retention says (2 by default) and deletes older ones, with the binary logs only they needed. ## The binary log, shipped continuously The **binary log** is the server's record of every change. The agent reads the binary log files on your server and uploads what is new: - a finished file right away; - the file being written once 16 MiB are waiting, or when the oldest waiting change is 50 seconds old. So your bucket is at most about a minute behind, without asking the server to switch files: a quiet server uploads nothing and a busy one isn't disturbed. A **Mark** asks for an upload at once and counts only when its position is in the bucket. The dashboard's "Last change saved" is the time up to which every change is in your bucket. The agent keeps going on its own: if it or your bucket is unreachable for a while, it catches up from where it stopped, as long as the server still has the binary log files (keep them at least a day; MySQL keeps them 30 days by default). If the server deleted files before they were copied, Rowsafe says so and the next full backup closes the gap. ## Restoring to a second A restore (Proof, a Rewind copy) downloads the backup chain, unpacks it (`xbstream` / `mbstream`), prepares it with the backup tool, and starts a **private server** on it: a copy of your server's own binary, listening only on a Unix socket in a folder only the agent can open (no network), without the grant tables, binary log, replication or scheduled events. The agent then replays the binary logs (`mysqlbinlog` / `mariadb-binlog`) from the backup's position up to the second you chose, or exactly to a Mark's position. The whole transaction that committed at that second is included. ## Encryption Every object is compressed and then encrypted **on your server** with [age](https://age-encryption.org), keyed from your repository passphrase (`ROWSAFE_REPO_CIPHER_PASS`, the same one pgBackRest uses for PostgreSQL) through scrypt. Your bucket only ever holds ciphertext; the passphrase never leaves your server. Without it no backup can be restored, so keep a copy in your secret manager. ## In your bucket ```text /// repository.json.age the database's marker backups/