● 在备份上不要拖延，做备份其实并不难。
● 做事不要追求完美，而要追求可恢复。
● 至少对于可接受的数据损失、可接受的宕机时间、数据持续策略以及安全需求要形成文档。
● 对恢复过程要进行练习并形成文档，恢复比备份要重要得多!
● 对于备份作业成功与否，要进行外部验证，不要依赖于作业自身对你的提示。
下面，让我们将繁文缛节的形式抛在一边，看看怎么用复制从服务器做备份。
首先，最显然的事情，是将从服务器自身作为备份。不幸的是，这并非一个真正的备份。在发生问题时，如丢失了服务器或其一部分、恶意攻击造成的数据破坏、偶然的DROPTABLE，真正的备份能够挽回损失，而复制从服务器对于上述后两个问题所造成的数据损失，却是无能为力的，因为它只是好心地将数据变化复制了过来，从而将数据的破坏或损失也一并复制了过来。
所以，怎么做真正的备份呢?假如只有一台复制从服务器，而且这台服务器也有多余的空间做cron作业等，则在不用数据库服务器的时候，将其停掉，然后备份其数据。对于MYSQL:在 MYSQL进程运行的时候，不要复制IINNODB的文件，这样是无法复制的。如果能够停掉MYSQL，然后将其数据移走，则对于大多数情况，都是最安全的。
如果不想停止服务器，还有一个选择，就是Ktrabackup，一个免费和开源的非阻塞备份程序，用于备份INNODB和KTRADBE的表。假如有 MYISAM表，则在复制时会进行锁定。Xtrabackup基于与INNODBI的热备工具同样的原理，但 XTRADB开源，且具有一些额外的特点。
我过去建议人们使用文件系统快照，特别是LVM快照。这些快照也可以创建备份，而又不会打断数据库的操作。但经过一些基准测试，我和我的同事都不再推荐这种方法了。LVM的问题是影响性能，而且比我们过去认为的影响要大得多。其他有快照能力的文件系统，如ZFS，相对比较新，我也不是这方面的专家，所以也就没什么可说的。我的有些客户使用 Solaris和ZFS，尽管很难分离各个变量，或者直接比较性能，但我并不认为性能有明显的好转。ZFS写时复制(copy-on-write)的行为，使得关于数据如何物理组织的考虑变得很复杂了，关于这方面，我还没有足够的时间来熟悉，所以也就无法做出合理的推荐。所以，在我看来，将ZFS用做数据库的文件系统，还仍然没有取得一致意见。所以，在开源领域，我还没有见到基于快照的备份的杀手级解决方案。
关于MYSQLI的，而MYSQL没有这种能力，所以，MYSQL的备份就有点复杂了。很多数据库都有内置的热备能力，如果你的数据库有，就使用它。前面的讨论大部分都是对于MYSQL，可能其他数据库也一样，可以用复制从服务器来做这样的事:将复制延迟一段时间，如一个小时。这可以使用Maatkitt的mk-slave-delay工具来实现。将延迟的服务器用
做“备份”，有下面两个有趣的点:
● 不断地从主服务器中获取更新，但并不应用这些更新，这意味着，比起昨天晚上做的备份(在发生崩溃的时候，备份的数据可能已经过去24小时了)，丢失数据的机会要低得多。在延迟时间到达时，服务器将应用从主服务器中获取的更新。
● 假如发生问题，这种延迟会给你一段缓冲时间。偶然的DROP TABLE，在你的从服务器上会延迟一个小时才会发生，所以，在又对主服务器上的表进行恢复等类似操作时，可以跳过从服务器上DROP，并将从服务器切换为主服务器。这段额外的延迟时间，给了恢复操作相当的选择空间。
将延迟从网站建设服务器用做备份的补充，而不是替代。你仍然需要做实际的备份!
本文地址：//www.qlpinke.com//article/3321.html
