Using Replication for Backups 3. Once the dump has completed, start replication again: In the preceding example, you may want to add login credentials (user name, password) to the commands, and bundle the process up into a script that you can run automatically each day. If you use this approach, make sure you monitor the replication process to ensure that the time taken to run the backup does not affect the replica’s ability to keep up with events from the source. See Section 17.1.7.1, “Checking Replication Status” . If the replica is unable to keep up, you may want to add another replica and distribute the backup process. For an example of how to configure this scenario, see Section 17.4.6, “Replicating Different Databases to Different Replicas” . To guarantee the integrity of the files that are copied, backing up the raw data files on your MySQL replica should take place while your replica server is shut down. If the MySQL server is still running, background tasks may still be updating the database files, particularly those involving storage engines with background processes such as  InnoDB . With  InnoDB , these problems should be resolved during crash recovery, but since the replica server can be shut down during the backup process without affecting the execution of the source it makes sense to take advantage of this capability. To shut down the server and back up the files: For example, assuming that the data directory is located under the current directory, you can archive the entire directory as follows: Under Windows: Normally you should back up the entire data directory for the replica MySQL server. If you want to be able to restore the data and operate as a replica (for example, in the event of failure of the replica), in addition to the data, you need to have the replica’s connection metadata repository and applier metadata repository, and the relay log files. These items are needed to resume replication after you restore the replica’s data. Assuming tables have been used for the replica’s connection metadata repository and applier metadata repository (see Section 17.2.4, “Relay Log and Replication Metadata Repositories” ), which is the default in MySQL 8.0, these tables are backed up along with the data directory. If files have been used for the repositories, which is deprecated, you must back these up separately. The relay log files must be backed up separately if they have been placed in a different location to the data directory. If you lose the relay logs but still have the  relay-log.info  file, you can check it to determine how far the replication SQL thread has executed in the source’s binary logs. Then you can use  CHANGE REPLICATION SOURCE TO  statement (from MySQL 8.0.23) or  CHANGE MASTER TO  statement (before MySQL 8.0.23) with the  SOURCE_LOG_FILE  |  MASTER_LOG_FILE  and  SOURCE_LOG_POS  | MASTER_LOG_POS  options to tell the replica to re-read the binary logs from that point. This requires that the binary logs still exist on the source server. 3630 C:\>  "C:\Program Files\MySQL\MySQL Server 8.0\bin\mysqld" shell>  mysqld_safe & shell>  tar cf /tmp/dbbackup.tar ./data shell>  mysqladmin shutdown 1. Shut down the replica MySQL server: 2. Copy the data files. You can use any suitable copying or archive utility, including  cp ,  tar  or  WinZip . 3. Start the MySQL server again. Under Unix: 17.4.1.2 Backing Up Raw Data from a Replica shell>  mysqladmin start-slave