Question

I was trying to backup all my SQL Server databases and came across the following script from here:

DECLARE @name VARCHAR(50) -- database name  
DECLARE @path VARCHAR(256) -- path for backup files  
DECLARE @fileName VARCHAR(256) -- filename for backup  
DECLARE @fileDate VARCHAR(20) -- used for file name 

SET @path = 'C:\Backup\'  

SELECT @fileDate = CONVERT(VARCHAR(20),GETDATE(),112) 

DECLARE db_cursor CURSOR FOR  
SELECT name 
FROM master.dbo.sysdatabases 
WHERE name NOT IN ('master','model','msdb','tempdb')  

OPEN db_cursor   
FETCH NEXT FROM db_cursor INTO @name   

WHILE @@FETCH_STATUS = 0   
BEGIN   
       SET @fileName = @path + @name + '_' + @fileDate + '.BAK'  
       BACKUP DATABASE @name TO DISK = @fileName  

       FETCH NEXT FROM db_cursor INTO @name   
END   

CLOSE db_cursor   
DEALLOCATE db_cursor

This works perfectly fine except that I’m thinking that I’ll have to reconstruct all the indexes of the database after I restore it. I wanted to know if it is possible to dump the CREATE statements for all the indexes so that I can re-run them in one-go after restoring all these database?

Answer 1

Is this the regular maintenance backup operation? If not, then it must add a WITH COPY_ONLY clause, otherwise it breaks the backup chain.

As a regular maintenance backup this is rather poor:

• it ignores each database recovery model (may be different)
• it does not do a good job of scheduling full/differential/log backup (ie. uses way too much disk space and causes way too much disaster recovery loss of data)
• it is not error safe, one db error will fail the entire loop
• it does not sanitize the file names generated (eg. a database named [a:b] will create an invalid file name and always fail).
• it does not do maintenance of old backups and reclaim disk space from obsolete backups
• it does not allow for things like backup compression
• backup on the same disk as the database is a useless illusion of safety, you’ll lose all data anyway on disk loss

But ultimately the fundamental issue is that you’re looking at it from the wrong angle. Your goal is not to have a backup plan, but to have a recovery plan. Read some more here: Importance of testing your disaster recovery plan. And btw, you need a recovery plan for master too.

As for your question about indexes, I don’t think you understand how SQL Server backup works at all. Start here: SQL Server: Recovering from Disasters Using Backups