SQL数据库自动备份(mysql数据库自动备份)

首先利用数据库自带的命令行工具将数据库备份下来，例如对MySQL将数据库备份到D:datasql（具体查阅数据库说明书）

mysqlmp

然后将该文件以日期参量重名名。如果指定保留N天的数据可能有一定困难，不过既然要求7天，不妨以星期作为区分。

假设文件名具有格式“data_日期sql”，则更名语句为（建议先创建后改名，对于很大的数据库可能要备份很长时间并超过0点）

ren"datasql""data_%date%sql"

若系统时间格式为“2009-04-05星期日”，则产生文件“data_2009-04-05星期日txt”。

获取星期几的语句：%date:~11,3%

其中11表示从第11个字符开始（从0开始计算），总共截取3个字符。由此可获得字符串“星期日”。重名名前，删除以data_开头，包含“星期日”的文件

del"data_%date:~11,3%sql"

这样就把上星期的那个文件删除了。

注意：如果系统日期格式与上面的不一致，数字需重新计算，特别是若日期中含有“/”、“:”等字符会导致创建文件失败，此时年月日星期均需手动提取，例如对“04/05/2009Sun”，应使用“%DATE:~6,4%%DATE:~0,2%%DATE:~3,2%%DATE:~11,3%”得到“20090405Sun”。查看日期格式可使用“echo%date%”。

另外，如果某项（时间格式、文件名、路径等）包含空格则必须使用引号。

脚本源代码

mysqlmp

del"D:data_%date:~11,3%sql"

ren"D:datasql""data_%date%sql"

编为一个bat文件，添加计划任务，每天定时执行即可。

以mysql为列：

规划容灾备份时，有两个参考依据，1：恢复点目标（PRO），2：恢复时间目标（RTO）。他们定义了可以容忍丢失多少数据，以及恢复数据需要多少时间。而且一定要走出一个误区，复制就是备份，只有备份才能满足备份的要求。

个人认为备份方案类型如下：

1：在线备份或者离线备份，通常关闭mysql做离线备份是最简单最安全的，服务器不提供应用访问服务，可以更快完成备份，但是，这样会导致服务中断，同时，重启mysql也需要一定的时间成本，对于已经上线的系统，基本不可取。在线备份的最大一个问题是，mysql可能锁住大量的表，除非锁被释放，否则会有大量的io请求被阻塞。

综上所述，我们在规划备份的时候需要考虑一下几点：

a：锁时间。

b：备份时间。

c：备份负载对服务器的影响有多大。

d：恢复备份时间需要多久。

2：逻辑备份还是物理备份。

（1）：逻辑备份有以下优点：

a：逻辑备份文件恢复非常简单。只需要使用mysqlimport即可。

b：在我们只想查看数据，不想恢复的时候可以使用grep或者sed命令查看。

c：逻辑备份与存储引擎没有关系，我们可以跨存储引擎恢复数据，比如：从InnoDB表中备份，用很小的工作量就可以把数据恢复到MyISAM中。

逻辑备份也会有以下缺点：

a：必须有数据库服务器完成备份工作，增加服务器工作负荷。

b：逻辑备份文件某些场景比数据库本身文件还大。

c：无法保证导入导出的数据是一样的，比如浮点型数据。

d：恢复的时候需要重建索引，速度会慢。

（2）：物理备份有以下优点：

a：基于文件的物理备份，只需要复制 *** 作到目标目录即可。

b：恢复的时候只需要将文件copy到要恢复的目录即可。InnoDB可能需要停止服务和其他一些 *** 作。

c：物理备份中恢复速度块，而且容易垮平台和 *** 作系统和mysql数据库版本。

物理备份也会有以下缺点：

a：文件名大小写敏感，浮点格式数据可能会遇到麻烦。

b：物理备份通常包含很多未使用的空间。

3：增量备份和差异备份。增量备份和差异备份只是局部备份，主要是思想就是不备份没有改变的表，但是会减少服务器的开销，备份时间等。

4：二进制日志备份。通常数据小，我们可以频繁的备份，同时，基于时间点的恢复，二进制日志备份是一个很有效的手段。

5：文件系统快照，通过创建镜像达到恢复的目的。

对于一个好的开发人员来说，有好的备份容灾规划和计划是必不可少的。这样可以提高我们在线系统的持续运行能力。更好的服务我们系统的用户。我个人最喜欢的备份方式就是从文件系统快照中直接复制数据文件。

以上是个人的见解，希望对你有一定的帮助。谢谢。

MySQL备份数据库的两个主要实际 *** 作方案是采用MySQL(与PHP搭配之最佳组合) dump程序或是直接复制相关的数据库文件（如用cp、cpio或tar等）。当然每种实际应用方法都有其优缺点：

MySQL(和PHP搭配之最佳组合)dump与MySQL(和PHP搭配之最佳组合)服务器协同 *** 作。

直接拷贝方法在服务器外部进行，并且你必须采取措施保证没有客户正在修改你将拷贝的表。如果你想用文件系统备份来备份数据库，也会发生同样的问题：

如果数据库表在文件系统备份过程中被修改，进入备份的表文件主语不一致的状态，而对以后的恢复表将失去意义。文件系统备份与直接拷贝文件的区别是对后者你

完全控制了备份过程，这样你能采取措施确保服务器让表不受干扰。

MySQL(和PHP搭配之最佳组合)dump比直接拷贝要慢些。

MySQL(和PHP搭配之最佳组合)dump生成能够移植到其它机器的文本文件，甚至那些有不同硬件结构的机器上。直接拷贝文件不能移植到其它机器上，

除非你正在拷贝的表使用MyISAM存储格式。ISAM表只能在相似的硬件结构的机器上拷贝。在MySQL(和PHP搭配之最佳组合)

323中引入的MyISAM表存储格式解决了该问题，因为该格式是机器无关的，所以直接拷贝文件可以移植到具有不同硬件结构的机器上。只要满足两个条

件：另一台机器必须也运行MySQL(和PHP搭配之最佳组合) 323或以后版本，而且文件必须以MyISAM格式表示，而不是ISAM格式。

不管你使用哪种备份方法，如果你需要恢复数据库，有几个原则应该遵守，以确保最好的结果：

定期实施备份。建立一个计划并严格遵守。

让服务器执行更新日志。当你在崩溃后需要恢复数据时，更新日志将帮助你。在你用备份文件恢复数据到备份时的状态后，你可以通过运行更新日志中的查询再次运用备份后面的修改，这将数据库中的表恢复到崩溃发生时的状态。

以文件系统备份的术语讲，数据库备份文件代表完全倾倒（full dump），而更新日志代表渐进倾倒（incremental dump）。

使用一种统一的和易理解的备份文件命名机制。象backup1、buckup2等不是特别有意义。当实施你的恢复时，你将浪费时间找出文件里是什么东西。你可能发觉用数据库名和日期构成备份文件名会很有用。例如：

%MySQL(和PHP搭配之最佳组合)dump samp_db >/usr/archives/MySQL(和PHP搭配之最佳组合)/samp_db1999-10-02

%MySQL(和PHP搭配之最佳组合)dump menagerie >/usr/archives/MySQL(和PHP搭配之最佳组合)/menagerie1999-10-02

市面上有很多数据库备份产品，有软件（例如 备特佳）也有UPM灾备一体机，关键在于根据自身的需求进行选择。首先要确定备份策略，定时备份还是实时备份；其次要确定备份方案，本地备份还是异地容灾，是备份数据还是也要考虑业务的连续性。最后考察下所选产品的客户案例和实际应用情况就差不多了，当然，也要考虑资金。

以上就是关于SQL数据库自动备份(mysql数据库自动备份)全部的内容，包括:SQL数据库自动备份(mysql数据库自动备份)、有哪些mysql数据库容灾备份方案推荐、备份mysql是用的什么方法等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！