最近我阅读了大量有关服务器端备份软件和策略的资料。
我很好奇想知道经验丰富的系统管理员（ServerFault 上）使用什么策略和软件。
- 数据备份和服务器备份的注意事项。
- 当服务器真正崩溃时该怎么办。
- 您想要分享的与备份和恢复技术相关的任何其他信息。
请发布您使用此策略的环境（Windows、Linux 等）
希望从这篇文章中学到很多东西，并在我最终确定自己的备份策略后尽可能地做出贡献。;)
答案1
O'Reilly 出版的《备份与恢复》一书。强烈推荐。
答案2
我和我的团队有几条规则。希望其中一些对你有用。
- 所有数据（日志和缓存除外）都应备份。不要指望系统永远不会崩溃。它会崩溃的。有时我们也会备份日志和缓存分区，以加快系统恢复过程，而无需创建目录、使用权限等。
- 记录备份的内容和备份位置。处理任何数据时，要习惯于始终记住备份的位置、备份频率以及如何恢复。
- 选择平台时，请务必检查其备份解决方案。尤其是崩溃后恢复系统的速度。在知道如何备份和快速恢复之前，不要选择平台。安装前尝试备份/恢复，广告总是骗人的。
- 只对经常更改的数据进行频繁备份。每小时备份整个系统是愚蠢的做法。
- 任何关键服务器都应至少有一个重复服务器，可以自动替换故障服务器。
- 进行备份审核。至少每周一次。自动备份系统很容易出现故障，尤其是在 X 日前几天出现故障。
- 将所有可能的数据保存在共享存储中。这样备份起来就容易多了。但不要完全信任共享存储，确保可以快速将所有内容切换到备份存储，最好系统可以自动执行此操作。
- 使用 ZFS 快照或类似技术。一次完整备份 + 增量备份，结合完整备份。如果系统需要多次进行完整备份 - 这是一个糟糕的系统（当然磁带除外），我们生活在 21 世纪。
- 选择磁带解决方案时，请务必计算每 TB 的价格。如果它与普通 HDD 价格相同或略低，那就忘了磁带吧。除非您不需要快速恢复数据，否则对于非紧急档案，我更喜欢磁带，即使它更贵。
- 训练自己。没有训练，你的生产力恢复时间会更长。
最后，也是最重要的一点：
- 人为错误 - 数据丢失最常见的问题。将所有数据保存在两个副本中。足够分开以避免用一个或两个命令同时杀死两个。这是 RAID 不是备份的主要原因。重大硬件故障只会发生在第二甚至第三位置。
我们使用的内容：
对于服务器 - 我们的一切都在 VMWare VSphere 上，并且对它的 DataRecovery 几乎很满意。对于 Oracle 和其他数据库，我们使用它们的内部工具。对于工作站 - 我们最终将所有内容迁移到 iSCSI 或瘦客户端，因此不再有缓慢的 Acronis 和其他垃圾。
答案3
我们有一个混合环境（70% Linux 和 30% Windows）。由于（大部分）遗留原因，我们在 Windows 端使用 EMC Networker（带磁带更换器），在 Linux 端使用 bacula。所有 Linux 服务器都通过 bacula 覆盖，然后该服务器上的备份目录将包含在 EMC 备份中（我们的夜间备份大小约为 3TB）。
基本策略是，对于所有机器，我们仅涵盖无法通过标准源恢复的部分。换句话说：数据文件、数据库、配置文件等。在某些情况下，备份过程没有本地客户端，而是使用 NFS 挂载来访问需要备份的内容（因为除了 NFS 挂载之外，这些目标服务器一直在变化，而仅提供 NFS 挂载点更简单）。
如果服务器完全失灵（从未发生过这种情况），我们会购买替换硬件，安装操作系统和所有软件包，恢复配置文件和数据，然后您就可以开始使用了。如前所述，我们从未遇到过服务器完全失灵的情况。我们的备份主要用于用户意外删除文件或文件损坏的情况。我们曾遇到过一些构建服务器必须从头开始恢复的情况，因为一些工程师将它们置于无法正常恢复的状态，而原理运行得很好（除了恢复 30GB 数据需要一些时间）。我可能应该补充一点，我们所有的关键任务服务器都运行在 RAID 阵列和冗余电源上，而且我们通常还会保留相当多的备用硬件。