我需要在 Ubuntu 9.04 上组织数据库、网站、ftp、电子邮件等的自动备份，由于我以前从未做过，所以我正在寻找可以学习的地方。需要做什么、我可以使用哪些（免费）软件、提示和技巧、最佳实践等等。如果您能为我指出适合初学者的相关文章，我将不胜感激
答案1
根据您的目标、基础设施和媒体偏好，有很多选择。
首先，无论你最终选择哪种解决方案，你可能需要弄清楚如何设置 cron 作业。它是在 *nix 上运行计划任务的工具。
至于备份本身，我倾向于选择快照因为它的设置非常简单，而且可以满足我的需要。Amanda 和 Bacula 都是很好的解决方案，但涉及数据库和其他东西，这会使备份和恢复变得复杂。当我需要可靠的东西（例如备份的情况）时，我倾向于避免复杂的事情。Rsnapshot 使用 rsync 通过 ssh 在系统之间传输数据，因此它既安全又高效。然后它使用硬链接，这样您就可以获得要备份的文件系统的许多时间点快照。
数据库必须得到特殊对待，因为您要么需要在运行备份作业时锁定表，要么将数据库表转储到另一个位置，然后使用您选择的任何方法进行备份。如果您使用 MySQL，可以使用 mysqldump 等工具来完成此操作。此转储通常使用 cron 作业自动完成。
答案2
备份总是很难正确调整；特别是因为人们有不同的需求，并且这些需求通常是数据“快照”备份、数据存档、服务器（配置）备份、可靠服务等的混合。
3dinfluence 和 davey 都是对的：尝试恢复操作很重要（因为乔尔说) 和一组 cron 脚本通常是首先要做的事情；但还必须根据您可以“接受丢失”的数据量以及您需要的可靠性级别来采取其他措施。
因此，你需要问自己的问题是：
备份的目的 - “保护”您的数据/服务免受以下侵害：
- （本地）硬件故障，如磁盘崩溃；
- 更大的损害，例如建筑物起火；
- 用户错误（意外删除）或需要检索旧数据；
- 有缺陷的软件包版本（升级服务通常很困难，等等）。
出现不同类型的问题时，可接受的停机时间（和数据丢失）
- 磁盘故障？例如，无损失，无停机(?)
- 其他硬件故障（MB、CPU 等）？一天的工作成果白费，停机几个小时
- 火灾（以及消防员的水）？损失一周，停工几天
- 地震还是停电？
根据这些问题的答案，您将了解每日备份是否足够，或者是否需要位于不同地理位置的热备用服务器。
我并不是这个领域的专家，但也许我的例子可以给你一些启发。
我正在管理一个小型（debian）服务器，提供数据库（postgresql）、subversion 存储库、trac 站点和其他一些类似的功能；该服务器主要由我们的研发小组使用，所以人很少（~20 个用于 subversion 的客户端）和一些工具（~50 个用于数据库的客户端），但他们几乎 24/24 小时、7/7 天都在工作（尤其是那些为数据库提供测量数据的工具）。
如果出现一般问题（如主要硬件故障），停机 2 到 4 小时是可以接受的（仪器可以在本地工作一段时间）。所以我（目前）没有警告备用服务器，只有一组本地和远程备份和转储。
所以要求一点也不高：大约几百 GB 的数据，需要服务的客户端不到一百个。
第一道“防线”由磁盘冗余和分区提供（这不仅有助于解决磁盘崩溃的问题，还可以用于进一步的备份或服务器升级）该机器配备 4 个磁盘（每个 500Gb）。
- 2 个 (软) raid 阵列 (类型 1，位于 3 个磁盘上)：
- 一个小的，专用于 /boot
- 还有一个较大的，由 lvm 使用（见下文）
- 2个lvm组：
- 一个在大型 raid 阵列上制作（+第 4 个磁盘上的 1 个非 raid 分区）
- 另一个仅由非 raid 分区组成的（前 3 个磁盘上每个 50Gb，第 4 个磁盘上有一半）
- 最后，分区：
- / 和 /var 位于大型 raid 的两个 lvm 卷上；用户数据全部存储在 /var 上...
- 第一个 vgroup 的非 raid 扩展保留用于快照 (lvm)
- /boot 直接在小型 raid 1 阵列上
- /tmp 和第二个 vgroup（非 raid）中两个 lvm（线性卷）上的特殊 /backup。最后一个驱动器被使用，其他 3 个驱动器上的扩展被保留用于快照。
第二道防线是定期备份：它们由 cron 脚本制作，基本上每天启动一次（例如，svn 的热备份、trac 站点、db 文件的副本等）或每周启动一次（数据库转储、svn 转储等）。执行每次备份的具体方式取决于服务；例如，Subversion 提供了用于（快速）热备份（使用硬链接等）和文本转储的工具，但数据库使用简单的 rsync，由 lvm 快照制作。
所有这些备份都放在（本地！）/backup 分区上（为了加快速度）；此分区通常以只读方式安装；两个 sudoeable 脚本用于将其重新绑定到 rw 模式（备份开始时），并返回到 ro（结束时）。在 lockfiles 上生成的信号量用于处理并发备份。
每次将 /backup 切换到 ro（以及每 4 小时一次）时，都会安排一次镜像操作（使用稍有延迟的“at”连接第三行的更改）。镜像是（使用 rsync）到不同的服务器进行的，从该服务器将数据存档在磁带上（每天，仅保留一年），并通过网络传输到一组远程 terra 站。
为了避免损失一整天工作成果的风险，以最小的带宽成本，还设置了第三条线路，即在可能的情况下进行增量备份。
例子：
- 对于颠覆，每个修订都转储到一个单独的（压缩文件）中，来自 post-commit 和 post-revpropschange 钩子（使用 svn-backup-dumps）
- 对于数据库，使用连续归档（&PITR 概念）
这些增量使用与每日和每周复制相同的概念进行保存（首先保存到本地备份分区，稍有延迟后再保存到第二台主机上）。当然，每日复制和每周转储脚本必须处理增量的轮换。
请注意，第三行非常接近警告备用服务器（嗯，这是实现这一概念的必要步骤）。
最后，服务器本身的配置（如果需要设置新服务器，则可简化工作）。由于我对 ghosting 解决方案不满意（新机器将具有不同的硬件、磁盘配置等），因此我设置了一个专用的 subversion 存储库，在其中放置了我手动编辑的每个脚本或配置文件（直接或通过用户界面间接编辑）。因此，文件系统的根目录 (/) 是工作副本。此外，每天安排的 cron 任务负责保存已安装软件包列表 (dpkg)、分区表 (fdisk)、raid 和 lvm 设置等。
顺便说一句，这肯定是最薄弱的环节：服务器配置位于 Subversion 存储库上，由“同一”主机提供服务。无论如何，如果需要，可以相当轻松地从另一台计算机（甚至是 Windows 计算机）使用存储库备份之一（快速备份或转储）。
此外，在接触主系统上的任何脚本（或软件包升级）之前，我也会尽量认真地制作 lvm 快照。但这些 lvm 快照的生命周期应该尽可能短，因为这会给其他服务带来很大的损失。
好吧，我希望它能够有所帮助，或者至少提供一些想法......
答案3
我认识的大多数人都使用 Bacula 来达到这个目的。
他们有相当不错的文档，但这里有一篇文章可以引导您了解一些基础知识。
答案4
关于备份策略已经有了很好的答案。我开始喜欢一个简单的备份工具：备份管理器。
Backup Manager 非常轻量（实际上只是一些脚本），并且易于配置。它知道如何备份 SVN 存储库、MySQL 数据库，并且可以运行特定命令来备份您无法仅复制文件进行备份的其他系统。它以标准文件格式（tar、zip 等）存储备份数据，并可以将它们保存到许多不同的存储区域：本地磁盘、FTP 服务器、scp、Amazon S3……可能在途中使用 GPG 密钥对它们进行加密。另一个要点是它已经打包在 Debian 和 Ubuntu 中。
这绝对是一种简单而有效的开始方式，尽管您最终可能会想要一些更高级的东西。