怎样从服务器上做备份？

对备份，只是但愿在进入正式话题以前，容许给一些小提示。

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

● 干事不要谋求完满，而要谋求可恢复。
● 至少对付可承受的数据损失、可承受的宕机时间、数据连续战略以及安全需求要形成文档。
● 对恢复过程要进行操练并形成文档，恢复比备份要首要得多!
● 对付备份功课胜利与否，要进行外部验证，不要依赖于功课自身对你的提示。

下面，让咱们将繁文缛节的模式抛在一边，看看怎么用复制从服务器做备份。
起首，最显然的工作，是将从服务器自身作为备份。可怜的是，这并不是一个真实的备份。在产生问题时，如丧失了服务器或其一部分、歹意进犯形成的数据粉碎、偶尔的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，并将从服务器切换为主服务器。这段分外的延迟时间，给了恢复操纵至关的选择空间。

将延迟从网站制作服务器用做备份的弥补，而不是代替。你依然需求做理论的备份!