如何从服务器上做备份？

对备份，只是愿望在进入正式话题之前，许可给一些小提醒。

● 在备份上不要迁延，做备份其实并不难。

● 干事不要寻求完善，而要寻求可恢复。

● 至少对于可接收的数据丧失、可接收的宕机时光、数据连续策略以及平安需求要形成文档。

● 对恢复进程要进行演习并形成文档，恢复比备份要主要得多!

● 对于备份功课胜利与否，要进行外部验证，不要依附于功课自身对你的提醒。

下面，让我们将繁文缛节的情势抛在一边，看看怎么用复制从办事器做备份。

起首，最显然的工作，是将从办事器自身作为备份。不幸的是，这并非一个真正的备份。在产生问题时，如丧失了办事器或其一部门、恶意进击造成的数据损坏、有时的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小时了)，丧失数据的机遇要低得多。在延迟时光达到时，办事器将运用从主办事器中获取的更新。

● 假如产生问题，这种延迟会给你一段缓冲时光。有时的DROPTABLE，在你的从办事器上会延迟一个小时才会产生，所以，在又对主办事器上的表进行恢复等相似操作时，可以跳过从办事器上DROP，并将从办事器切换为主办事器。这段额外的延迟时光，给了恢复操作相当的选择空间。