我们没有DBA，我必须做备份。 我们只有一个数据库是3GB（其他的小于100MB）。 3gb数据库是重写的，并且有非常重要的数据。 我为所有数据库设置了每日备份，但是我认为这可能还不够。
好吧，你真的需要头脑文件，并阅读它 – 成为一个小dba。 希望这里的人从BOOKS ONLINE – SQL Server文档中复制/粘贴极其详细的信息 – 不是很好的行为。 这就是说，你也是错误的网站 – 这绝对不是一个编程问题。 有一个姊妹站点（serverfault.com）用于服务器操作问题，即备份所属的站点。
为了让你开始：
事务日志logging对数据库所做的所有更改。 这意味着你做了一个完整的备份，然后tx日志可以用来滚动转发到最后的交易备份在日志中。 意味着如果您在16小时之后备份了tx日志，服务器就会死亡，在新服务器上恢复每日备份，然后处理事务日志并在16小时后返回到上一次提交的事务;）如果您要求我 – 一个没有这样做的企业应该得到不这样做的损失。
与传统的文件级备份相比，事务日志实际上是HUGH在SQL Server等方面的优势。
所有其他问题，我不能回答。 认真。 这些不是“dba级”的决定，它们是商业决策。 我知道公司每5分钟进行一次事务日志备份，将它们传送到一个安全的服务器（检查：日志文件传送）。 原因：数据丢失将是一场灾难。 想象一下亚马逊半天的销售情况。 我知道其他企业每天都在做，有时甚至是每周备份（小商店，内联网站点）。 我知道其他人不依赖备份解决灾难问题，而是使用复制和/或镜像，每日完整备份和每小时日志备份，这样，如果服务器死亡，他们不会得到任何停机时间。 从技术angular度来看，所有这些都是“相同的” – 每个build议都取决于您所说的商业案例。
作为一个正常的情况，我会build议定期完整备份（每周，在rest时间如周日），每日差异bakups（比完整的一个小很多），然后一个日志备份每x小时（1，6，12 – 取决于你的商业案例）。
其他人给了你一些基本的概述。 我会给你一些通用的答案，但请注意，实际的答案将取决于你的业务需求。
事务日志备份备份事务日志。 此日志logging在数据库上执行的每个事务。 当数据库处于简单恢复模式时，该日志将在数据库上的每个检查点之后清除。 数据库处于完整模式时，这些日志将继续填充事务，直到备份或手动截断。 通过备份事务日志，您可以将它们与“常规”数据库备份结合使用，以在恢复数据库时前滚到最近执行的事务。
这个问题没有一个答案，但总的来说，我倾向于每周完整备份，并结合每日差异备份。
日志备份将由您创build的SQL维护计划执行。 您执行这些备份来清除事务日志，并logging事务以防需要恢复它们。 请注意，如果您不打算使用事务日志备份，则应将数据库更改为简单恢复模式，以避免出现完整日志或完整磁盘问题，因为处于完全恢复模式时事务将不会从日志中自动清除。
您可以使用应用程序所需的任何频率执行日志备份。 例如，如果丢失超过5分钟的交易是不可接受的，那么您需要每五分钟执行一次日志备份，并结合常规的完整和差异数据库备份。
这完全取决于你的需求。 我的标准是每周完整加每日差异，然后每隔15到30分钟为完整恢复数据库logging备份，如果需要，则按照另一个计划logging备份。 您需要做出的另一个决定是为了恢复目的而保留备份多长时间。 主要的折衷显然是pipe理和磁盘空间需求的复杂性。
我不是专家，但我的理解是，使用事务日志备份可以回滚发生的事务。 如果你不想撤销已经发生的事情，这是没有必要的。
这个问题“每天完全备份足够吗？” 取决于情况。 如果是每24小时，并且在备份前1小时您丢失了数据库，那么您已经损失了23小时的数据。
差异备份会备份自上次完全备份以来的所有更改，增量备份会备份自上次完全备份或差异/增量备份以来的所有更改。 根据您的设置，其中之一可能对您有用。
您可以执行一些操作，例如在完全备份过程中添加差异备份，或在整个一天中使用增量备份。