You can find this document as PDF here.
1. About
The FromDual Backup and Recovery Manager for MariaDB and MySQL (brman
) is an application to ease the use of the various MariaDB/MySQL backup tools. The Problem with MariaDB/MySQL backup tools is, that they have many options and thus are over-complicated and errors are easy made.
bman
has the intention to make backups for MariaDB/MySQL easier and technically correct. This means it should per default not allow non-consistent backups or complain if some functions or parameters are used in the wrong way to guarantee proper backups.
In addition it has added some nice features which are missing in standard MariaDB/MySQL backup tools or which are only known from Enterprise backup solutions.
1.1. Where to download brman
The FromDual Backup and Recovery Manager for MariaDB and MySQL (brman
) can be downloaded from our website.
1.2. What brman
users say about
Ow! Nice! FromDual Backup Manager is a very nice tool! Congratulations for FromDual! I made a shell script for catalog and maintained backups by
xtrabackup
, butbman
is the best!
Xtrabackup + bman!!!!
1.3. What is supported by brman
?
FromDual Backup and Recovery Manager supports:
-
Supported Operating Systems: Linux. Other UNIX like Operating Systems like BSD or MacOSX may work or not. Windows most probably does NOT work.
-
Supported Linux Distributions: Red Hat/Rocky Linux 8 and 9 (other Red Hat derivatives may work), Debian 11 - 12, Ubuntu LTS: 20.04, 22.04 and 24.04, SUSE 12 and 15 probably work. Other Linux distributions we do NOT know.
-
MariaDB 10.5 to 11.4, MySQL/Percona Server 5.7 and 8.0 are supported. We could not test MySQL 8.4 yet.
-
MariaDB Backup, Percona Xtrabackup and MySQL Enterprise Backup are supported.
2. Backup and Recovery Manager Installation Guide
2.1. Introduction
The FromDual Backup an Recovery Manager (brman
) for MariaDB and MySQL is an easy to use CLI application for creating MariaDB and MySQL backups.
Its main purpose is to ease the many difficult ways of doing MariaDB and MySQL backups.
Fromdual brman
is written in PHP and works best on Linux systems. Other UNIX like systems may work as well.
2.2. Adding FromDual DEB repository
Adding the FromDual DEB/APT repository as described here. Then install brman
with the following command:
2.3. Debian
2.3.1. Install brman
on Debian 11 (Bullseye) and Debian 12 (bookworm)
apt install brman
For ease of use add the following line to your shell profile (e.g. ~/.bashrc
):
export PATH=${PATH}:/opt/brman/bin bman --version
2.4. Ubuntu
2.4.1. Install brman
on Ubuntu 20.04 LTS (Focal Fossa), Ubuntu 22.04 (Jammy Jellyfish) and Ubuntu 24.04 (Noble Numbat)
apt install brman
For ease of use add the following line to your shell profile (e.g. ~/.bashrc
):
export PATH=${PATH}:/opt/brman/bin bman --version
2.5. Adding FromDual RPM repository
Adding the FromDual RPM repository as described here. Then install brman
with the following command:
2.6. Red Hat / Rocky Linux / AlmaLinux
2.6.1. Install brman
on Red Hat 8 and 9 / Rocky Linux 8 and 9 / AlmaLinux 8 and 9
We did not test yet if PHP 8.0 or 7.3 and older also works. Please try it out and let us know your results…
dnf install https://rpms.remirepo.net/enterprise/remi-release-<8 or 9>.rpm dnf update dnf install brman php83-php-pecl-yaml
For ease of use add the following line to your shell profile (e.g. ~/.bashrc
):
export PATH=${PATH}:/opt/brman/bin bman --version
2.7. Installation of brman
from a binary tar ball
Download FromDual Backup and Recovery Manager for MariaDB and MySQL from here.
export RELEASE=2.3.0 cd /tmp wget https://support.fromdual.com/admin/download/brman-${RELEASE}.tar.gz tar -C /opt -xf brman-${RELEASE}.tar.gz ln -s /opt/brman-${RELEASE} /opt/brman
For ease of use add the following line to your shell profile (e.g. ~/.bashrc
):
export PATH=${PATH}:/opt/brman/bin bman --version
2.8. Creating a brman
database user
For convenience we recomend the brman
user as follows:
CREATE USER 'brman'@'127.0.0.1' IDENTIDIFIED BY '<a_secret_Password>'; GRANT ALL ON *.* TO 'brman'@'127.0.0.1';
If you want to do the backup also from remote machines (logical backup only) you can use '%'
or an IP address or an IP range for the host part.
The minimal required privileges for full logical backup are:
GRANT SHOW DATABASES, EVENT on *.* TO 'brman'@'127.0.0.1'; GRANT SELECT on *.* TO 'brman'@'127.0.0.1'; GRANT SHOW VIEW on mysql.user TO 'brman'@'127.0.0.1';
Additonally for a full physical backup the following privileges are required:
GRANT RELOAD, PROCESS, CONNECTION ADMIN on *.* TO 'brman'@'127.0.0.1';
2.9. Upgrading brman
Upgrading brman
is typically quite easy:
INST_DIR=${HOME}/product VERSION=9.9.9 shell> cd ${INST_DIR} shell> tar xf /download/brman-${VERSION}.tar.gz shell> rm -f brman shell> ln -s brman-${VERSION} brman
If you were installing brman via your distribution package manager the following command is sufficient:
shell> apt upgrade brman # On DEB based systems shell> dnf upgrade brman # On RPM based systems
For further details see the specific release notes.
3. FromDual Backup Manager (bman
)
3.1. Where can bman
help you
The intention of bman
is to assist you in bigger MariaDB/MySQL set-ups where you have to follow some backup policies and where you need a serious backup concept.
3.2. bman
example
To give you an impression of the power of the FromDual Backup Manager (bman
) let us have a look at a little example:
shell> bman --target=brman:secret@192.168.1.42 --type=full --mode=logical --policy=daily \ --no-compress --backupdir=/mnt/slowdisk \ --archive --archivedestination=file:///mnt/nfsmount
With this backup method we do a logical full backup (mysqldump
is triggered in the background). The backup is stored in the location for backups with the daily policy and is NOT compressed to speed up the backup by saving CPU power AND because the backup device is a de-duplicating drive. Then the backup is archived to and NFS mount.
3.3. Backup types
To achieve this we have defined different backup types:
Type | Description |
---|---|
full |
Do a full logical or physical backup ( |
binlog |
Do a binary log backup. |
config |
Do configuration file backup ( |
structure |
Do a structure backup (no data). |
cleanup |
Do a clean-up of backups older than n days. |
schema |
Do backup of one or more schemas (together or separated). |
privilege |
Do a privilege backup ( |
A backup type is specified with the option --type=<backup_type>
.
3.3.1. Binlog Backup
Binary Log Backup currently is only supported locally.
3.4. Backup modes
A backup can either be logical or physical. A logical backup is typically what you do with mysqldump
. A physical backup is typically a physical file copy without looking into the data. That is what for example mariadb-backup
does.
The backup mode is specified with the option --mode=<backup_mode>
. The following backup modes are available:
Mode | Description |
---|---|
logical |
Do a logical backup ( |
physical |
Do a physical backup ( |
3.5. Backup policies
Further we have introduced different backup policies. Policies are there to distinguish how different backups should be treated.
The following backup policies exist:
Policy | Description |
---|---|
daily |
Directory to store daily backups. |
weekly |
Directory to store weekly backups. |
monthly |
Directory to store monthly backups. |
quarterly |
Directory to store quarterly backups. |
yearly |
Directory to store yearly backups. |
binlog |
Directory to store binary log backups. |
For example you could plan to do a daily MariaDB/MySQL backup with binary logs with a retention policy of 7 days. But once a week you want to do a weekly backup consisting of a full backup, a configuration backup and a structure dump. But this weekly backup you want to keep for 6 months. And because of legal reasons you want to do a yearly backup with a retention policy of 10 years.
A backup policy is specified with the --policy=<backup_policy>
option. This leads us to the retention time:
3.6. Options
The retention time which should be applied to a specific backup policy you can specify with the option --retention=<period_in_days>
. The retention option means that a backup is not deleted before this amount of days when you run a clean-up job with bman
.
Let us do an example:
shell> bman --type=cleanup --policy=daily --retention=30
This means that all backups in the daily policy should be deleted when they are older than 30 days.
3.7. Target
With the --target
option you specify the connect string to the database to backup. This database can be located either local (all backup types can be used) or remote (only client/server backup types can be used (mysqldump
)).
A target looks as follows: user:password@host:port
(similar to URI specification) whereas you can omit password and port.
3.8. Backup location, archiving, compressing and clean-up
The --backupdir
option controls the location of the backup files. The policy folders (daily
, weekly
, monthly
, quarterly
and yearly
) are automatically created under the --backupdir
location.
If you have a second layer of backup stores (also called archive stores for example tapes or slow backup drives or de-duplicated drives or NFS drives) you can use the --archive
option to copy your backup files to this second layer storage which is specified with the --archivedestination
option. For faster restores it is recommended to always keep one or two generations of backups on your fast local drive.
If you want to remove (clean-up) the backuped files from the --backupdir
destination after the archive job has completed use the --cleanup
option.
If you want to remove (clean-up) the archived files from the archive location (--archivedestination
) use the option --archive
in combination with --type=cleanup
.
If you want to omit to compress backups, either to safe time or because your location uses de-duplicated drives you can use the --no-compress
option.
3.9. Per schema backup
Especially for shared hosting companies (or multi tenant applications) a full database backup is typically not the right backup strategy because a restore of one specific customer (= schema) is very complicated. For this case we have the --per-schema
option. bman
will do a backup of the whole database schema by schema. Keep in mind: This breaks consistency among schemas!
Sometimes you want to do a schema backup only for some specific schemas for this you can use the --schema
option. This option allows you to specify schemas to backup or not to backup. --schema=+a,+b
means backup schema a and b. --schema=-a,-b
means backup all schemas except a and b.
The second variant is less error prone because you do not forget to backup a new schema.
3.10. Instance name
MariaDB/MySQL does not know the concept of naming an instance (mysqld
). But for bigger environments it could be useful to uniquely name each instance. For this purpose we have introduced the option --instance-name=<give_it_a_name>
. This instance name should be unique within your whole company. But we do not enforce it atm. The instance name is used to name backup files and later to identify the backup history of an instance in our backup catalog and to allow us to track the files for restore.
3.11. bman
configuration file
Specifying everything on the command line is cumbersome. Thus bman
considers a configuration file specified with the --config=<config_file>
option.
A bman
configuration file looks for example as follows:
policy = daily target = brman:secret@127.0.0.1:3306 type = schema schema = -mysql archive = on archivedestination = file:///mnt/tape per-schema = on no-compress = on no-memory-table-check = on
3.12. Simulate what happens
For the Sissies among us (as for example me) we have the --simulate
option. This option simulates nearly all steps as far as possible without executing really anything. This option is either for testing some features or for debugging purposes.
3.13. Logging
If you want to track your backup history you can specify with the --log
option where your bman
log file should be located.
3.14. Using Catalog
It will be very useful when you can store your backups metadata in the database so you can check them in the future and to find out the backup criteria (type, mode, instance-name, … etc) for specific backup processes. This could be achieved by using the catalog feature.
To activate this feature you have to create a schema for the catalog "default name is brman_catalog`" then create its tables by using the option `--create
in a special bman
command (check examples below).
Finally, to store your backup metadata in the catalog what you only have to do is adding the option --catalog=catalog_connection_string
to the normal bman
command.
Check the examples below for using catalog in bman
.
3.15. Special cases and workarounds
If your application is dropping tables during your bman
Backup and bman
is returning errors you find here some workarounds: Dropped Tables with FromDual Backup Manager.
3.16. Backup Manager (bman
) Examples
3.16.1. Example: Getting bman
version and help
To just see if bman
works correctly just run:
shell> bman --version
To get a compact help of what bman
can do run the following command. This output is the most reliable and most up-to-date source of information about brman (documentation may not be up-to-date):
shell> bman --help
3.16.2. Example: Full logical backup
Do a full (logical = default) backup and store it in the daily policy folder:
shell> bman --target=brman:secret@127.0.0.1:3306 --type=full --policy=daily
3.16.3. Example: Full physical backup
Do a full physical backup and store it in the weekly policy folder:
shell> bman --target=brman:secret@127.0.0.1 --type=full --mode=physical --policy=weekly
3.16.4. Example: Full binary log backup
Do a binary log backup omitting the password in the target and store it in the binlog
policy folder. The binary logs should NOT be purged during the backup (by default they would be purged):
shell> bman --target=brman@192.168.1.42:3307 --type=binlog --policy=binlog --no-purge
3.16.5. Example: Schema backup omitting some schemas
Do a schema backup omitting the mysql
schema:
shell> bman --target=brman:secret@127.0.0.1:3306 --type=schema --schema=-mysql \ --policy=daily --archive --archivedestination=file:///mnt/tape
3.16.6. Example: Schema backup of some schemas
Do a schema backup only of foodmart
and world
and write each backup to its own own file. Omit compressing these backups because they are located for example on deduplicated drives:
shell> bman --target=brman:secret@127.0.0.1:3306 --type=schema \ --schema=+foodmart,+world --per-schema --policy=daily --no-compress
3.16.7. Example: Configuration backup into weekly policy
Do a configuration backup (my.cnf
) and store it in the weekly policy folder:
shell> bman --target=brman:secret@127.0.0.1:3306 --type=config --policy=weekly
3.16.8. Example: Structure backup into monthly policy
Do a structure backup and store it in the monthly policy folder and name the file with the instance name:
shell> bman --target=brman:secret@127.0.0.1:3306 --type=structure --policy=monthly \ --instance-name=prod-db
3.16.9. Example: Weekly structure backup to other location
Do a weekly structure backup and archive it to an other backup location:
shell> bman --target=brman:secret@127.0.0.1:3306 --type=structure --policy=weekly \ --archive --archivedestination=file:///mnt/tape
3.16.10. Example: Privilege backup
Do a weekly privilege backup:
shell> bman --target=brman:secret@127.0.0.1:3306 --type=privilege --policy=weekly \ --mode=logical
3.16.11. Example: Privilege backup per schema
Do a daily privilege backup per schema:
shell> bman --target=brman:secret@127.0.0.1:3306 --type=privilege --policy=daily \ --per-schema
3.16.12. Example: Archiving an Cleaning
Archive backup to other location:
shell> bman --target=brman:secret@127.0.0.1:3306 --type=structure --policy=weekly \ --archive --archivedestination=file:///mnt/tape --cleanup
Cleanup old backups:
shell> bman --target=brman:secret@127.0.0.1:3306 --type=cleanup --policy=daily \ --retention=30d
Cleanup old backups from archive location:
shell> bman --target=brman:secret@127.0.0.1:3306 --type=cleanup --policy=daily \ --retention=30d --archive --archivedestination=file:///mnt/nfsmount
3.16.13. Example: Backup shipping
If you want to ship your backup to an other (backup) server after database backup you can use the option --archivedestination
. The protocols file
, scp
, sftp
and rsync
are supported:
shell> bman --target=brman:secret@127.0.0.1:3306 --type=full --policy=daily \ --archivedestination=sftp://backup@backup.example.com:22/home/backup/production/daily/
3.16.14. Example: Other options (--pass-through
)
If you want to pass through options to the underlying backup utility (mysqldump
, mariadb-backup
, xtrabackup
, mysqlbackup
) you can use the --pass-through
option. In the following example the mysqldump
utility omits dumping the CountryLanguage
table in a world
schema backup:
shell> bman --target=brman:secret@127.0.0.1:3306 --type=schema --mode=logical --policy=daily \ --schema=+world --pass-through="--ignore-table=world.CountryLanguage"
3.16.15. Example: Monitoring integration (fpmmm
)
If you are using the FromDual Performance Monitor for MariaDB and MySQL (fpmmm
) and/or Zabbix for database monitoring you can send the backup information also to your monitoring solution for getting trends and see errors or anomalies:
shell> bman --target=brman:secret@127.0.0.1:3306 --type=full --policy=daily \ --fpmmm-hostname=mariadb-103 --fpmmm-cache-file=/var/cache/fpmmm/fpmmm.FromDual.mariadb-103.cache
3.16.16. Example: Backup Catalog
Creation of a backup catalog (assuming you have created already a catalog schema with the default name brman_catalog
):
shell> bman --catalog=brman:secret@127.0.0.1:3306 --create
Backups against catalog:
shell> bman --target=brman:secret@127.0.0.1:3306 --catalog=brman:secret@127.0.0.1:3306 \ --instance-name=test --type=full --policy=daily
3.16.17. Example: Excluding a table or a schema from backup
If you want to exclude one or several tables from a logical brman backup you can use the --pass-through
option:
shell> bman --target=brman:secret@127.0.0.1:3306 --type=schema --mode=logical \ --policy=daily --schema=+world --pass-through="--ignore-table=world.CountryLanguage"
If you prefer a configuration file instead use this:
# # /etc/brman.conf # target = brman:secret@127.0.0.1:3306 type = schema mode = logical policy = daily schema = +world pass-through = --ignore-table=world.CountryLanguage
4. FromDual Recovery Manager (rman
)
4.1. Where can rman
help you
The Recovery Manager (rman
) is the counterpart to the Backup Manager (bman
). Recovery Manager assists you in restoring and recovering backups of your MariaDB and MySQL databases done with bman
or in some cases also with classical backup means like (mariadb-dump
, mysqldump
, mariadb-backup
, xtrabackup
and mysqlbackup
). Recovery Manager makes your restore easier and safer.
4.2. Progress Indicator
Since version 2.1.0 the FromDual Recovery Manager (rman
) has also a progress indicator for the restore of logical backups made with mysqldump
.
The Recovery Manager progress indicator logs to STDOUT:
shell> rman --target=brman:secret@127.0.0.1:3306 --type=full --mode=logical --policy=daily \ --instance-name=qamariadb102 --progress --backup-name=bck_qamariadb102_full_2019-08-20_21:15:23.sql Reading configuration from /etc/mysql/my.cnf No rman configuration file. Command line: /home/mysql/product/brman-2.2.1/bin/rman.php --target=brman:******@127.0.0.1:3306 --type=full --mode=logical --progress --backup-name=bck_qamariadb102_full_2019-08-20_21:15:23.sql --policy=daily --instance-name=qamariadb102 Options from command line target = brman:******@127.0.0.1:3306 type = full mode = logical progress = backup-name = bck_qamariadb102_full_2019-08-20_21:15:23.sql policy = daily instance-name = qamariadb102 Resulting options target = brman:******@127.0.0.1:3306 type = full mode = logical progress = backup-name = bck_qamariadb102_full_2019-08-20_21:15:23.sql policy = daily instance-name = qamariadb102 log = ./rman.log datadir = /var/lib/mysql owner = mysql backupdir = /home/mysql/bck binlog-policy = binlog Logging to ./rman.log Backupdir is /home/mysql/bck Version is 2.2.1 Start restore at 2019-08-20 21:18:46 mysql --user=brman --password=****** --host=127.0.0.1 --port=3306 From backup file: /home/mysql/bck/daily/bck_qamariadb102_full_2019-08-20_21:15:23.sql.gz Restore progress: . schema foodmart . schema fromdual_a . . table audit 1 statements, 3 rows, 171 bytes . . table c1 1 statements, 3 rows, 42 bytes . . table c2 1 statements, 3 rows, 42 bytes . . table child 1 statements, 3 rows, 177 bytes . . table parent 1 statements, 3 rows, 175 bytes . schema fromdual_b . . table audit 1 statements, 3 rows, 171 bytes . . table c1 1 statements, 3 rows, 42 bytes . . table c2 1 statements, 3 rows, 42 bytes . . table child 1 statements, 3 rows, 177 bytes . . table employees 0 statements, 0 rows, 0 bytes . . table parent 1 statements, 3 rows, 175 bytes . schema fromdual_c . . table audit 1 statements, 3 rows, 171 bytes . . table c1 1 statements, 3 rows, 42 bytes . . table c2 1 statements, 3 rows, 42 bytes . . table child 1 statements, 3 rows, 177 bytes . . table parent 1 statements, 3 rows, 175 bytes ... . schema test . . table test 347 statements, 4621 rows, 286528 bytes . schema world . . table City 1 statements, 4079 rows, 177139 bytes . . table Country 1 statements, 239 rows, 36481 bytes . . table CountryLanguage 1 statements, 984 rows, 26160 bytes . schema brman_catalog . schema foodmart . schema fromdual_a . schema fromdual_b . schema fromdual_c . schema mysql . schema test . schema test_catalog . schema world Schemas: 9, Tables: 55, Statements: 376, Rows: 12275, Bytes: 992736 WARNING: Progress numbers for Total Byte Counter may be different of dump file size. Restore time was: 0d 0h 1' 28" End restore at 2019-08-20 21:20:14 (rc=0)
The overhead of FromDual Recovery Manager progress indicator is not significant. We measured less than 1% longer recovery times with the progress indicator compared to pure mysql
restoration.
4.3. Recovery Manager (rman
) Examples
4.3.1. Example: Full logical restore
This is the way how to do a full logical restore from a backup done with bman
, mariadb-dump
or mysqldump
:
shell> rman --target=brman:secret@127.0.0.1:3306 \ --type=full --mode=logical \ --policy=daily --backupdir=/home/oli/bck --backup-name=full_dump.sql.gz
4.3.2. Example: Full physical restore
A full physical restore from a backup done with bman
, mariadb-backup
or xtrabackup
is done as follows:
shell> rman --target=brman:secret@127.0.0.1 \ --type=full --mode=physical --policy=daily \ --backup-name=bck_full_2026-06-11
4.3.3. Example: Logical restore of a specific schema from FromDual bman
backup:
shell> rman --target=brman:secret@127.0.0.1:3306 \ --type=schema --mode=logical --schema=world --policy=daily \ --progress --fast --no-binlog --cleanup-first \ --backup-name=full_dump.sql.gz
4.3.4. Example: Point-in-Time-Recovery (PiTR) after restore:
shell> rman --target=brman:secret@127.0.0.1:3306 \ --type=full --policy=daily --mode=logical \ --backupdir=/home/oli/bck --backup-name=full_dump.sql.gz \ --recover --before-datetime='2024-07-04 16:19:21' \ --binlog-policy=binlog
4.3.5. Example: Partial (database/schema) physical restore (xtrabackup
/mariadb-backup
) from FromDual bman backup:
shell> rman --target=brman:secret@127.0.0.1 \ --type=schema --mode=physical --policy=daily \ --schema=test --log=/tmp/rman.log \ --backup-name=bck_full_2024-07-11 --backupdir=/tmp/backup
4.3.6. Example: Monitoring integration (fpmmm
)
If you are using the FromDual Performance Monitor for MariaDB and MySQL (fpmmm
) and/or Zabbix for database monitoring you can send the backup information also to your monitoring solution for getting trends and see errors or anomalies:
shell> rman --target=brman:secret@127.0.0.1:3306 --type=full --mode=logical \ --policy=daily --instance-name=qamariadb102 \ --fpmmm-hostname=mariadb-106 --fpmmm-cache-file=/var/cache/fpmmm/fpmmm.FromDual.mariadb-106.cache
4.3.7. Example: Restore of a testing system from bman
backup
Restore on a testing system of a backup made by bman
:
shell> rman --config=/etc/rman_restore.conf \ --backup-name=$(ls -tr1 /var/restores/daily/bck_schema_world*.sql.gz | tail -n1 | cut -d/ -f5-)
5. Automated Restore testing
FromDual Backup and Recovery Manager is ideal for automated restore testing.
For more details see also: Automated MariaDB restore tests.
6. brman Integration into other FromDual Tools
FromDual Backup and Recovery Manager is integrated into other Tools of FromDual Enterprise Toolbox:
-
Backup size, return code and duration of a
rman
runs can be reported to FromDual Performance Monitor for MariaDB and MySQL (fpmmm
). This allows monitoring of backups and alerting if backups fail or are not executed at all. -
Restore return code and duration of a
rman
runs can be reported to FromDual Performance Monitor for MariaDB and MySQL (fpmmm). This allows monitoring of automated restore tests and alerting if restore fail or are not executed at all. -
Backup and Recovery Manager is shown from
myEnv
overview:
shell> V The following FromDual Toolbox Packages are installed: ------------------------------------------------------------------------ MyEnv: 2.0.3 (2decca847d904dce9363fe68869897ab5a39dadb) BRman: 2.3.0 OpsCenter: not available Fpmmm: 1.5.0 O/S: Linux / Ubuntu Binaries: mariadb-10.6
-
Backups are integrated into the Graphical User Interface FromDual Ops Center for MariaDB and MySQL (
focmmm
): Database backup.
7. Backup and Recovery Manager Release Notes
-
Backup and Recovery Manager for MariaDB and MySQL 2.3.1, Release Date: 12 August 2024
-
Backup and Recovery Manager for MariaDB and MySQL 2.3.0, Release Date: 25 June 2024
-
Backup and Recovery Manager for MariaDB and MySQL 2.2.5, Release Date: 23 February 2022
-
Backup and Recovery Manager for MariaDB and MySQL 2.2.4, Release Date: 26 July 2021
-
Backup and Recovery Manager for MariaDB and MySQL 2.2.3, Release Date: 13 January 2021
-
Backup and Recovery Manager for MariaDB and MySQL 2.2.2, Release Date: 8 October 2020
-
Backup and Recovery Manager for MariaDB and MySQL 2.2.1, Release Date: 5 August 2019
-
Backup and Recovery Manager for MariaDB and MySQL 2.2.0, Release Date: 25 July 2019
-
Backup and Recovery Manager for MariaDB and MySQL 2.1.0, Release Date: 22 February 2019
-
Backup and Recovery Manager for MariaDB and MySQL 2.0.0, Release Date: 27 June 2018
-
Backup and Recovery Manager for MySQL 1.2.5, Release Date: 1 May 2017
-
Backup and Recovery Manager for MySQL 1.2.4, Release Date: 12 January 2017
-
Backup and Recovery Manager for MySQL 1.2.3, Release Date: 1 October 2016
-
Backup and Recovery Manager for MySQL 1.2.2, Release Date: 29 May 2015
-
Backup and Recovery Manager for MySQL 1.2.1, Release Date: 18 January 2015
-
Backup and Recovery Manager for MySQL 1.2.0, Release Date: 24 September 2014
-
Backup and Recovery Manager for MySQL 1.1.1, Release Date: 4 September 2014
-
Backup and Recovery Manager for MySQL 1.1.0, Release Date: 11 August 2014
-
Backup and Recovery Manager for MySQL 1.0.4, Release Date: 15 April 2014
-
Backup and Recovery Manager for MySQL 1.0.3, Release Date: 3 April 2014
-
Backup and Recovery Manager for MySQL 1.0.2, Release Date: 10 December 2013
-
Backup and Recovery Manager for MySQL 1.0.1, Release Date: 4 November 2013
-
Backup and Recovery Manager for MySQL 1.0, Release Date: 30 September 2013
-
Backup and Recovery Manager for MySQL 0.4, Release Date: 30 March 2011
-
Backup and Recovery Manager for MySQL 0.3.6, Release Date: 23 January 2011
-
Backup and Recovery Manager for MySQL 0.3.5, Release Date: 22 January 2011
-
Backup and Recovery Manager for MySQL 0.3.4, Release Date: 21 November 2010
-
Backup and Recovery Manager for MySQL 0.3.3, Release Date: 21 November 2010
-
Backup and Recovery Manager for MySQL 0.3.2, Release Date: 14 November 2010
-
Backup and Recovery Manager for MySQL 0.3.1, Release Date: 14 November 2010
-
Backup and Recovery Manager for MySQL 0.3, Release Date: 13 November 2010
-
Backup and Recovery Manager for MySQL 0.2.7, Release Date: 12 August 2010
-
Backup and Recovery Manager for MySQL 0.2.6, Release Date: 12 August 2010
-
Backup and Recovery Manager for MySQL 0.2.5, Release Date: 12 August 2010
-
Backup and Recovery Manager for MySQL 0.2.4, Release Date: 12 August 2010
-
Backup and Recovery Manager for MySQL 0.2.3, Release Date: 19 January 2010
-
Backup and Recovery Manager for MySQL 0.2.2, Release Date: 7 January 2010
-
Backup and Recovery Manager for MySQL 0.2.1, Release Date: 31 December 2009
-
Backup and Recovery Manager for MySQL 0.2, Release Date: 24 December 2009
-
Backup and Recovery Manager for MySQL 0.1.1, Release Date: 18 July 2008
-
Backup and Recovery Manager for MySQL 0.1, Release Date: 18 July 2008
8. Backup and Recovery Manager License
9. Backup and Recovery Manager Frequently Asked Questions (FAQ)
Question: How can I find the version of the installed brman
?
Answer: You can find the version by the 2 following commands:
shell> bman --version shell> rman --version
Question: Is there a Graphical User Interface (GUI) for Backup and Recovery Manager?
Answer: Backup Recovery Manager is integrated into FromDual Ops Center for MariaDB and MySQL.
Question: How can I automate restore and restore tests with brman
?
Answer: To automatize backup and restore with Backup and Recovery Manager (brman
) we have have written the article: Automated MariaDB restore tests.
Question: How can I integrate brman
into my monitoring?
Answer: If you are using the FromDual Performance Monitor for MariaDB and MySQL (fpmmm
) and/or Zabbix for database monitoring you can send the backup and restore information also to your monitoring solution for getting trends and see errors or anomalies. For this you can use the options --fpmmm-hostname=
and --fpmmm-cache-file=
.
No other FAQ so far… Please ask!