NetVault Plug-in for MySQL 13.2

NetVault Plug-in for MySQL 13.2 - User Guide

Reviewing the backup types for MySQL Enterprise Backup

For the MySQL Enterprise Backup option, the plug-in runs the mysqlbackup command once for all selected database objects to achieve the following types of backup: Full, Incremental, and TTS.

Full Backups

In a Full Backup for the MySQL Enterprise Backup option, the plug-in uses the mysqlbackup utility or applicable NetVault Backup script to back up every selected database object included in the instance. Full Backups are the foundation of any backup strategy because they provide the starting point for almost every restore scenario. Full Backups generated with the plug-in can be used to restore an entire instance, individual or multiple databases, and individual or multiple tables.

Incremental Backups

For an InnoDB table, only data that changed since the last Full or Incremental Backup is backed up. For a non-InnoDB table, the entire table is backed up if anything has changed in the table since the last Full or Incremental Backup.

Transportable Tablespace (TTS) Backups

If you perform a TTS Backup, the plug-in issues a Full Backup and adds the “--use-tts” MySQL option.


	IMPORTANT: Quest strongly recommends that you only generate TTS Backups as standalone backups, separate from your backup plan. Because TTS Backups are partial backups, you cannot use them to replace or complement a Full or Incremental Backup strategy, nor can you use them for a disaster recovery operation.

If you intend to generate TTS Backups, be aware of the following limitations:

•

TTS Backups are only supported in MySQL Server 5.6 and later.

•

Only InnoDB tables are included in the backup.

•

Only tables that were created with the innodb_file_per_table option enabled are included in the backup.

•

Backup of a partitioned table fails if the partition was created in a shared tablespace.

•

The backup excludes the binary or relay log.

For more limitations on the use of the “--use-tts” option, see https://dev.mysql.com/doc/mysql-enterprise-backup/4.0/en/backup-partial-options.html.

Reviewing the backup types for Mariadb-backup

For the Mariadb-backup method, the plug-in runs the Mariadb-backup command once for all selected database objects to achieve the following types of backup: Full, and Incremental..

Full Backups

In a Full Backup for the Mariadb-backup option, the plug-in uses the Mariadb-backup utility or applicable NetVault script to back up every selected database object included in the instance. Full Backups are the foundation of any backup strategy because they provide the starting point for almost every restore scenario. Full Backups generated with the plug-in can be used to restore an entire MariaDB instance.

Incremental Backups

For Mariadb-backup Incremental backups, only data that changed since the last Full Backup is backed up.

Examples of backup sequences for MySQL Standard/Community

The following provides examples of the various sequences.

•

Full Backups only: When requirements guarantee data protection up to the previous day and daily read-only access is permissible, for example, after regular business hours, performing only Full Backups daily should be sufficient. While DBAs are only guaranteed to be able to recover the database up to the point of the last Full Backup, they can perform a PIT Recovery using the Binary Logs that currently exist on the MySQL Server.

•

Full and Incremental Backups: When requirements guarantee data protection up to the previous day, but read-only access to the target MySQL Instance is only permissible at intermittent times — for example, after regular business, on only a weekly or biweekly basis — and backup time should be as fast as possible, Full Backups coupled with Incremental Backups is the best combination. For example, Full Backups are performed every Sunday night at 11:00 P.M., while Incremental Backups are performed Monday through Saturday at 11:00 P.M. Each Incremental Backup includes the Binary Logs that were generated since the previous night’s backup, whether it be the Sunday evening Full Backup or one of the Incremental Backups.

Restoring this type of backup sequence is more time-consuming. For example, if recovery is performed on Tuesday, only Sunday’s Full Backup and Monday’s Incremental Backup must be restored; whereas, if recovery is performed on Thursday, Sunday’s Full Backup followed by Monday’s, Tuesday’s, and Wednesday’s Incremental Backups must be restored. Even though the backups are quicker, the restores can take longer due to the additional intervention that is required to run multiple restore jobs.

•

Full and Differential Backups: When requirements guarantee data protection up to the previous day, but read-only access to the target MySQL Instance is only permissible at intermittent times — for example, after regular business hours, on only a weekly or biweekly basis — and restore time should be as fast as possible, Full Backups coupled with Differential Backups is the best combination. For example, Full Backups are performed every Sunday night at 11:00 P.M., while Differential Backups are performed Monday through Saturday at 11:00 P.M. Each Differential Backup includes the Binary Logs that were generated since the last Full Backup. As noted earlier, this process requires more overall backup time.

Regardless of the time to which recovery is necessary, the same number of restore jobs is required. For example, if recovery is performed on Tuesday, Sunday’s Full Backup and Monday’s Differential Backup must be restored; whereas, if recovery is performed on Thursday, Sunday’s Full Backup followed Wednesday’s Differential Backup must be restored. Even though subsequent Differential Backups increase not only in size but in duration, restores are quicker due to the fewer restore jobs that must be run.