很少使用的数据库的备份策略(几乎是存档的数据库)

Question

系统:我有一个拥有大约150个数据库的系统，每个数据库的大小约为2gb。

其中130人大多不活动，但需要上网。这些设置为简单恢复，活动dbs设置为full。

我有一个每天完整的备份和每小时的tran日志备份。我正在使用sql server维护计划备份，并且正在备份所有用户数据库。

这个问题(完全备份)会产生一个很大的备份集，由于各种原因，我觉得很难处理。

问题，我正在寻找一个不会导致不必要的备份大小的后退策略。

我没有使用差异备份(我认为这会减少非活动DB备份的大小)，因为我害怕不得不处理大量的文件，以防不得不从备份中重建。

我知道我可以维护不同的备份维护计划，并在数据库不活跃的情况下更新它，但是，当我添加新的活动数据库时，这是手动过程，我们每个月添加几个数据库。我以前做过这种事，也犯过错误.

有没有办法利用死气沉沉是简单的复苏的事实，以不同的方式威胁他们？

备份压缩怎么样？我从未使用过它，不确定这会对我的CPU使用造成什么影响(目前DB服务器通常是<15% CPU)。

谢谢!

PS，我不是DBA，而是一个开发人员。

Answer 1

这个(完全备份)生成一个大型备份集，由于各种原因，我发现很难处理这个备份集。

正如您所说的，您没有使用压缩，我相信当您使用备份压缩时，您可以得到很好的缓解。只需忘记CPU利用率，我曾多次使用备份压缩，在极端情况下，CPU利用率仅高出5-10 %。我建议你使用它，但在此之前请阅读文献资料

我正在寻找一个不会导致不必要的备份大小的备份策略。

备份策略是确保在需要时拥有有效的备份，并且使用该备份可以尽可能少地释放数据，除非使用数据压缩或备份压缩，否则几乎没有减少备份大小的策略。

有没有办法利用死气沉沉是简单的复苏的事实，以不同的方式威胁他们？

备份大小本身不受恢复模型的很大影响，它决定了在灾难发生时数据丢失的数量。

寓意:使用备份压缩，它可以解决所有的查询。

Answer 2

基于每个人的评论，我决定使用ola的脚本和备份压缩。我无法自动拥有两个备份集，但我能够轻松地排除一些不需要备份的大型数据库。

当使用压缩备份时，我没有注意到对CPU使用的任何影响。

感谢大家的建议