我一直在寻找我们为托pipe客户端实施的设置，他们每天都有数次备份的数据库（并且备份的最后一周始终可用）。 假设备份需要20GB，而它们托pipe的驱动器（分区，真的）是30GB。 在驱动器上有超过10GB的其他“东西”，通过SQL 2000安装，操作系统和其他各种各样的东西，这意味着有一个不断的努力，以保持在完全满的驱动器。
我认为没有必要在SCSI驱动器上存储一周的备份，但我并不是这方面的专家，我真的只是寻求其他DBA的build议来处理这种备份scheme。
值得注意的是，目前我们使用的是3个驱动器，镜像的RAID设置，以及任何时候都可以使用的备份。 因此，灾难恢复是问题的核心，同时最大限度地降低成本。
任何input欢迎….
在此先感谢人。
我之前作为标准SQL Server设置/备份程序（SQL 2000-2008）实现的内容如下
数据分区将OS / SQL二进制文件，数据文件和日志文件拆分为3个独立的物理卷，RAID 1上的OS / SQL，RAID 1上的数据（以下为来自Paul Randall（ http://www.sqlskills.com/ ），logging在RAID 1上。另外推荐1-2个热备份。我会推荐至less一些级别的RAID，但是如果空间/成本是问题的话，RAID 1将它们全部放在一组硬盘上，您仍将具有与RAID 5相同的冗余级别（最多1个驱动器故障）（假设分别为2个和3个驱动器）
数据库设置为每个数据库实现3个数据文件，数据和日志以及NDF的默认MDF和LDF，将NDF设置为数据库属性中的默认数据文件，并保留MDF。 我已将所有数据库设置为完全恢复模式，因为我进行了镜像，并且需要能够执行时间点恢复。 我会build议这样做，但它确实带有警告（下面）
BACKUPS数据库设置中最重要的部分是使备份（和相关的恢复）正确。 我们的标准化设置是一个完整的备份@ 2am，当我们有一个不使用数据库的人窗口（从新加坡到纽约的多个时区的员工进行全局操作），然后从上午8点开始每5小时进行一次事务日志备份（0800，1300 ，1600，2100）。 免责声明确保如果你有你的数据库设置为完全恢复模式，你正在做事务日志备份，否则你可以结束了怪异的日志文件，然后你可能不得不截断，然后收缩他们，这根据保罗·兰德尔（嗨保罗！），我会信任与SQL隐含的，是一个很有趣的（tm）。 每日备份（包括与之有关的交易logging）保存在本地，然后由我们的备份服务每晚备份，并由pipe理员值class。 这样，如果机器丢失，我们只丢失上一次完整备份的数据，而在有人搞砸数据的情况下，只有最后一次T-Log备份和那个时间点之间input的信息（我们可以进入当前日志和回放任何其他交易，但我们通常不这样做我们的SLA是为了适应这个）你当然可以发送交易日志备份离开机器，甚至在现场创build时，但这是一个决定让你做。
数据文件收缩不要这样做（除非你陷入了无法避免的情况）当然不要安排它！
索引和碎片这应该是一个手动（但是脚本）的操作，只有在需要的时候才能执行，你应该定期进行维护，索引碎片应该在这个列表中。 在我的月度计划中，我检查了数据文件的大小，索引碎片和数据库的数量（我们有时候会让开发人员添加数据库，而不是告诉我们，维护计划需要照顾备份，但有时他们搞砸了数据文件的布局和命名约定），如果我们检测到任何新的数据库，他们会根据其大小，数据文件的布局和备份进行审计（从不伤害检查和双重检查备份）
请随便任何人，在上面挑选洞，或者至less告诉我，我说的是废话。
不要从“备份”的angular度来看它，从“还原”的angular度来看它。 坐下来定义你所需要的东西，以便能够恢复正常，testing一些恢复情况，以确保你的列表正确和完整，然后才开始考虑你的备份策略。
通常在服务器应用程序中，备份操作系统，程序文件，configuration以及所有其他的doo-dahs是我认为必不可less的。 原始数据的恢复很容易，但configuration的恢复不是。 除此之外，您还有最新的修补程序级别，操作系统和应用程序configuration，您可能为服务使用而创build的任何本地用户帐户，等等。
所以，备份一切，你肯定你没有错过我的口头禅。
现在，您每周都要在同一个存储上备份一天的备份。 如果你不小心丢失了一些数据，这很好; 如果你失去了操作系统或有硬件故障，你是EFF-YOU-SEE-KAY，并且没有错误。
我以前使用过的一种方法是在日间将常规数据（仅）转储到磁盘，而在晚上将所有内容全部备份到磁带。 这可以减less日间转储的存储需求，从而为意外丢失的数据提供更长的恢复时间（保持一周以上的价值）。 保持磁带完整意味着如果需要的话，我甚至可以对备用服务器进行全面恢复。 我可以走得更远，但现在我的业务需求并不需要我 – 你的能力。
如上所述，您当前的备份计划并不真正涵盖需要进行灾难恢复的许多场景。
至less应该备份一台机器，以免发生像电源故障一样的严重事件，一次性杀死所有驱动器，最好是在另一个地方，以防服务器所在的build筑物发生故障。
在服务器本身保留备份的本地副本以及轻松访问（例如在您build议的新的更大的驱动器上）是没有问题的，但这些不应该是您唯一的备份。
从目前的空间受限的位置，我build议只保留机器本地最新的几个备份，并保留在另一台机器上的更大的驱动器上，如果可能的话，最好在场外（像rsync这样的协议可以减less离线所需的带宽）网站备份大大）。 如果机器是您可以物理访问的机器，那么您可以（或者也可以）通过将备份复制到外部驱动器并在其他时间保持远离机器（或者更好地，具有两个或更多个外部驱动器和循环它们 – USB笼中的大型驱动器现在非常便宜）。 在物理访问的情况下，周期中带有多个磁带的磁带机可能是更好的select。
所以，当你有三个驱动器，你真的只是使用一个驱动器值得的空间，对不对？ 两个驱动器在镜子+第三个作为备用…
通过迁移到RAID 5可以获得一些空间
这就是说，你可以添加另一个大的驱动器来保存备份，就像你刚刚提出的那样。