R1Soft MySQL application-aware backups on cPanel servers

R1Soft's block-level snapshots are crash-consistent at the filesystem layer but not always at the database layer. A snapshot taken mid-transaction restores in the same state as a power cut — InnoDB will replay its redo log on startup, MyISAM will need a myisamchk --recover, and any half-written .ibd page may force a tablespace import. The MySQL add-on (called "application-aware" in the Server Backup Manager UI and "database instance" in the agent config) closes that window by flushing tables and pausing writes for the few milliseconds it takes the agent to declare a snapshot point.

This guide covers enabling the add-on on a cPanel host where MySQL or MariaDB runs locally, creating the privileged user the agent uses, registering the database instance, and verifying that a recovery point actually completed in application-aware mode. The procedure assumes you have already installed the R1Soft agent and a policy is backing the server up.

How application-aware actually works

When the policy runs, the agent connects to MySQL using the credentials you stored, issues FLUSH TABLES WITH READ LOCK, asks the kernel module to declare the snapshot, and immediately releases the lock. For InnoDB-only schemas the lock is released even sooner because the agent uses a consistent read instead of a global flush. The whole pause is usually 50–500 ms on a healthy server, but it can stretch into seconds if a long-running SELECT is holding tables open — that is the single most common production complaint and worth designing for upfront.

The add-on works with MySQL 5.7, 8.0, MariaDB 10.3 through 10.11, and Percona Server. cPanel typically ships MariaDB 10.11 on AlmaLinux 9; both the bundled and EOL versions work.

Prerequisites

• R1Soft Server Backup agent 6.16 or later
• A policy already protecting the cPanel server with at least one successful recovery point
• MySQL or MariaDB reachable on 127.0.0.1:3306 or via the cPanel socket at /var/lib/mysql/mysql.sock
• Root on the cPanel server

If MySQL lives on a separate database server, install the agent there and create a second policy — application-aware does not reach across hosts.

Create the MySQL user the agent will use

The agent needs five privileges and nothing more. Avoid using root — when the password rotates, your backups break silently.

CREATE USER 'r1soft'@'localhost' IDENTIFIED BY 'CHANGE_ME_LONG_RANDOM';
GRANT RELOAD, LOCK TABLES, REPLICATION CLIENT, SELECT, SHOW VIEW
  ON *.* TO 'r1soft'@'localhost';
FLUSH PRIVILEGES;

RELOAD is the one people forget; without it the FLUSH TABLES WITH READ LOCK call fails and the agent silently falls back to a crash-consistent snapshot. REPLICATION CLIENT lets the agent read binary log coordinates, which it stores in the recovery point so you can use a backup as a replication source after restore.

Register the database instance on the agent

On the cPanel server, run the interactive helper:

serverbackup-setup --add-mysql-instance

Answer the prompts: instance name (cpanel-mysql is fine), host (127.0.0.1), port (3306), user (r1soft), and password. The helper writes the instance to /etc/serverbackup/databases.conf and reloads the agent. To verify it loaded:

serverbackup-setup --list-mysql-instances

The agent will print the configured instances and whether each is reachable. A connection refused here almost always means MySQL is bound to the socket only — add bind-address = 127.0.0.1 to /etc/my.cnf.d/server.cnf and restart MariaDB, or switch the instance to socket mode by re-running the helper with --mysql-socket /var/lib/mysql/mysql.sock.

Enable application-aware on the policy

In Server Backup Manager:

1. Open Policies, edit the policy that protects the cPanel server
2. Open the Database tab
3. Tick Enable MySQL application-aware backups
4. Select the instance you just registered
5. Save

The next policy run will flush tables before the snapshot. The recovery point in the Disk Safes view shows a small database icon when application-aware fired successfully — if the icon is missing but the recovery point still completed, the agent fell back to crash-consistent mode and there will be a warning in the task log.

Verify the recovery point is actually consistent

The fastest end-to-end verification is to restore a database into a sandbox and read it.

serverbackup-setup --browse-recovery-point --policy-id 12 --point latest
# pick the MySQL instance, then "Restore to alternate location"
# point it at /tmp/r1soft-verify
mysqld --datadir=/tmp/r1soft-verify --socket=/tmp/verify.sock --port=3307 &
mysql -S /tmp/verify.sock -e "CHECK TABLE wp_options" wp_user_db

If CHECK TABLE returns OK without any repair_status rows, the snapshot is consistent. If you see Table marked as crashed, the lock did not hold long enough — usually a long SELECT was running. Move the policy schedule to a quieter window or shorten the offending queries.

Tuning for busy shared hosting

On a server with several hundred cPanel accounts, the global lock can collide with batch operations (Imunify360 malware scans, LiteSpeed cache warmup, or cron-heavy plugins). Three settings help:

• Lock timeout. In databases.conf, set lock_wait_timeout=30 so the agent gives up after 30 seconds instead of hanging the schedule.
• Skip transient databases. Add a skip_database line for information_schema, performance_schema, and any throwaway databases like tmp_* patterns.
• Use the InnoDB-only fast path. If every account uses InnoDB exclusively, set innodb_only=true and the agent skips the global flush entirely, using a consistent read instead. This is by far the largest single win on busy hosts.

# /etc/serverbackup/databases.conf
[cpanel-mysql]
host = 127.0.0.1
port = 3306
user = r1soft
password_file = /etc/serverbackup/.cpanel-mysql.pw
lock_wait_timeout = 30
innodb_only = true
skip_database = information_schema,performance_schema,sys,tmp_%

Reload the agent with systemctl restart serverbackup-agent after editing.

Restoring a single database from an application-aware point

The whole reason to enable this is so a single-database restore comes up clean. From the SBM:

serverbackup-setup --restore-database --policy-id 12 --point 2026-05-17T03:00 \
  --database wp_user_db --target-host 127.0.0.1 --target-user root

The agent recreates the schema, replays the InnoDB redo log if needed, and imports tablespaces in dependency order. A typical 2 GB WordPress database restores in about 90 seconds on local NVMe. For self-service restores by cPanel users, see the R1Soft cPanel plugin guide.

Next steps

• Compare the application-aware approach with JetBackup's account-level database export in R1Soft vs JetBackup for hosting fleets
• Move your offsite copy to a second Disk Safe with R1Soft Disk Safe replication
• Right-size your SBM tier on the R1Soft license page once you know how many MySQL instances you will protect