Thanks for the reply's To be clear when the change scripts is applied to production they have been tested on our CI server and in our pre-prod environment. We also uses the same pattern as Sean described, where script files are numbered and applied in the correct order (https://dbup.github.io/). We have been using this way of updating our schema for a few years now and it works very well. So far we have been avoiding our backup windows. However it would be very nice if we could use these backup windows too.
From what i can read in your reply's, it is safe to make these changes during backup - provided that the scripts have been tested. @Helen, the fact that changes made during backup i not included in the backup is totally fine, I wasn't expecting them to be. You write " It's too easy for human error to put the states of the current database and the backup out of synch inadvertently." What do you mean by putting the state of the backup out of sync? As long as the backup is not damaged in any way, and I am able to restore the database to the state it was in when the backup started, then i am happy. If the database suffers a fatal error and we need to restore the backup, we will be able to apply the change scripts again and use our event source to reply user actions. In the original message i forgot to ask about what happens if a column or table is deleted during backup? //Thomas
