SQL Server 2008 备份最佳实践
无缘无故地，我丢失了数据库中的所有数据。幸运的是，这只是测试数据，但这让我思考如果使用生产数据库完成这一步会发生什么。
最终，每个开发人员都会遇到数据库问题并希望回滚数据库。我们不做任何事情来保护数据库，因为我们认为这是 DBA 的工作，但后来我们遇到了麻烦......
你们的备份最佳实践是什么？
Without not reason, I lose all my data in my database. Fortunately this was just test data, but this made me to think what will happen if this was done with a production db.
Ultimately, every developer got a db problem and want to rollback the db. We don't do things to protect the db, as we think its a DBA work, but then we got into trouble...
What are your backup best practices?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
由于所有开发人员也是我工作的 DBA，因此我们也共同负责我们的备份策略 - 如果您关心数据，请确保您至少了解备份的工作原理，即使您是不属于实际决策的一部分。
我做的第一件事（在设置任何数据库之前）是制定夜间维护计划，其中包括完整备份，并将这些备份定向到另一台计算机（我们的 NAS）上的中央网络共享。至少，出于对工作的热爱，不要将备份放在数据库文件所在的同一物理存储上。如果您在丢失磁盘的同时也丢失了备份，那么备份还有什么用呢？
我们不进行时间点恢复，因此我们不进行日志备份（我们所有的数据库都设置为简单恢复模式），但如果您想要备份日志，请确保也包括这些日志，作为也是可以接受的间隔。
附带说明一下，SQL 2008 支持压缩备份，这大大加快了备份时间并使文件变得非常非常小 - 我想不出您不想使用此选项的实例。不过，我很想听听，并且我愿意重新考虑！
Since all the developers are also the DBAs where I work, we're collectively responsible for our backup strategy as well - if you care about the data, make sure you're at least informed about how the backups work, even if you're not part of the actual decisions.
The VERY first thing I do (before I even have any databases set up) is set up nightly maintenance plans that include a full backup, and direct those backups to a central network share on a different computer (our NAS). At the very least, for the love of your job, don't put the backups on the same physical storage that your database files sit on. What good are backups if you lose them at the same time you lose the disk?
We don't do point-in-time restores, so we don't do log backups (all our databases are set to Simple recovery mode), but if you want logs backed up, make sure you include those as well, as an acceptable interval as well.
On a side note, SQL 2008 supports compressed backups, which speeds up backup time considerably and makes the files much, much smaller - I can't think of an instance where you wouldn't want to use this option. I'd love to hear one, though, and I'm willing to reconsider!
以下是我自己的经验中的一些要点：
这不是完整列表，您可以在我的文章 https 中找到更多提示://sqlbak.com/blog/backup-and-recovery-best-practices/
Here are some points from my own experience:
And this isn't a whole list, you can find more tips in my article https://sqlbak.com/blog/backup-and-recovery-best-practices/
选择正确的备份策略是 DBA 在开发数据库时应考虑的最重要因素之一。
然而，您选择的备份策略取决于许多因素：
但总而言之，我想说的是，每晚安排一次备份，然后每隔一段时间进行事务日志备份。
Choosing the right backup strategy is one of the most important factors a DBA should consider at the point of developing the DB.
However the backup strategy you choose depends on a number of factors:
But in all, i would say, schedule a nighly backup every night, and then transaction log backups at intervals.