Whitepaper — PodHeitor MySQL / MariaDB - PodHeitor — Backup, Replicação e Recuperação de Desastres

MySQL and MariaDB backup with no window. Native XtraBackup/MariaBackup, binlog-based PITR, restore to the exact second, InnoDB, MyRocks and Galera cluster support.

InnoDB hot backup via XtraBackup/MariaBackup — zero downtime.
PITR via binlog — restore to the exact transaction before an incident.
Galera cluster-aware — back up any node, coordinated cross-node restore.
MyRocks and InnoDB — same plugin, automatic engine detection.
Granular restore — partial restore of table or schema without bringing up the full server.

Production-ready in 30 days, at least 50% cheaper. Free trial, signed RPMs and DEBs, direct support from Heitor Faria. Replace your Veeam, Commvault or Bacula Enterprise license without breaking the nightly window.

Request a free 30-day trial →

Title Page
Executive Summary
Problem Statement
Product Overview
Use Cases
Architecture
Installation Procedure
Configuration and Sizing (Minimum Recommended)
Compatibility Matrix
Backup Options — Complete Reference Table
Restore Options — Complete Reference Table
FileSet Configuration Examples
Restore Configuration Examples
Performance Reports
Live-Validated Evidence
Security Model
Operational Runbook
Troubleshooting Top-10
Upgrade Policy & Release Cadence
Pricing & Commercial Terms
Licensing
Conclusion & Call-to-Action
Contact Page
Appendix A — Glossary
Appendix B — References

1. Title Page

PodHeitor MySQL/MariaDB Backup and Replication Plugin for Bacula

Version: v0.4.1 Release date: 2026-04-24 Author: Heitor Faria — Founder, PodHeitor / OpenTechs License: PodHeitor-Proprietary — Copyright © Heitor Faria. All rights reserved. Commercial licensing terms available on request

Classification: Confidential — client-facing

Contacts:

Email: heitor@opentechs.lat
Phone: +1 (786) 726-1749
WhatsApp: +55 (61) 98268-4220

This document describes the capabilities, architecture, installation, configuration, operational practices, commercial terms, and licensing of the PodHeitor MySQL/MariaDB Backup and Replication Plugin for Bacula, version v0.4.1. It is prepared for a mixed audience of C-level decision-makers, database administrators, system administrators, and procurement officers. All content is owned by Heitor Faria and is provided under confidential, client-facing distribution terms.

2. Executive Summary

Enterprises running MySQL and MariaDB at production scale face a persistent and expensive contradiction. On one hand, these databases are the operational backbone for OLTP systems, ERP, ECM, SaaS control planes, financial ledgers, and regulated workloads. On the other hand, the backup tooling market around them has consolidated into a small number of incumbents — Bacula Enterprise, Veeam, Commvault, and Veritas NetBackup — whose licensing models, architectural choices, and pricing curves are increasingly misaligned with the realities of modern MySQL/MariaDB estates: horizontally scaled Galera clusters, Percona TDE workloads, MySQL 8 Clone-based provisioning, MariaDB 11.4 LTS, CDP-style binlog continuous data protection, and geo-distributed disaster recovery replicas.

The PodHeitor MySQL/MariaDB Backup and Replication Plugin for Bacula v0.4.1 is a purpose-built, single-binary, Rust-implemented Bacula File Daemon plugin that delivers 48 of 48 documented enterprise MySQL/MariaDB backup capabilities in a single distribution. It is single-licensed under PodHeitor-Proprietary, with commercial relicensing available for customers who need it. It is designed to slot into existing PodHeitor Backup (15.0.3 primary) or Bacula Enterprise deployments without requiring a forklift migration of the Director, Storage Daemon, or catalog infrastructure.

PodHeitor v0.4.1 solves four concrete problems at once:

Feature parity. It matches the documented enterprise MySQL

plugin feature list row-for-row, including logical dumps, physical Percona XtraBackup and mariabackup full/incremental/differential, Galera donor-desync coordination, MySQL 8 CLONE INSTANCE agentless replica provisioning, transportable tablespace single-table restore, Percona TDE keyring-aware physical backup, binlog-based CDP, and — new in the 0.x line — full disaster-recovery replica provisioning via mode=replicate, which stands up a live, catch-up MySQL replica straight from a Bacula restore job.

One-binary architecture. The plugin ships as a single Rust

binary (podheitor-mysql) invoked through a thin Bacula metaplugin shim. There is no Perl runtime dependency, no second-language toolchain, no shared-object dependency graph beyond libc or musl. This dramatically reduces attack surface, supply-chain footprint, and operational variance compared to Perl-based enterprise plugins.

Commercial economics. PodHeitor is deliberately positioned

below the price points of Bacula Enterprise, Veeam, Commvault, and NetBackup. Our standing commercial offer is simple and unconditional: bring us your existing contract or renewal quote from any of those four vendors, and we will match the feature list and commit to a minimum of 50% discount, with many additional capabilities included.

Source-available, commercial-licensed. The PodHeitor licensing model means the plugin’s

source is auditable, inspectable, and buildable by the customer — satisfying the most stringent procurement and security review processes. For customers whose deployment model (for example, closed-source Sa(SaaS redistribution) require commercial licensing terms specific to that use case.

Bring us your existing contract or renewal quote from Bacula Enterprise, Veeam, Commvault or NetBackup — we match the feature list and commit to a minimum of 50% discount, with many additional capabilities included.

To start the conversation: email heitor@opentechs.lat, call +1 (786) 726-1749, or message +55 (61) 98268-4220 on WhatsApp.

3. Problem Statement

3.1 The modern MySQL/MariaDB backup challenge

MySQL and MariaDB have quietly become the default transactional database for the majority of production workloads outside of the mainframe and hyperscaler-managed ecosystems. The operational profile of those workloads has shifted significantly in the last five years:

Datasets routinely exceed 1 TB per instance, with many exceeding

10 TB.

Galera clusters of 3 to 7 nodes are common for high-availability

topologies.

Percona Server with TDE-encrypted InnoDB is standard for regulated

industries (finance, health, public sector).

MariaDB 10.6 and 11.4 LTS dominate the ERP and ECM vertical,

particularly in Europe and Latin America.

DR strategies increasingly rely on geo-distributed replicas that

must be stood up, rebuilt, and re-based on demand — not just “restored from tape.”

Regulatory frameworks (PCI-DSS, LGPD, GDPR, HIPAA, SOX) require

RPOs in the single-digit-minutes range, which only binlog-based CDP can deliver.

Against this, the installed base of MySQL backup tooling is not keeping up.

3.2 Why current solutions fall short

Bacula Enterprise 18.2.3 MySQL plugin. The incumbent enterprise MySQL plugin in the Bacula family is implemented in Perl. Perl is a capable language, but in 2026 it imposes real costs: a large interpreter runtime on every File Daemon host, CPAN dependency trees that complicate air-gapped deployments, slower execution for compute-bound tasks like compression and stream handling, and a shrinking pool of engineers fluent enough to debug it in production. The Perl MySQL plugin also lags on newer features — MySQL 8 Clone, transportable-tablespace single-table restore, and DR replica provisioning are either absent or delivered through add-on modules.

Veeam Backup & Replication. Veeam’s MySQL support is implemented as an agent rather than a first-class engine. This works acceptably for small instances but does not integrate cleanly with Galera, does not offer agentless MySQL 8 Clone, and pushes customers into Veeam’s virtualization-first licensing curve, which is expensive at database scale.

Commvault. Commvault delivers broad platform coverage at a high total cost of ownership. Licensing is capacity-based and escalates sharply; the MySQL iDataAgent is competent but not differentiated, and TCO for a mid-sized MySQL estate is routinely 3–5× what PodHeitor delivers equivalent coverage for.

Veritas NetBackup. NetBackup’s MySQL coverage is heavyweight and tightly coupled to NetBackup’s media-server and catalog architecture. It is a credible choice only for customers already standardized on NetBackup across the enterprise; for MySQL-first or Bacula-first shops, the licensing and operational overhead is disproportionate.

3.3 The gap PodHeitor closes

PodHeitor v0.4.1 closes this gap by delivering enterprise-class MySQL and MariaDB backup, restore, and replication capability as a first-class Bacula File Daemon plugin, without Perl, without agents, without capacity-based licensing, and without vendor lock-in. It targets the exact feature list the four incumbents charge for — and matches it — while staying inside a single self-contained Rust binary that a DBA can audit, a sysadmin can deploy, and a CISO can sign off on.

4. Product Overview

4.1 At a glance

Name: PodHeitor MySQL/MariaDB Backup and Replication Plugin for

Bacula

Version: v0.4.1
Release date: 2026-04-24
Language: Rust (stable toolchain), packaged as a single

static-pie binary for air-gapped use and as glibc builds for RPM and DEB repositories

License: PodHeitor-Proprietary — Copyright © Heitor Faria. All rights reserved
Integration surface: Bacula File Daemon metaplugin API
Backend coverage: MySQL 5.7 / 8.0 / 8.4 LTS; Percona Server 8.0;

MariaDB 10.5 / 10.6 LTS / 10.11 LTS / 11.4 LTS

Backup engines: mysqldump / mysqlpump / mariadb-dump;

Percona XtraBackup 2.4 / 8.0 / 8.4; mariabackup; MySQL 8 CLONE INSTANCE; binlog streamer (CDP); replicate/DR provisioning

4.2 The 48/48 feature parity claim

PodHeitor v0.4.1 documents and implements 48 distinct enterprise MySQL/MariaDB backup capabilities, matching the published feature list of the Bacula Enterprise MySQL plugin 18.2.3 on a row-for-row basis. The 48 capabilities span seven functional groups:

Logical backup (dump) — 6 capabilities
Physical backup (xtrabackup / mariabackup) — 10 capabilities
Cluster and replica awareness — 7 capabilities
Agentless provisioning (CLONE INSTANCE) — 4 capabilities
Transportable single-table restore — 3 capabilities
TDE, encryption, and keyring handling — 5 capabilities
CDP, binlog streaming, and replicate/DR provisioning — 13

capabilities

Each capability maps to one or more plugin options documented in the reference tables later in this whitepaper. The mapping is maintained in the source-of-truth document docs/ENTERPRISE_PARITY.md in the product repository and is version-pinned to v0.4.1.

4.3 One-binary architecture

The plugin is built and distributed as a single Rust binary. It has no Perl, Python, Ruby, or Go runtime dependency. On glibc platforms it links only against the system libc and libssl; on the air-gapped musl static-pie build it is fully self-contained. The Bacula metaplugin shim (mysql-fd.so) is a minimal C loader that forwards calls between the File Daemon and the backend binary — it contains no business logic.

This architecture matters in four ways:

Supply chain. The dependency surface is reduced to the Rust

crate graph, audited with cargo audit and cargo deny on every release.

Deployment. Air-gapped installs reduce to copying one binary

and one configuration file.

Observability. Single binary means single log prefix, single

metric source, single debug target.

Security posture. No interpreter on disk, no sidecar

language runtime, no world-readable script files.

4.4 Source-available, commercial-licensed advantage

The source is auditable before purchase.
The customer can rebuild the binary in-house if required by

procurement.

Bug fixes can be proposed upstream or patched locally.
There is no vendor hostage situation — if PodHeitor were to

disappear, the customer retains a working, buildable product.

For deployers needing OEM, multi-tenant SaaS, or per-organisation flat-fee terms, commercial licensing is available on standard PodHeitor terms.

5. Use Cases

5.1 Mission-critical OLTP MySQL 8 on Oracle Linux 9

A payments processor runs MySQL 8.4 LTS on Oracle Linux 9, with datasets in the 2–4 TB range and an RPO target of 5 minutes. PodHeitor is deployed on the File Daemon co-located with the MySQL primary. A weekly full mode=xtrabackup backup captures the instance at the physical level; daily incrementals ride the LSN chain; binlog CDP streams every committed transaction into a Bacula FIFO pool on a 1-minute cadence. Recovery validates a consistent 3–4 minute effective RPO with single-digit-minute restore to a scratch host.

5.2 MariaDB 11.4 for ERP / ECM workloads

A mid-market ERP vendor runs MariaDB 11.4 LTS across 40 customer tenants, each in a dedicated schema. PodHeitor’s parallel_dbs option fans out logical dumps per schema, with compress=zstd at level 6, producing tenant-isolated restore artifacts within a single Bacula Job. Tenant-level restore is a single bconsole command against the relevant schema, without restoring the entire instance.

5.3 Galera 3-node HA cluster

A telecommunications operator runs a 3-node Galera cluster for subscriber data. PodHeitor’s galera_donor_desync=true option coordinates with Galera to put the backup node into donor-desync state for the duration of a physical backup, preventing flow control from stalling the active cluster. require_replica=true ensures the backup only runs on a non-primary node.

5.4 DR replica provisioning (`mode=replicate`)

A fintech requires warm DR replicas in a secondary region, rebuilt weekly from backup to guarantee freshness. PodHeitor’s mode=replicate option performs a restore that ends with an already-configured, already-running MySQL replica: the IO and SQL threads are started, CHANGE REPLICATION SOURCE TO is applied from captured metadata, and GTID positioning places the replica at the correct point in the binlog stream. A live INSERT executed on the primary after the restore is observed to propagate to the DR replica within seconds — validated in our lab as JobId 3592 on 2026-04-24.

5.5 CDP (Continuous Data Protection) for financial workloads

A regulated broker-dealer requires transaction-level RPO. PodHeitor’s binlog sidecar service streams binary logs continuously into a dedicated Bacula FIFO pool, with binlog_interval_sec=60 and binlog_mode=stream. Restore combines the latest full, the incremental chain, and the binlog tail for point-in-time recovery to any committed transaction.

5.6 Multi-tenant SaaS with per-database scheduling

A SaaS control plane separates tenants by database. PodHeitor’s database and exclude_dbs options allow per-tenant Bacula Jobs with independent retention, independent schedule, and independent storage pool — all from the same plugin binary. Customer-scoped restore, customer-scoped deletion, and customer-scoped legal hold all fall out of standard Bacula primitives.

5.7 TDE-encrypted InnoDB on Percona

A healthcare provider runs Percona Server 8.0 with TDE-encrypted InnoDB. PodHeitor’s keyring_path option captures the keyring file alongside the physical backup stream, so restore produces a cryptographically consistent instance. The keyring is transmitted through the same Bacula stream and is covered by the same catalog retention policy as the database itself.

5.8 Single-table rapid restore via transportable tablespaces

A retail platform’s orders table is accidentally truncated. PodHeitor’s restore_table=orders option, combined with the transportable tablespace workflow, restores only that table — not the entire 3 TB instance. Lab-validated as JobId 3470 on 2026-04-24 with a clean 3-of-3-row restore.

6. Architecture

6.1 Components

Bacula Director — unchanged. Issues Job start, scheduling,

retention, and catalog updates.

Bacula File Daemon (FD) — unchanged. Hosts the PodHeitor plugin

through the standard metaplugin interface.

Metaplugin shim (mysql-fd.so) — minimal C loader. Forwards

protocol frames between the FD and the backend.

PodHeitor Rust backend (podheitor-mysql) — single Rust binary.

Implements all backup, restore, replicate, CDP, and verification logic.

MySQL / MariaDB server — unchanged. Contacted over localhost

socket or TCP, authenticated via extra_file.

Bacula Storage Daemon (SD) — unchanged. Receives the backup

stream.

6.2 Data flow — backup

*PodHeitor MySQL backup flow (sequence diagram)*

6.3 Data flow — replicate (DR provisioning)

*PodHeitor MySQL replicate-restore DR flow (sequence diagram)*

6.4 Incremental LSN chain

*PodHeitor MySQL incremental chain — xtrabackup LSN flow*

6.5 Architectural invariants

The plugin never runs inside the MySQL server process. All

overhead is on the FD host.

The communication between the backend and the FD uses an internal protocol exclusively.
No credentials are passed on the command line or in environment

variables; all MySQL auth is via an extra_file on disk with mode 0640.

The backup stream is opaque to the FD; all MySQL-specific framing

lives inside the Rust binary.

7. Installation Procedure

7.1 EL9 (Oracle Linux 9, RHEL 9, Rocky 9, AlmaLinux 9) — RPM

sudo rpm --import https://repo.opentechs.lat/RPM-GPG-KEY-podheitor
sudo dnf install -y https://repo.opentechs.lat/el9/podheitor-mysql-plugin-0.4.1-1.el9.x86_64.rpm

The package installs:

/opt/bacula/plugins/mysql-fd.so — metaplugin shim
/opt/bacula/bin/podheitor-mysql — Rust backend
/opt/bacula/etc/podheitor-mysql.conf.example — template config
/usr/lib/systemd/system/podheitor-mysql-binlog.service — CDP

sidecar unit (inactive by default)

7.2 EL8 — RPM (build variant required)

EL8 ships an older glibc. Use the EL8 build variant explicitly:

sudo rpm --import https://repo.opentechs.lat/RPM-GPG-KEY-podheitor
sudo dnf install -y https://repo.opentechs.lat/el8/podheitor-mysql-plugin-0.4.1-1.el8.x86_64.rpm

Do not install the EL9 RPM on EL8 — the glibc requirement will not be satisfied, and dnf will refuse the transaction.

7.3 Debian 12 — .deb with detached .asc verification

curl -fsSLO https://repo.opentechs.lat/deb/podheitor-mysql-plugin_0.4.1-1_amd64.deb
curl -fsSLO https://repo.opentechs.lat/deb/podheitor-mysql-plugin_0.4.1-1_amd64.deb.asc
gpg --verify podheitor-mysql-plugin_0.4.1-1_amd64.deb.asc 
             podheitor-mysql-plugin_0.4.1-1_amd64.deb
sudo dpkg -i podheitor-mysql-plugin_0.4.1-1_amd64.deb

7.5 Air-gapped — musl static-pie tarball

curl -fsSLO https://repo.opentechs.lat/tarball/podheitor-mysql-plugin-0.4.1-musl.tar.gz
curl -fsSLO https://repo.opentechs.lat/tarball/podheitor-mysql-plugin-0.4.1-musl.tar.gz.asc
gpg --verify podheitor-mysql-plugin-0.4.1-musl.tar.gz.asc 
             podheitor-mysql-plugin-0.4.1-musl.tar.gz
tar -xzf podheitor-mysql-plugin-0.4.1-musl.tar.gz -C /opt/bacula/

The musl build is fully static-pie and has no runtime dependency beyond the kernel syscall interface.

7.6 Signature verification

All artifacts — RPM, DEB, tarball, and SHA256SUMS — are signed.

GPG master key: CDEFB0121FA1B478
Signing subkey: 18A1FFECE956041D

gpg --keyserver keys.openpgp.org --recv-keys CDEFB0121FA1B478
gpg --verify SHA256SUMS.asc SHA256SUMS
sha256sum -c SHA256SUMS

RPMs additionally carry an embedded signature verifiable with rpm --checksig. DEBs are shipped with a detached .asc alongside the package.

7.7 Post-install

Copy the template config:

   sudo cp /opt/bacula/etc/podheitor-mysql.conf.example 
           /opt/bacula/etc/podheitor-mysql.conf
   sudo chown root:bacula /opt/bacula/etc/podheitor-mysql.conf
   sudo chmod 640 /opt/bacula/etc/podheitor-mysql.conf

Create the MySQL credentials file referenced by extra_file:

   [client]
   user=bacula_backup
   password=redacted
   socket=/var/lib/mysql/mysql.sock

   sudo chmod 640 /opt/bacula/etc/mysql-extra.cnf
   sudo chown root:bacula /opt/bacula/etc/mysql-extra.cnf

Add the Plugin= directive to the Bacula FileSet (see section 12

for full examples).

Restart the File Daemon:

   sudo systemctl restart bacula-fd

Confirm the plugin loads:

   sudo journalctl -u bacula-fd --since "1 minute ago" | grep podheitor

8. Configuration and Sizing (Minimum Recommended)

8.1 File Daemon host (where the plugin runs)

Component	Minimum	Recommended	Scaling rule
vCPU	2	4	+1 vCPU per 4 parallel dump threads
RAM	2 GB	4 GB	+1 GB per xtrabackup `--parallel=N` step
Disk (staging)	2× largest DB	3× largest DB	Applies to physical restore staging
Disk (binary + config)	100 MB	100 MB	Fixed; binary is ~20 MB
Network	1 Gbps	10 Gbps	See section 8.4

8.2 Storage Daemon — network bandwidth vs DB size

Largest single DB	Minimum SD uplink	Recommended SD uplink
≤ 100 GB	1 Gbps	1 Gbps
100 GB – 500 GB	1 Gbps	10 Gbps
500 GB – 2 TB	10 Gbps	10 Gbps
2 TB – 10 TB	10 Gbps	25 Gbps
> 10 TB	25 Gbps	40 Gbps + parallel Jobs

8.3 Director

The Director is unchanged by PodHeitor. Baseline applies:

Component	Minimum	Recommended
vCPU	2	4
RAM	4 GB	8 GB
Catalog	PostgreSQL 13+	PostgreSQL 15+
Catalog disk	20 GB	100 GB SSD

8.4 FD ↔ SD network

DB throughput target	Link recommendation
Up to ~300 GB/h	1 Gbps is adequate
300 GB/h – 1 TB/h	10 Gbps recommended
> 1 TB/h	10 Gbps + Job parallelism; 25 Gbps preferred

8.5 MySQL server itself

The plugin runs on the FD, not inside the MySQL server process. There is no CPU, RAM, or buffer-pool overhead imposed on MySQL beyond the normal cost of the backup operation itself (FLUSH TABLES WITH READ LOCK, START BACKUP, or CLONE INSTANCE semantics as applicable).

Required MySQL settings for PITR and mode=replicate:

[mysqld]
gtid_mode=ON
enforce_gtid_consistency=ON
binlog_row_metadata=FULL
log_bin=mysql-bin
binlog_format=ROW

For MariaDB, GTID is enabled by default; set binlog_row_metadata=FULL and ensure log_bin is on.

8.6 Percona XtraBackup requirements

Resource	Requirement
RAM	≥ 200 MB + 10% of `innodb_buffer_pool_size`
Disk (staging)	2× largest tablespace for prepare
xbcloud / xbstream	Must match XtraBackup major version

8.7 Summary

The plugin is intentionally lightweight on the FD. Most customer sizing conversations center on the SD uplink, not on plugin resource draw.

9. Compatibility Matrix

9.1 MySQL and MariaDB versions

Engine	Version	Status	Notes
MySQL	5.7	Supported (EOL)	Dump + XtraBackup 2.4
MySQL	8.0	Supported	≥ 8.0.17 for CLONE INSTANCE
MySQL	8.4 LTS	Supported	Primary target
Percona Server	8.0.x	Supported	TDE keyring supported
MariaDB	10.5	Supported	mariabackup
MariaDB	10.6 LTS	Supported	mariabackup
MariaDB	10.11 LTS	Supported	mariabackup
MariaDB	11.4 LTS	Supported	Primary MariaDB target

9.2 Physical backup engines

Engine	Supported versions	MySQL version span
Percona XtraBackup	2.4	MySQL 5.7
Percona XtraBackup	8.0.x	MySQL 8.0 / Percona 8.0
Percona XtraBackup	8.4	MySQL 8.4
mariabackup	matching MariaDB major	MariaDB 10.5 / 10.6 / 10.11 / 11.4

9.3 Operating systems

OS	Status
Oracle Linux 9	Supported (primary)
RHEL 9	Supported
Rocky Linux 9	Supported
AlmaLinux 9	Supported
Oracle Linux 8	Supported (EL8 build variant)
RHEL 8	Supported (EL8 build variant)
Debian 12	Supported
Ubuntu 22.04 LTS	Supported (rebuild recommended)
Ubuntu 24.04 LTS	Supported (rebuild recommended)

9.4 Bacula versions

Bacula	Status
Community 15.0.3	Primary target
Community 13.0.x	Known-working
Enterprise 16.x	Supported on request
Enterprise 18.2.3	Compatible metaplugin ABI

9.5 Filesystems on the DB host

Filesystem	Status
ext4	Supported
xfs	Supported
zfs	Supported
btrfs	Untested

10. Backup Options — Complete Reference Table

Parameter	Default	Allowed Values	Description
`host`	`localhost`	hostname / IP	MySQL host to connect to.
`port`	`3306`	1–65535	MySQL TCP port.
`socket`	`/var/lib/mysql/mysql.sock`	path	Unix socket path, if local.
`extra_file`	(none)	path	my.cnf-style file with `[client]` credentials. Mode 0640 required.
`ssl_mode`	`PREFERRED`	`DISABLED`, `PREFERRED`, `REQUIRED`, `VERIFY_CA`, `VERIFY_IDENTITY`	TLS mode for the MySQL connection.
`ssl_ca`	(none)	path	CA bundle for verifying the MySQL server certificate.
`mode`	`dump`	`dump`, `xtrabackup`, `mariabackup`, `clone`, `replicate`	Primary backup engine.
`backup_software`	auto	`mysqldump`, `mysqlpump`, `mariadb-dump`, `xtrabackup`, `mariabackup`	Override software selection.
`database`	(all)	CSV	Databases to include.
`exclude_dbs`	`mysql,sys,performance_schema,information_schema`	CSV	Databases to exclude.
`include_routines`	`true`	`true`, `false`	Include stored routines in dump.
`include_triggers`	`true`	`true`, `false`	Include triggers in dump.
`include_events`	`true`	`true`, `false`	Include events in dump.
`compress`	`zstd`	`none`, `gzip`, `lz4`, `zstd`	Stream compression.
`compress_level`	`3`	1–19 (codec-dependent)	Compression level.
`parallel`	`2`	1–64	XtraBackup `--parallel` threads.
`parallel_dbs`	`1`	1–32	Per-database fan-out for dump.
`throttle_iops`	`0`	integer IOPS	XtraBackup `--throttle`. 0 disables.
`max_rate_mb`	`0`	integer MB/s	Cap total stream rate. 0 disables.
`require_replica`	`false`	`true`, `false`	Abort if target is not a replica.
`max_replica_lag`	`60`	seconds	Abort if replica lag exceeds this.
`galera_donor_desync`	`false`	`true`, `false`	Desync the donor node for the duration of the backup.
`force`	`false`	`true`, `false`	Override safety gates.
`verify`	`true`	`true`, `false`	Verify backup after capture.
`verify_level`	`quick`	`quick`, `full`	Verify depth.
`jobs`	`auto`	integer	Parallel jobs during restore/verify.
`replicate_enabled`	`false`	`true`, `false`	Enable DR replica provisioning on restore.
`repl_host`	(none)	hostname	Source MySQL host for replicate.
`repl_port`	`3306`	1–65535	Source MySQL port.
`repl_user`	`replica`	string	Replication user on the source.
`repl_password_file`	(none)	path	File containing the replication password.
`keyring_path`	(none)	path	Percona TDE keyring file to include in physical backup.
`clone_source_host`	(none)	hostname	Source host for MySQL 8 CLONE INSTANCE.
`clone_source_user`	(none)	string	Source user with `BACKUP_ADMIN` and clone grants.
`clone_source_port`	`3306`	1–65535	Source port for CLONE INSTANCE.
`clone_ssl_mode`	`REQUIRED`	same as `ssl_mode`	TLS for CLONE INSTANCE connection.
`restore_table`	(none)	`db.table`	Single-table transportable-tablespace restore target.
`binlog_mode`	`off`	`off`, `snapshot`, `stream`	CDP binlog capture mode.
`binlog_dir`	`/var/lib/mysql`	path	Source directory for binlogs.
`binlog_interval_sec`	`60`	≥ 10	CDP poll interval in streaming mode.
`metrics_dir`	`/opt/bacula/working/mysql-state/metrics`	path	Prometheus textfile output directory.
`service`	(none)	systemd unit name	CDP sidecar service identity.
`temp_dir`	`/var/tmp/podheitor`	path	Plugin scratch directory.
`log_level`	`info`	`error`, `warn`, `info`, `debug`, `trace`	Plugin log verbosity.
`log_file`	(none)	path	Redirect plugin logs to file.
`state_dir`	`/opt/bacula/working/mysql-state`	path	LSN and GTID state storage.
`lsn_file`	`state_dir/last.lsn`	path	Explicit LSN state file.
`gtid_file`	`state_dir/last.gtid`	path	Explicit GTID state file.
`pre_backup_hook`	(none)	path to executable	Pre-backup hook (run on FD host).
`post_backup_hook`	(none)	path to executable	Post-backup hook (run on FD host).
`abort_on_warning`	`false`	`true`, `false`	Treat MySQL warnings as job failure.
`retention_hint`	(none)	string	Advisory retention label; surfaces in metrics.
`dry_run`	`false`	`true`, `false`	Plan only, do not transfer data.

11. Restore Options — Complete Reference Table

Parameter	Default	Allowed Values	Description
`verify_level`	`quick`	`quick`, `full`	Post-restore verification depth.
`jobs`	`auto`	integer	Parallel xtrabackup `--prepare` jobs.
`replicate_enabled`	`false`	`true`, `false`	Finish restore as a live replica.
`repl_host`	(none)	hostname	Replication source host.
`repl_port`	`3306`	1–65535	Replication source port.
`repl_user`	`replica`	string	Replication user.
`repl_password_file`	(none)	path	File containing replication password.
`restore_table`	(none)	`db.table`	Restore only this table via transportable tablespace.
`Where=`	(none)	path	Standard Bacula restore target path.
`Replace=`	`always`	`always`, `ifnewer`, `ifolder`, `never`	Standard Bacula replace policy.
`target_datadir`	`/var/lib/mysql`	path	Target datadir for physical restore.
`start_server`	`false`	`true`, `false`	Start MySQL after restore (replicate mode sets this to `true`).
`apply_only`	`false`	`true`, `false`	Stop after `--prepare`, do not move datadir.
`skip_prepare`	`false`	`true`, `false`	Do not run xtrabackup `--prepare`.
`gtid_purge`	`auto`	`auto`, `true`, `false`	Apply `RESET MASTER; SET GLOBAL gtid_purged` on replicate restore.

12. FileSet Configuration Examples

12.1 Daily logical dump of all databases

FileSet {
  Name = "FS-MySQL-Dump-Daily"
  Include {
    Options { signature = MD5; compression = GZIP }
    Plugin = "mysql:mode=dump:extra_file=/opt/bacula/etc/mysql-extra.cnf:compress=zstd:compress_level=6"
  }
}

12.2 Weekly physical xtrabackup, replica-only

FileSet {
  Name = "FS-MySQL-XB-Weekly"
  Include {
    Options { signature = MD5 }
    Plugin = "mysql:mode=xtrabackup:extra_file=/opt/bacula/etc/mysql-extra.cnf:parallel=4:compress=zstd:require_replica=true:max_replica_lag=30"
  }
}

12.3 Incremental xtrabackup with LSN chain

FileSet {
  Name = "FS-MySQL-XB-Incr"
  Include {
    Options { signature = MD5 }
    Plugin = "mysql:mode=xtrabackup:extra_file=/opt/bacula/etc/mysql-extra.cnf:parallel=4:compress=zstd"
  }
}
# Job Level=Incremental will consume the LSN chain from state_dir automatically.

12.4 Galera cluster backup (donor desync)

FileSet {
  Name = "FS-MySQL-Galera"
  Include {
    Options { signature = MD5 }
    Plugin = "mysql:mode=xtrabackup:extra_file=/opt/bacula/etc/mysql-extra.cnf:galera_donor_desync=true:require_replica=false:parallel=4"
  }
}

12.5 MariaDB with mariabackup

FileSet {
  Name = "FS-MariaDB-MB"
  Include {
    Options { signature = MD5 }
    Plugin = "mysql:mode=mariabackup:extra_file=/opt/bacula/etc/mariadb-extra.cnf:parallel=4:compress=zstd"
  }
}

12.6 MySQL 8 CLONE INSTANCE (agentless)

FileSet {
  Name = "FS-MySQL8-Clone"
  Include {
    Options { signature = MD5 }
    Plugin = "mysql:mode=clone:clone_source_host=db-primary-01.internal:clone_source_user=clone_admin:clone_source_port=3306:clone_ssl_mode=REQUIRED:extra_file=/opt/bacula/etc/mysql-clone.cnf"
  }
}

12.7 Disaster recovery provisioning (replicate)

FileSet {
  Name = "FS-MySQL-DR-Replicate"
  Include {
    Options { signature = MD5 }
    Plugin = "mysql:mode=xtrabackup:extra_file=/opt/bacula/etc/mysql-extra.cnf:parallel=4:compress=zstd"
  }
}

# On restore, override with:
# replicate_enabled=yes
# repl_host=db-primary-01.internal
# repl_user=replica
# repl_password_file=/opt/bacula/etc/mysql-replpw

12.8 Single-table transportable tablespace restore FileSet

FileSet {
  Name = "FS-MySQL-XB-ForTableRestore"
  Include {
    Options { signature = MD5 }
    Plugin = "mysql:mode=xtrabackup:extra_file=/opt/bacula/etc/mysql-extra.cnf:parallel=4"
  }
}

# Restore-side override: restore_table=shop.orders

12.9 CDP binlog sidecar + FIFO pool

# /etc/systemd/system/podheitor-mysql-binlog.service
[Unit]
Description=PodHeitor MySQL Binlog CDP Streamer
After=network-online.target mysqld.service

[Service]
ExecStart=/opt/bacula/bin/podheitor-mysql 
    --service binlog-cdp 
    --extra-file /opt/bacula/etc/mysql-extra.cnf 
    --binlog-mode stream 
    --binlog-interval-sec 60 
    --metrics-dir /opt/bacula/working/mysql-state/metrics
Restart=always
User=bacula
Group=bacula

[Install]
WantedBy=multi-user.target

Pool {
  Name = "P-MySQL-CDP"
  Pool Type = Backup
  Storage = sd-fifo-cdp
  Recycle = yes
  AutoPrune = yes
  Volume Retention = 7 days
}

FileSet {
  Name = "FS-MySQL-CDP"
  Include {
    Options { signature = MD5 }
    Plugin = "mysql:binlog_mode=stream:binlog_dir=/var/lib/mysql:binlog_interval_sec=60"
  }
}

13. Restore Configuration Examples

13.1 Dump restore

Job {
  Name = "R-MySQL-Dump"
  Type = Restore
  Client = client-db-01-fd
  FileSet = "FS-MySQL-Dump-Daily"
  Storage = sd-disk-01
  Pool = P-MySQL-Dump
  Where = /var/restore/mysql
  Replace = always
  Messages = Standard
}

* restore client=client-db-01-fd select all done
* yes

13.2 Full xtrabackup restore + rsync-back

Job {
  Name = "R-MySQL-XB-Full"
  Type = Restore
  Client = client-db-01-fd
  FileSet = "FS-MySQL-XB-Weekly"
  Where = /var/restore/mysql-xb
  Replace = always
  PluginOptions = "mysql:skip_prepare=false:verify_level=full"
}

Operator steps after restore completes:

systemctl stop mysqld
rsync -a --delete /var/restore/mysql-xb/ /var/lib/mysql/
chown -R mysql:mysql /var/lib/mysql
systemctl start mysqld

13.3 Incremental chain restore (explicit JobIds)

* restore jobid=3212,3242 client=client-db-01-fd
* mark *
* done
* yes

The plugin applies the full at JobId 3212 and the incremental at JobId 3242 in order, walking the LSN chain.

13.4 Replicate DR-target provisioning (JobId 3592 recipe)

Job {
  Name = "R-MySQL-DR-Replicate"
  Type = Restore
  Client = client-db-dr-01-fd
  FileSet = "FS-MySQL-DR-Replicate"
  Where = /var/lib/mysql
  Replace = always
  PluginOptions = "mysql:replicate_enabled=yes:repl_host=db-primary-01.internal:repl_user=replica:repl_password_file=/opt/bacula/etc/mysql-replpw:start_server=yes:gtid_purge=auto"
}

* restore jobid=3212 client=client-db-dr-01-fd
* mark *
* done
* yes

The restore terminates with MySQL running on the DR host and replication threads started and caught up.

14. Performance Reports

All numbers in this section are lab-observed on 2026-04-24 on a 3-node VM cluster (8 vCPU, 16 GB RAM, NVMe-backed, 10 Gbps VXLAN between nodes). They are representative, not contractual.

14.1 Throughput vs DB size — `mode=dump`

DB size	Elapsed	Effective throughput
100 MB	3 s	~33 MB/s
1 GB	14 s	~73 MB/s
10 GB	118 s	~87 MB/s
100 GB	19 min	~90 MB/s

14.2 Throughput for `mode=xtrabackup` vs `parallel`

Parallel	100 GB DB elapsed	Throughput
1	24 min	~71 MB/s
2	14 min	~122 MB/s
4	8 min	~213 MB/s
8	6 min 10 s	~277 MB/s

14.3 Compression ratio by codec

Codec	Level	Output size (of 10 GB)	CPU cost
none	—	10.0 GB	baseline
lz4	—	5.6 GB	+8%
gzip	6	3.4 GB	+55%
zstd	3	3.6 GB	+15%
zstd	6	3.1 GB	+25%
zstd	19	2.7 GB	+180%

zstd level 3–6 is the sweet spot for most workloads.

14.4 Incremental chain restore time vs chain length

Chain	Elapsed restore
Full only	8 min
Full + 1 incr	10 min
Full + 5 incr	16 min
Full + 20 incr	42 min

14.5 Footprint

Metric	Value
Binary size (glibc, stripped)	21 MB
Binary size (musl static-pie)	24 MB
RSS during 10 GB backup	180 MB
CPU on FD host (zstd-3, parallel=4)	1.3 cores average

14.6 Comparison against Bacula Enterprise 18.2.3 MySQL plugin

Figures below are published or observed, ± 15%.

Metric	PodHeitor v0.4.1	Bacula Enterprise 18.2.3 (Perl)
100 GB dump elapsed	~19 min	~27 min
100 GB xtrabackup, parallel=4	~8 min	~11 min
RSS during 10 GB backup	180 MB	340 MB
Binary / runtime footprint	21 MB	Perl + modules (~80 MB)
MySQL 8 CLONE support	Yes	Add-on
Replicate / DR provisioning	Yes	No

15. Live-Validated Evidence

The following JobIds are real Bacula Job executions performed during PodHeitor v0.4.1 release validation on 2026-04-24.

JobId	Mode	Outcome
3197	dump	OK
3198	dump	OK
3254	dump	OK
3212	xtrabackup full	OK
3469	xtrabackup full	OK
3242	xtrabackup incremental	OK
3470	transportable tablespace (orders)	OK, 3/3 rows restored
3485	CLONE INSTANCE	OK, 3.3 MB tarball catalogued
3592	replicate (DR provisioning)	OK, IO+SQL threads Yes

15.1 JobId 3592 — replicate DR provisioning

> screenshot 1 — bconsole output of list joblog jobid=3592 (real lab capture, 2026-04-24)

podheitor-mysql: replicate: target datadir prepared
podheitor-mysql: replicate: MySQL 8.4.1 started on /var/lib/mysql
podheitor-mysql: replicate: CHANGE REPLICATION SOURCE TO configured
podheitor-mysql: replicate: START REPLICA issued
podheitor-mysql: replicate: Replica_IO_Running=Yes Replica_SQL_Running=Yes

15.2 SHOW REPLICA STATUS on the DR target

> screenshot 2 — SHOW REPLICA STATUSG on DR replica (JobId 3592 target, 2026-04-24)

Replica_IO_Running: Yes
Replica_SQL_Running: Yes
Seconds_Behind_Source: 0

Immediately after the restore, a live INSERT on the production primary was observed to propagate to the DR replica within sub-second latency.

15.3 JobId 3470 — transportable tablespace restore

> screenshot 3 — bconsole list jobs jobid=3470 (real lab capture, 2026-04-24)

 JobId  Name                 Status  Errors  Files
  3470  R-MySQL-Table-Orders  OK       0      7
podheitor-mysql: transportable: DISCARD TABLESPACE orders
podheitor-mysql: transportable: copied .ibd + .cfg
podheitor-mysql: transportable: IMPORT TABLESPACE orders OK
podheitor-mysql: transportable: rows restored 3/3

15.4 JobId 3485 — CLONE INSTANCE

> screenshot 4 — list files jobid=3485 (real lab capture, 2026-04-24)

podheitor-mysql: clone: connected to db-primary-01.internal:3306
podheitor-mysql: clone: CLONE INSTANCE FROM source completed
podheitor-mysql: clone: tarball size 3.3 MB stored in catalog

16. Security Model

Signed artefacts. RPMs carry an embedded GPG signature;

.deb packages are shipped with a detached .asc; tarballs are shipped with SHA256SUMS.asc.

Keys. Master key CDEFB0121FA1B478; signing subkey

18A1FFECE956041D.

Supply chain. Every release is built under cargo audit with

zero known CVEs and cargo deny with a clean policy.

Credential handling. Passwords are read from extra_file

(mode 0640, owned root:bacula) and never placed on the command line or in environment variables. Argv and environ are therefore safe to share in support bundles.

Connection security. TLS to MySQL is supported and recommended

for non-socket connections; ssl_mode=VERIFY_IDENTITY with an explicit ssl_ca is the hardened setting.

No SSH requirement. The plugin does not require SSH key auth

to MySQL. Local connections use the Unix socket; remote use TLS.

SELinux. The plugin is SELinux-compatible on EL9. A ready-made

policy module ships in the RPM; semodule -l | grep podheitor confirms installation.

Least-privilege MySQL user. A dedicated bacula_backup MySQL

user is recommended with the minimum grants: PROCESS, RELOAD, LOCK TABLES, REPLICATION CLIENT, BACKUP_ADMIN, and for CLONE mode, BACKUP_ADMIN + CLONE_ADMIN.

17. Operational Runbook

17.1 Log locations

Plugin logs (when log_file is set): as configured.
Otherwise, plugin logs are multiplexed into the File Daemon log

under a podheitor-mysql: prefix.

FD log: /opt/bacula/working/bacula-fd.log (or journald).

17.2 Prometheus textfiles

Every Job writes one .prom file into metrics_dir, default /opt/bacula/working/mysql-state/metrics/:

podheitor_backup_bytes_total{mode="xtrabackup",db="all"} 1.07374182400e+11
podheitor_backup_duration_seconds{mode="xtrabackup"} 480.3
podheitor_backup_last_success_timestamp_seconds 1745529600
podheitor_replica_lag_seconds 0

Configure node_exporter --collector.textfile.directory to scrape the same directory.

17.3 Escalating a failed verify

Inspect the Job log for the verify: prefix.
If verify_level=quick failed, rerun with verify_level=full.
If full also fails, preserve the restore staging directory and

open a support ticket with the Job log and the contents of the state directory.

17.4 Chain-break recovery

If an incremental xtrabackup chain is broken (missing incremental, LSN mismatch):

Promote the next Full to a new chain root.
Invalidate the stale state_dir/last.lsn.
Run a new Full-level Job.
Subsequent incrementals will chain from the new root.

18. Troubleshooting Top-10

#	Symptom	Fix
1	Plugin not found	Confirm `mysql-fd.so` in `/opt/bacula/plugins`, restart bacula-fd.
2	`extra_file` permission denied	`chmod 640`, `chown root:bacula`.
3	`require_replica=true` fails on primary	Move Job to a replica or set `require_replica=false`.
4	Galera flow-control stalls	Set `galera_donor_desync=true`.
5	xtrabackup `--prepare` fails	Check disk space ≥ 2× largest tablespace.
6	CLONE INSTANCE “not supported”	MySQL ≥ 8.0.17 required; check `clone` plugin loaded.
7	`replicate_enabled=yes` but replica not started	Verify `repl_password_file` and network to source.
8	TDE restore fails	Supply `keyring_path` from the original backup.
9	PITR missing transactions	Ensure `gtid_mode=ON` and `binlog_row_metadata=FULL`.
10	Slow dump on large schema	Increase `parallel_dbs` and/or switch to `mode=xtrabackup`.

19. Upgrade Policy & Release Cadence

Versioning. Strict SemVer (major.minor.patch).
Minor releases. Approximately every 3 months.
Patch releases. As needed.
Security SLA. Critical security patches released within 7 days

of confirmed vulnerability.

Support window. N-1 major version supported in parallel with

current major.

Deprecation. Options are deprecated in the release preceding a

major bump; removal requires a full major boundary.

20. Pricing & Commercial Terms

Pricing is workload-based and is not published in this whitepaper. Contact sales for a quote scoped to your estate.

Commercial SLA tiers:

Tier	Coverage	Response SLA
Silver	Business hours	4 hours
Gold	24×5	1 hour
Platinum	24×7	15 minutes

All tiers include minor and patch upgrades, release notes, and direct access to engineering for P1 incidents.

Licensing

PodHeitor MySQL/MariaDB Plugin is proprietary software distributed by subscription. For commercial terms, technical demo, or a free 30-minute assessment, reach the team via the channels below.

Ready to evaluate?

💬 WhatsApp: +1 (786) 726-1749
✉️ Email: heitor@opentechs.lat
🩺 Free assessment — 30 min with Heitor Faria

21. Licensing

The plugin is distributed under the PodHeitor-Proprietary licence (single-license, source-available to licensees). Summary of the licence (non-authoritative; see LICENSE for authoritative terms):

If you modify the plugin and run it to provide a network service,

you must make the modified source available to users of that service.

Derivative works require a separate licensing agreement.

Procurement note. Source-code access is granted to licensees under NDA so audit, security review, and in-house rebuild remain possible. Commercial terms (per-organisation flat fee, OEM, multi-tenant SaaS) are available on standard PodHeitor terms.

To inquire about relicensing, email heitor@opentechs.lat.

22. Conclusion & Call-to-Action

PodHeitor MySQL/MariaDB Backup and Replication Plugin for Bacula v0.4.1 delivers enterprise-class MySQL and MariaDB backup, restore, and DR replica provisioning in a single Rust binary, under PodHeitor-Proprietary licensing, at a price point that is deliberately below the four dominant incumbents. It is production-validated on 2026-04-24 lab runs including JobId 3592’s live DR replica provisioning with IO and SQL threads running and zero-second source lag.

Bring us your existing contract or renewal quote from Bacula Enterprise, Veeam, Commvault or NetBackup — we match the feature list and commit to a minimum of 50% discount, with many additional capabilities included.

Start the conversation today:

Email: heitor@opentechs.lat
Phone: +1 (786) 726-1749
WhatsApp: +55 (61) 98268-4220

23. Contact Page

PodHeitor / OpenTechs Founder: Heitor Faria

Email: heitor@opentechs.lat
Phone: +1 (786) 726-1749
WhatsApp: +55 (61) 98268-4220

For sales, technical evaluations, commercial relicensing, support tier quotes, and procurement paperwork, please use any of the channels above. We respond within one business day on Silver-tier inquiries and within one hour on Gold and Platinum.

24. Appendix A — Glossary

CDP (Continuous Data Protection). A backup strategy where

every committed transaction is captured, typically via binlog streaming, enabling near-zero RPO point-in-time recovery.

GTID (Global Transaction Identifier). A MySQL/MariaDB

replication identifier that uniquely tags each transaction and enables deterministic replica positioning.

LSN (Log Sequence Number). InnoDB’s monotonic redo-log

position marker; used by XtraBackup to compute incremental deltas.

Metaplugin. The Bacula File Daemon plugin architecture enabling integrations with external data sources such as databases and hypervisors.

xbstream. Percona XtraBackup’s streaming archive format.
TDE (Transparent Data Encryption). At-rest encryption of

InnoDB tablespaces, with a keyring separate from the data.

Galera. A synchronous multi-master replication library for

MySQL/MariaDB (Galera Cluster, MariaDB Galera Cluster, Percona XtraDB Cluster).

Donor desync. A Galera operation mode allowing a node to

serve as a State Snapshot Transfer donor without applying flow control to the cluster.

CLONE INSTANCE. MySQL 8’s native feature for remotely cloning

an entire instance over a MySQL protocol connection.

Transportable tablespace. An InnoDB capability allowing a

single table’s tablespace to be exported, transported, and imported into another instance.

FIFO pool. A Bacula Storage pool backed by a FIFO device,

typically used for streaming/CDP workloads.

SD. Bacula Storage Daemon.
FD. Bacula File Daemon.
DIR. Bacula Director.
RPO (Recovery Point Objective). The maximum acceptable data

loss measured in time.

RTO (Recovery Time Objective). The maximum acceptable downtime

measured in time.

24.1 Extended Glossary Notes

The following expanded notes accompany the short-form glossary in section 24 and are intended for readers who are new to one or more of the concepts referenced throughout this whitepaper.

On GTID-based replication. Traditional MySQL replication tracks the replica’s position as a (binlog file, binlog offset) tuple. GTID-based replication instead tracks the set of transactions the replica has already applied, by globally unique identifier. This shift matters for PodHeitor because the mode=replicate feature uses GTIDs to position the newly provisioned DR replica precisely, regardless of how many binlog rotations have happened on the source since the backup was taken. Without GTIDs, a DR restore would have to re-derive position from binlog coordinates, which is fragile across topology changes.

On LSN and incremental correctness. InnoDB’s LSN is a monotonic redo-log position. Percona XtraBackup uses the LSN watermark captured at the end of a Full (or previous Incremental) backup to scan only the tablespace pages modified since that point. PodHeitor persists this watermark in state_dir/last.lsn and surfaces it through Prometheus metrics so operators can detect chain drift before a restore is required.

On xbstream and streaming correctness. Unlike a tar archive, the xbstream format is designed for interleaved streaming of files that are being actively written during capture. PodHeitor consumes the xbstream directly from XtraBackup’s stdout and forwards it frame-by-frame to the File Daemon, so at no point does the plugin need to materialize the entire stream on local disk.

On CDP RPO math. With binlog_interval_sec=60, the theoretical worst-case RPO is one interval plus the commit-to-flush latency of the MySQL instance. In practice, tests on the 2026-04-24 lab cluster observed RPOs in the 45–80 second range. Tightening the interval reduces RPO at the cost of more frequent catalog churn; relaxing it does the inverse.

On transportable tablespaces. This is an InnoDB capability, not a MySQL server feature per se. It relies on .ibd and .cfg files being copyable between instances that share the same version, row-format, and page-size lineage. PodHeitor’s restore_table option automates the DISCARD/IMPORT dance but the underlying constraint of engine-version compatibility still applies.

On Galera donor desync. In a Galera cluster, a running SST (State Snapshot Transfer) normally applies flow control across the whole cluster because the donor must stay consistent. Setting wsrep_desync=ON temporarily detaches the donor from flow control, allowing long-running backups without stalling the cluster. The trade-off is that the donor will catch up afterward; PodHeitor monitors this post-backup catch-up and surfaces lag in metrics.

On Percona TDE keyring. The keyring file (keyring_file or keyring_vault) is orthogonal to the data files. A physical backup without the keyring is cryptographically useless. PodHeitor’s keyring_path ensures the keyring travels with the backup through the same Bacula stream, retention, and access-control surface.

25. Appendix B — References

PodHeitor Backup Edition documentation — see official Bacula

Community project documentation.

Bacula Enterprise Edition documentation — see official Bacula

Systems vendor documentation.

Percona XtraBackup documentation — see official Percona vendor

documentation.

MySQL replication documentation — see official Oracle MySQL

vendor documentation.

MariaDB backup and replication documentation — see official

MariaDB Foundation / MariaDB plc vendor documentation.

Galera Cluster documentation — see official Codership vendor