I suffered dearly from this practice.
I had one client who required the fastest restore possible; naturally, I made frequent
differential backups. As you??™ve already seen, differential backups are tied directly to a single
full backup. This client frequently took full backups of the production database and
restored them to a development box. Due to the size of the backup file, the client immediately
deleted it once the database was restored. Initially, this didn??™t worry me, because
I was taking differential backups each hour. As you may have already guessed, the server
went down, destroying the database in the process. When I went to begin my ???quick???
restore process, I discovered that the server had gone down just after a full backup was
taken for use on the development server. All of my differential backups were now invalid.
I had to use the previous night??™s full backup and apply every transaction log up to the
point of failure.
If only copy-only backups existed back then. A new feature in 2005, the copy-only
backup does not reset the backup chain. As far as differential backups go, the copy-only
backup never happened.
Pages:
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111