如何实现Mysql数据库每天自动备份定时备份？

利用UCache灾备云平台，可作为一个工具，在window服务器现有架构不变的情况下，针对Mysql数据库每天自动备份定时备份。

（1）新建备份任务

UCACHE灾备云控制台登录账号后：点击服务器定时数据保护--数据备份点击新建按钮，然后选要保护的对象（您的生产服务器节点），选中对应的客户端，选择文件系统然后点击 下一步

（2）设置备份策略

选择要进行备份的文件

（3）永久增量备份与数据保留设置

选择完要过滤的数据之后点击下一步，可进行下一步备份的高级功能选择，各个选项说明如下：

永久增量备份开启了永久增量备份每一次增量备份都会进行一次时间点合成形成新的一个永久增量时间点等效于完备时间点。

数据保留策略开启数据保留策略一共有三种保留策略分别为数据保留期限、保留副本数、按备份策略的备份周期设置副本保留策略默认选中数据保留期限一年。可以设置保留完全副本的个数最大可设置1024个副本按备份策略的备份周期设置副本保留策略最大可设置99999个副本。

传输和存储加密开启传输加密与存储加密选项开启此功能的任务的数据在传输和存储上都经过加密处理。一共有两种加密方式AES256加密算法、SM4加密算法。

数据压缩默认不开启开启该选项后默认启用快速压缩可选择启用强力压缩

重复数据删除勾选该选项可以启动源端重复数据删除的功能该选项在建立任务后不能通过修改任务的方式更改此属性。指纹库需要提前创建才能成功开启重删功能

最后新建完成

目录和文件内容，可以全选和分选，还可以利用UCACHE灾备云控制台的“文件过滤”“目录过滤”“时间过滤”功能进行不必要的数据不进行备份策略添加。为了备份效率不建议两个任务包含同一文件。

（4）设置邮件告警

备份执行完毕，会得到系统的执行反馈，也可以设定告警监控策略，进行邮件监控

从备份策略来讲，现在的备份可分为三种：完全备份，差异备份，增量备份，累积备份，现在来讲讲这几种备份之间的区别： 完全备份：指的是拷贝给定计算机或文件系统的所有文件，而不管它是否改变。 差异备份：只备份在上一次完全备份后有变化的部分数据。 增量备份：备份上一次备份后增加、改动的部分数据，增量备份可以分为：累积增量备份和非累积增量备份。 累加备份：采用数据库的管理方式，记录累积每个时间点的变化，并把变化后的值备份到相应的数组中，这种备份方式可恢复到指点的时间点。 一般在使用过程中，这三种策略常结合使用，常用的方法有：完全备份、完全备份加增量备份、完全备份加差异备份、完全备份加累加备份。 完全备份会产生大量数据移动，选择每天完全备份的客户经常直接把磁带介质连接到每台计算机上（避免通过网络传输数据）。这样，由于人的干预（放置磁带或填充自动装载设备），磁带驱动器很少成为自动系统的一部分。其结果是较差的经济效益和较高的人力花费。 完全备份加增量备份源自完全备份，不过减少了数据移动，其思想是较少使用完全备份。比如说在周六晚上进行完全备份（此时对网络和系统的使用最小）。在其它6 天（周日到周五）则进行增量备份。增量备份会问这样的问题：自昨天以来，哪些文件发生了变化？这些发生变化的文件将存储在当天的增量备份磁带上。 使用周日到周五的增量备份能保证只移动那些在最近24 小时内改变了的文件，而不是所有文件。由于只有较少的数据移动和存储，增量备份减少了对磁带介质的需求。对客户来讲则可以在一个自动系统中应用更加集中的磁带库，以便允许多个客户机共享昂贵的资源。然而，当恢复数据时，困难产生了。 在完全+增量方法下，完整的恢复过程首先需要恢复上周六晚的完全备份。然后再覆盖自完全备份以来每天的增量备份。该过程最坏的情况是要设置7 个磁带集（每天一个）。如果文件每天都改的话，需要恢复7 次才能得到最新状态。 由于完全+增量方法中恢复很困难，后来有了完全+差异方法。差异成为备份过程考虑的问题。增量备份考虑：自昨天以来哪些文件改变了？而差异方法考虑：自完全备份以来哪些文件发生了变化？对于完全备份后立即的备份过程（本例中周六），因为完全备份就在昨天，所以这两个问题的答案是相同的。但到了周一，答案不一样了。增量方法会问：昨天以来哪些文件改变了？并备份24 小时内改变了的文件。差异方法问：完全备份以来哪些文件改变了？然后备份48 小时内改变了的文件。到了周二，差异备份方法备份72 小时内改变了的文件。 在Tivoli 存储管理器之前，客户被迫在完全备份、完全+增量备份和完全+差异备份间权衡。许多客户在管理时都会混合和匹配这三种方法，试图得到期望的可重获性水平。 Tivoli 存储管理器引入了一个新范例叫累加备份方法。累加方法提出增量问题：自昨天以来哪些文件改变了？并把结果放到存储管理器数据库中。这样当首次用累加方法备份文件系统或计算机时，由于Tivoli 存储管理器以前未曾备份，所有的文件都将移动。当备份拷贝发送到Tivoli 存储管理器服务器时，每个文件单独存放在数据库中。文件名信息、所有者和安全信息、创建和修改时间，以及拷贝自身都放置在Tivoli 存储管理器服务器连续存储分层结构中（参见图8）。如果客户策略要求拷贝到磁带上，Tivoli 存储管理器数据库将记录磁带的条形码、起始块地址和文件长度。 在初始的备份后，将只考虑增量问题（不再进行完全拷贝）。每天将只移动上次备份 *** 作后改变了的文件。并且，文件发送到Tivoli 存储管理器服务器后被单独存放在数据库中。当需要拷贝到磁带时，Tivoli 存储管理器服务器查询数据库，确定从前的拷贝在哪一个磁带上。一旦确定，将对该磁带进行再设置并把新拷贝附加在磁带末尾。这种对备份拷贝的收集都来自于同一台计算机或文件系统，于是形成了所谓的排列组。每天，改变的文件累加到排列组中（见图）。 现在让我们来看恢复 *** 作。恢复 *** 作的目标是让文件系统或计算机回到期望的某一时间点。常见的情况是客户期望的时间点就是最近某时刻。在累加备份方法下，完成一个完全的恢复 *** 作只需告诉Tivoli 存储管理器服务器期望的时间点。利用时间点信息，Tivoli 存储管理器服务器查询数据库中文件集合，看它们是否在期望的时间点上。这些文件存在于同一个排列组上，通常也位于一个（或少数几个）磁带上。设置了正确的磁带后，数据库指定每个文件的长度和起始块位置。大多数现代的磁带驱动器都具有快速扫描功能，能迅速定位到期望的备份拷贝并执行恢复 *** 作，这样只移动了期望的文件。您可以把该过程看作完全系统 *** 作中一个完整的恢复过程。该过程就象在期望的时间点做了完全备份一样。 累加备份采用增量，提供了备份效率；采用排列组，提高了介质管理效率；准确地只移动期望的文件，提高了恢复效率。该方法最大的功效还在于：累加方法并不需要在一个完全备份后才能开始恢复过程，也就是说并不需要周期性地建立完全备份拷贝。而对完全+增量或完全+差异方法，无论是否改变，每周都要移动和存储大量数据。有了累加备份方法，就不需要这样做了。于是客户节省了大量的网络带宽（LAN、WAN或SAN）、磁带介质和时间。 不同的软件有不同的备份特点，客户可根据自己的数据特点，选择适合自己的软件或备份策略。 在rman 增量备份中，有差异增量和累积增量的概念 1、概念 差异增量：是备份上级及同级备份以来所有变化的数据块，差异增量是默认增量备份方式 累积增量：是备份上级备份以来所有变化的块…… Oracle 增量备份与恢复 在rman 增量备份中，有差异增量和累积增量的概念 1、概念 差异增量：是备份上级及同级备份以来所有变化的数据块，差异增量是默认增量备份方式 累积增量：是备份上级备份以来所有变化的块 因为累积增量是备份上级备份以来所有变化的数据块，所以累积增量需要更多的备份时间，同时需要较小的恢复时间；而差异增量正好相反，它可以备份同级备份以来变化的数据块。所以会减少备份时间，但需要更多的恢复时间在oracle 9 中增量备份需要通过扫描整个数据库的数据块才能知道哪些数据块发生了变化，这是一个代价很大，时间很长的过程，而且由于增量备份形成多个不同的备份集，使恢复变得更加不可靠，所以增量备份在版本9 中仍然不被推荐使用;在10g 中，增量备份作了很大的改进，不需要再扫描所有数据块就能得知哪些数据块发生变化，从而大大提升备份效率。但这些却以牺牲磁盘i/o 为代价，所以在oltp 事务系统中还得衡量是否愿意以i/o 为代价来保证安全及高可用性。10g 还支持增量合并，增量备份可支持7 级增量。 2、备份策略及恢复 以rman 多级增量备份来作为备份策略例子: 增量备份都需要一个0 级备份来作为基础，0 级备份与全备份的区别在于0 级可以用来增量恢复，而全备份则不可以。 备份策略： eg:我们对一星期做如下备份策略 ，那么差异增量只需要使用星期天的0 级，星期三的一级，星期四、五的二级就可以恢复，累积增量则需要星期天的0 级，星期五的二级即可进行恢复。以上是一个星期的备份策略,如果做长期的备份策略则只需要把备份的时间延长即可得到新的备份策略，具体需要看自己备份及恢复能够接受的程度而顶，见最后的备份策略典型案例。 星期天 0 级 0 级 星期一 2 级 2 级 星期二 2 级 2 级 星期三 1 级 1 级 星期四 2 级 2 级 星期五 2 级 2 级 星期六 2 级 2 级 星期天 0 级 0 级 备份命令如下： 零级备份 backup incremental level 0 database; 一级差异增量 backup incremental level 1 database; 一级累计增量 backup incremental level 1 cumulative database; 备份策略典型案例： 每半年做一个数据库的全备份（包括所有的数据和只读表空间） 每一个月做一次零级备份（不包含只读表空间） 每个星期做一次一级备份 每天做一次二级备份 任何数据库的更改需要重新同步CATALOG目录并重新备份（如添加数据文件）或重新备份（如修改表空间为只读） 建议备份一段时间归档日志和定期备份归档到到磁带上 全库备份脚本 run{ allocate channel c1 type disk; allocate channel c2 type disk; allocate channel c3 type disk; backup full tag ‘dbfull’ format ‘/u01/oradata/backup/full%u_%s_%p’ database include current controlfile; sql ‘alter system archive log current’; backup fileaperset 3 format ‘/u01/oradata/backup/arch%u_%s_%p’ archivelog all delete input; #备份归档可选，可以单独定期备份 release channel c1; release channel c2; release channel c3; } 零级备份脚本 run{ allocate channel c1 type disk; allocate channel c2 type disk; allocate channel c3 type disk; backup incremental level 0 tag ‘db0’ format ‘/u01/oradata/backup/db0%u_%s_%p’ database skip readonly; sql ‘alter system archive log current’; backup fileaperset 3 format ‘/u01/oradata/backup/arch%u_%s_%p’ archivelog all delete input; #备份归档可选，可以单独定期备份 release channel c1; release channel c2; release channel c3; } 一级备份脚本 run{ allocate channel c1 type disk; allocate channel c2 type disk; allocate channel c3 type disk; backup incremental level 1 tag ‘db1’ format ‘/u01/oradata/backup/db1%u_%s_%p’ database skip readonly; sql ‘alter system archive log current’; backup fileaperset 3 format ‘/u01/oradata/backup/arch%u_%s_%p’ archivelog all delete input; #备份归档可选，可以单独定期备份 release channel c1; release channel c2; release channel c3; } 如果按照以上备份策略，则每天的所需要备份的数据量只有一天的改变量。而做恢复时最多要恢复当月的一个零级备份+三个一级备份+6 个二级备份+当天的归档文件。

实现方法如下：
1、用FTP并结合任务调度进行自动的同步。需要自动保持公司电脑和家里电脑FileBasenyf这个文件的同步。实现原理：
1）估计一下每天的关机时间，利用Windows的任务调度在这个时间的前几分钟将文件上传至ftp服务器。
2）同样利用Windows的任务调度，在机器启动时，自动备份本地FileBasenyf文件，并从ftp服务器下载文件。
2、实现方式(以本地存放路径D:\ApplicationData\mybase、本地任务调度文件:D:\ApplicationData\schedule、文件存放在远程服务器的temp目录下。

1：官方百万级别的测试数据库：

官方测试数据库github网址：>

使用多备份客户端可以对服务器硬盘进行自动备份

首先进入多备份控制面板。首次进入有保护设备选项，选择保护服务器，非首次进入直接点击左下角下载客户端

下载客户端以后打开dbfenexe，然后登陆账户并选择首次备份。

选择以后点击文件左侧的按钮，然后勾选要保护的数据所在的目录，最后创建任务即可对服务器的硬盘进行备份

Ø  首先，我们需要开启MySQL服务器的二进制日志功能，其实现方法有很多种，最常用的是在MySQL的配置文件的mysqld项中加入log-bin=[filepath]项；也可以使用mysqld –log-bin=[filepath]重新启动MySQL服务器。

Ø  其次，使用mysqldump对数据库进行完全备份，它可以实现对数据据的联机，非阻塞的热备份，不会影响其他进程对数据库的读写 *** 作。（参考指令：mysqldump -uroot --password=123 --single-transaction --flush-logs --master-data=2 --all-databases --delete-master-logs > d:/mysql50/full_%date:~0,10%_1500_PMsql）

Ø  第三，使用flush logs指令刷新创建新的二进制日志。可以通过mysqladmin flush logs或者flush logs语句实现。最方便有效的方法是将它做成批处理文件，然后让 *** 作系统定期执行。

Ø  使用mysql < sql进行完全备份的恢复。

Ø  使用mysqlbinlog logs-bin[0-9] | mysql进行增量备份的恢复。一般的，假设我们周日下午三点进行了完全备份并生成备份文件full_backup_20100415_3_PMsql，周一周二中午一点进行了两次增量备份，分别生成增量备份文件inc_backup_1_PM0007和inc_backup_1_PM0008，周三上午10：00数据库发生崩溃，需要进行数据库恢复，此时正在记录的二进制日志为inc_backup_1_PM0009，我们还需要恢复其中记录的 *** 作。具体的恢复 *** 作为：

mysql < full_backup_20100415_3_PMsql

mysqlbinlog inc_backup_1_PM0007 inc_backup_1_PM0008 inc_backup_1_PM0009

u  具体应用(结合T8项目)

根据上述分析，我们在T8项目使用MySQL增量备份，也需要三个步骤：

Ø  首选修改MySQL启动配置文件mycnf，在其中的mysqld项中增加log-bin选项，重新启动MySQL 服务器以开启二进制日志功能，在生成文件/usr/data/mysql/ t8server-binindex和t8server-bin000001。如图所示：

Ø  编写完全备份可执行文件脚本：

Ø  编写增量备份可执行文件脚本：

Ø  执行full_backup_20100417_1_pm，生成/usr/data/mysql/full_backup_20100417_1_pm sql文件。

Ø  执行inc_backup_1_pm，生成/usr/data/mysql/t8server-bin000002。

其中full_backup_20100417_1_pm sql和t8server-bin000002分别是完全备份和增量备份文件。

要进行备份文件的恢复，只需执行命令：

u  总结

MySQL提供了很方便的完全+增量备份实现方法，我们只需调用系统内置的方法或者作出一些细微的配置就可以对MySQL数据库进行备份和恢复。对于MyISAM数据库和InnoDB数据库，都可以通过mysqldump实现数据库的完全逻辑备份，通过启动二进制日志（binary logs），可以记录一个时间段内对数据库的所有可能更新的 *** 作，从而通过flush logs创建新的日志而实现增量备份。

利用下面的列出的技巧来确保你不会在每周一次的数据库备份过程中忘记关键步骤。每周一次备份主数据库。如果你创建、修改或者停止一个数据库，添加新的SQL Server消息，添加或者停止连接服务器，或者添加记录设备，那就进行手工备份。每天备份一次msdb数据库。它一般非常小，但很重要，因为它包含了所有的SQL Server工作、 *** 作和计划任务。只有当你修改它时，才有必要备份模型数据库。用SQL Server Agent来安排你的备份工作的时间表。如果在你的生产(production)环境中有现成资源，备份生产数据库到本地磁盘或者网络服务器(用同一个开关)。然后，把备份文件/设备拷贝到磁带上。在存在许多硬件故障(特别是在RAID系统中)的情况下，磁盘常常是完好的(inact)。如果备份文件是在磁盘上，那么恢复时的速度会提高很多。备份开发和测试数据库至少要用到SIMPLE恢复模型。除了有计划的定时备份外，在进行未记录的(nonlogged)批 *** 作(如，批拷贝)、创建索引、或者改变恢复模型后要备份用户数据库。如果你使用的是SIMPLE恢复模型，记住在截短(truncate)交易记录之后备份你的数据库。用文档记录你的恢复步骤。至少要大概记录这些步骤，注意所有的重要文件的位置。--------------------------------------------------------------------------------在截短记录之前，也就是所有的已提交(committed)交易从记录中清空之前，所有的这些信息都保存在交易记录中。在SIMPLE恢复模型中，记录在一个CHECKPOINT期间内截短(在SQL Server内存缓冲写道磁盘时)，它是自动发生的，但也可以手动执行。这也就是SIMPLE恢复模型不支持时间点(point-in-time)恢复的原因。在FULL和BULK_LOGGED恢复模型下，当交易记录被备份时，交易记录被截短，除非你明确指出不进行截短。为了备份交易记录，使用BACKUP LOG命令。其基本语法与BACKUP命令非常相似:BACKUP LOG { database } TO <backup device>下面是如何把交易记录备份到一个名为LogBackupDevice的逻辑设备上的例子:BACKUP TRANSACTION Northwind TO LogBackupDevice如果你不希望截短交易记录，使用NO_TRUNCATE选项，如下所示:BACKUP TRANSACTION Northwind TO LogBackupDevice WITH NO_TRUNCATE只是基本知识尽管我在本文中仅仅概述了数据库恢复的基本知识，你还是可以通过这些技巧来找到正确的方向。那么，为了避免不必要的(丢失数据造成的)恐慌，你要做到每周备份主数据库，每天备份msdb。 dsafg

帮助里面有说明，Windows Server Backup 可创建完整备份，使用该备份无需引用其他备份即可执行计算机恢复。但是，会对这些备份进行优化以类似于增量备份，从而提高备份性能和节省空间。此外，如果使用磁盘或卷存储备份，当存储位置占满后，Windows Server Backup 还会自动删除较早的备份。有关增量备份和完整备份的详细信息，请参阅优化备份和服务器性能。

---