MariaDB Backup
XLServer provides robust lifecycle management for MariaDB databases, including both standalone servers and Galera clusters.
Through native integration with Percona XtraBackup, ZFS snapshots, and XLServer orchestration, users can ensure fast backup, secure recovery, and efficient cloning of MariaDB environments.
⚙️ Prerequisites
Before linking a MariaDB database server to XLServer, ensure the following requirements are satisfied:
- ✅ MariaDB server is reachable from XLServer (network connectivity open).
- ✅ Binlog enabled in the source MariaDB database server (needed for incremental backup & recovery).
- ✅ Valid MariaDB user credentials with backup privileges and access to catalog system views.
- ✅ SSH access from XLServer to the host (or all nodes in case of a Galera cluster).
- ✅ MariaDB version ≥ 10.2 is supported.
- ✅ Sufficient free space exists in the datastore to hold golden image and incremental backups.
- ✅ NFS client is installed on all MariaDB hosts (required for backup and clone operations).
Note
The MariaDB user must have all privileges required for backup. Refer to the appendix “MariaDB User” for the SQL script to create this user.
Never link a database into the PUBLIC project, otherwise it will be visible to all XLServer users.
🔗 Linking a MariaDB Database Server
The first step is to link the MariaDB database server. This creates a golden image copy (full backup) that serves as the baseline for future incremental snapshots.
Step 1 — Navigate to Database Detail
Go to the MariaDB database server detail page.
If the server is not yet linked, you will see the linking option:
Step 2 — Start Linking Wizard
Click “Link Database” (or select Link from the Actions menu).
The Linking Wizard opens.
Step 3 — Validate Credentials
Enter MariaDB credentials, then click CHECK CONNECTION.
You can only proceed if the connection is successful.
Step 4 — Configure Linking Parameters
On the Linking Parameters page, provide the following:
- Mount Base: NFS mount point. Example:
/mnt/link. - Parallel Channels: Number of backup threads. Default
1, maximum32. - XtraBackup Path: Path to XtraBackup binary on the server. If not provided, XLServer uses the bundled binary.
- Project: Project where this database belongs. By default, the project of the environment is selected.
- Default Snapshot Retention: Default retention for snapshots of this DB.
- Storage Optimization: Enable compression and/or deduplication to save storage (may impact performance).
Step 5 — Review Summary
The summary page shows all selected options:
Step 6 — Connect and Validate
Click CONNECT to start the linking process.
You can track progress in the Jobs page.
Step 7 — Verify Linked Database
Once linking is complete, navigate to the database page to view details:
📊 MariaDB Live Database Server Detail
Once linked, each MariaDB database server has a dedicated detail page with four main tabs:
- Summary
- Database Template
- Data Masking
- Performances
1. Summary Tab
The Summary tab provides three sections:
- Database Parameters
- Database Schemas
- Snapshots Calendar
Database Parameters
| Setting | Description | Default Value | Modifiable |
|---|---|---|---|
| Project | Project where database is attached | — | — |
| Environment | Environment of the database | — | — |
| Vendor | Database vendor | MARIADB | — |
| Database Server | Endpoint (hostname/IP:port) | — | — |
| Version | MariaDB version | — | — |
| Datadir | Path to database files | — | — |
| Socket | Local socket path | — | — |
| Backup Path | Base path for backup (corresponds to Mount Base) | — | ✅ |
| Backup Strategy | Backup strategy attached to this DB | None | ✅ |
| Parallel | Number of backup threads | 1 | ✅ |
| Startup Timeout | Wait time for clone startup before failure | 120 seconds | ✅ |
| Quota | Maximum clones allowed (0 = unlimited) | 10 | ✅ |
| Snapshot Retention | Default snapshot retention | 7 days | ✅ |
| Database Type | Always Live Database | Live Database | — |
| DB User | Database user credentials | — | ✅ |
| Generic Post Script | Path to SQL script executed after clone creation | — | ✅ |
| Connecting Mode | Mode of backup. Current: ONLINE. (Offline mode planned in future versions). | ONLINE | — |
| Discovery | AUTO = discovered during environment refresh, MANUAL = added manually | AUTO | — |
| Linked On | Date & time database was linked | — | — |
| Last Sync Time | Time of last snapshot (synchronization) | — | — |
| Last Refresh Time | Time of last parameter refresh | — | — |
| Created By | User who added this database | — | — |
Database Schemas
Lists all detected schemas with their sizes.
Snapshots Calendar
Calendar view with all snapshots:
- Green dot = successful snapshot
- Red dot = failed snapshot
2. Database Template Tab
Database templates allow applying standardized parameters to all clones of this database.
- Attach Template: Link a predefined template
- Modify Template: Switch to another template
- Detach Template: Remove association
3. Data Masking Tab
The Data Masking tab allows attaching masking rules to protect sensitive data during cloning.
Column-Level Masking
- Define masking rules for specific columns.
- Use predefined or custom templates.
Table-Level Masking (Shuffling)
- Shuffle entire table rows to keep realistic but anonymized datasets.
4. Performances Tab
The Performances tab provides monitoring and tuning information:
-
Snapshots created in the last 7 days
-
Key metrics: Disk usage, compression ratio, deduplication ratio, RPO
-
Pie charts: storage consumption and snapshot success ratio
-
Line charts: backup size, DB size, compression ratio, duration
Note
Performance statistics help users detect issues early and optimize backup/clone operations.
🛠️ Actions on MariaDB Live Database
From the Actions menu, administrators can:
- Snapshot
- Refresh
- Create Virtual Database
- Create Physical Database
- Mount Snapshot
- Restore
- Disable / Enable
- Delete
Snapshot
Take an on-demand snapshot.
Snapshot-scoped actions include:
- Create Virtual DB
- Create Physical DB
- Mount Snapshot
- Restore
- Delete
Refresh
Refresh DB parameters (no snapshot taken).
Create Virtual Database
Instantly creates a virtual clone up to the last or a specific snapshot.
Create Physical Database
Creates a full physical clone with dedicated storage.
Mount Snapshot
Mounts snapshot content on source environment (for manual inspection/recovery).
When mounting, a staging clone is created. Backups are blocked until snapshot is unmounted.
Restore
Restore live DB from latest or specific snapshot.
Disable / Enable
Toggle availability of the database for backup & cloning.
Delete
Delete the live database from XLServer.
Note
A live DB Server cannot be deleted if clones are still attached. Delete clones first.
✏️ Edit Live Database Settings
-
Modify settings individually (e.g., quota):
-
Or update multiple parameters at once:
📅 Manage Snapshots
Snapshots calendar shows all recoverable points.
From snapshot detail, actions include:
- Create Virtual DB
- Create Physical DB
- Mount Snapshot
- Restore
- Delete
🎯 Backup Strategy
Assigning a backup strategy ensures continuous protection.
Assign Backup Strategy
Modify Backup Strategy
Remove Backup Strategy
🔑 Change Database Credentials
Update DB user credentials:
✅ Conclusion
XLServer provides complete lifecycle management for MariaDB and Galera cluster databases:
- Discovery and linking
- Golden image creation
- Incremental backups
- Snapshot-based cloning (virtual & physical)
- Data masking for security
- Performance visibility
This guarantees enterprise-grade protection with flexibility for development, testing, and recovery.
Appendix: Mariadb User (Required Privileges)
To allow XLServer to perform backups, snapshots, and recovery operations, you should create a dedicated Mariadb database user with the correct privileges. This user will be used when linking and snapshot the database in XLServer.
Example SQL Script
-- Connect as root user
mariadb -uroot -p
-- Create the backup user
CREATE USER 'xlsbackup'@'%' IDENTIFIED BY 'strong_password';
GRANT ALL ON *.* TO 'xlsbackup'@'%';
grant BACKUP_ADMIN on *.* to 'xlsbackup'@'%';
FLUSH PRIVILEGES;