November 10, 2016 at 8:12 pm
Comments posted to this topic are about the item The Google Solution
November 10, 2016 at 10:05 pm
As part of my backup process, I have a script that runs that creates a text file with the restore statements for all of the databases that have been backed up. That way, if I ever need to restore a backup, I just go to the text file, copy the appropriate restore statement and restore the database. I also use this text file to test the backups of all of my databases on a test server. My SQL environment is not complex, but this approach has definitely made me spend a lot less time on my restores.
November 11, 2016 at 7:11 am
Not sure I agree with the complexity. I had a large database that took both a long time to backup and a long time to restore. Then, based on an article I'd read on SQL Server Central (thanks), I started striping the backups. This significantly reduced the time needed to backup and restore, but it did make the restore a little more complex. Maybe that's not quite the intent, but in my view the increased speed came in handy a few times when we needed intra day restores and the added complexity had to be managed.
November 11, 2016 at 10:17 am
Perhaps one way to make restores easier is to generate the restore script at backup time for any particular full backup.
That could be a great way to improve the restore process.
November 11, 2016 at 10:55 am
Steve Jones - SSC Editor (11/11/2016)
Perhaps one way to make restores easier is to generate the restore script at backup time for any particular full backup.That could be a great way to improve the restore process.
I've written this as a part of the backup job for both full and log backups. The step executes a procedure that generates the restore statements for each database up to and including the most recent backup. It takes recovery model into account and also restore order. I write it out to an SQL file and it's saved to the backup volume. Happily, I haven't needed it yet.
November 11, 2016 at 11:26 am
Perhaps one way to make restores easier is to generate the restore script at backup time for any particular full backup.
That could be a great way to improve the restore process.
A good idea. Since the backup files are date stamped as part of the backup file name, the restore script always needed to be altered. It doesn't take long, but in an emergency removing any time and anything subject to human error that's possible to remove is helpful.
November 13, 2016 at 8:36 am
Interesting article. Normally I wouldn't comment on this topic because in a way its very cut-and-dry. However, this week I've witnessed the importance of that. The week of the November 7th we had a major issue with one of our high profile applications and databases. I'm not personally involved with any part of the app nor database, so I can't say what happened, but I know that they've lost lots of data. It makes it difficult because while they're working on restoring it they've got to leave it open for people to use all over the state. The people working on it are putting in late hours each night. I've offered to help, but know so little of it that I'd probably be more in the way than a real help. Well, whatever it was that went sideways, backups are the thing that's going to save our bacon.
Kindest Regards, Rod Connect with me on LinkedIn.
November 14, 2016 at 8:46 am
Interesting read about Google and some of their processes. Thanks.
November 14, 2016 at 10:50 am
Absolutely restores are more important then backups. If the restore doesn't work or takes too long then that is the problem for the business. If the backup fails the problem isn't that the backup failed but that there is nothing to restore.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply