☰

您对于这个 Debian 备份策略有什么看法？

tag-icon • tag-icon debian svn rsync mysql-replication system-restore
您对于这个 Debian 备份策略有什么看法？

我并不是真正的系统管理员，我主要是一个具有一些 UNIX 知识的开发人员，并且由于我们没有任何称职的系统管理员，所以我被委派实施备份策略的任务。

我们有许多 Web 服务器，一些运行 Mysql Server，其他运行 apache，还有一个运行 nginx，并且我们使用 SVN 作为版本系统。

我们期待实施备份策略，并能够自动恢复服务器。

我们想到了两种可能性：

  1. 每天 RSYNC 整个磁盘
  2. 分析我们的配置，规范每个安装步骤，仅备份这些信息，并使用 MySQL 复制和 SVN 恢复数据，以及 rsync 仅备份配置选项和软件包列表

在我们看来，第一种方法的优点是实现起来非常简单，缺点是占用大量服务器资源（CPU / RAM /带宽）

因为我们不想看到我们的服务器因为运行备份脚本而滞后，所以我们决定更深入地研究（2）。

经过一番思考，我想到了一个主意，我们的每个服务器可以分成 5 个部分

1 - Web服务器数据

SVN 可以处理我们所有的 php/css/js/html 文件，我们只需要有一个配置文件来存储有关文件夹和存储库的信息。例如：在文件 /etc/backup/svn_folders.list 中，我会

FOLDERNAME1    SVN Repository Address1
FOLDERNAME2    SVN Repository Address2
etc...

然后在发生崩溃的情况下，我们只需要解析这个文件，然后 SVN checkout 。

2 - 使用复制功能备份 MySQL 数据

我们有 3 个主 mysql 服务器，我在备份服务器上实现了 mysql_multi，其中 3 个 mysql 实例同时运行，每个实例都是主服务器的从属。然后，每天，我

Stop slaves
mysqldump
start slave

这样，我就可以确定我们的主要 MySQL 服务器不会受到备份过程的影响。然后对于每个主服务器，我只需要将这些信息存储在 conf 文件 /etc/backup/mysql.info serverID = ID 中

要恢复数据库，我只需要从 conf 文件中获取此 serverID，然后将相应的转储映像从备份服务器 rsync 到恢复的服务器。

3 - 软件包列表

使用 debian，很容易知道系统上安装的完整软件包列表。cron 会将此列表存储到 /etc/backup/package.list 中

4 - 自定义应用程序

有时，我们需要手动安装软件包（perl，编译等...）我正在考虑创建一个文件夹/etc/backup/manual/，其中包含所有自动安装脚本，然后在恢复时，运行此文件夹中的每个脚本就可以了

5 - 配置文件

文件 /etc/backup/conf_data.list 包含所有配置目录（例如：/etc）的列表，可以通过 cronjob 进行解析，然后在备份服务器上进行 rsynced。

在恢复时，我们需要首先恢复 /etc/apt/sources.list，执行步骤 4，然后将保存的配置文件 rsync 回服务器。

你能告诉我你对这个概念的看法吗？你已经实施过类似的东西了吗？你遇到过问题吗？

答案1

我认为你已经想出了一个不错的计划，但是上面有 2 个错误。rSync 仅备份更改，而不是整个磁盘，并且如果配置文件发生变化，rsync 应该获取配置文件，无论如何假设你配置正确。

我的意见是，你需要首先对丢失这些数据的代价进行可靠的评估，并根据你的知识决定是否值得冒这个风险。如果成本高于你的舒适区，你需要寻求一些咨询或聘请另一家公司来实施可靠的策略。没有冒犯的意思，但如果存在重大风险，你肯定不想在事情失败时承担责任。我见过有人因为这样的事情而丢掉工作。他们想做得更好，但当事情进展不顺利时，他们就无法自拔了。有时你只需要知道什么时候退出。如果失败了，你仍然可以提出意见，但不必承担责任。

只是纽约.02

答案2

您可能希望将 aptitude-create-state-bundle 的定期运行添加到您的方案中，以实现完整的系统恢复。请参阅http://man.he.net/man1/aptitude-create-state-bundle。

相关内容