March 29, 2009 at 3:12 pm
hi,
I have schedule a mantanace plan to backup the database on daily basis, it backups the full databse and i have the set the expiry after 6 days. Now my requiremtn is that i want to keep the backup of 6 days and delete other backups, iam using the hard drive for my backup no external storage.
I have schedule this on production but it does not delete the old backups, i have to manually delete all old backups and keep the recent 6 backups.
Can any body tell me what is database expiration ?? and tell me the starategy to implement this scenario.
Thanks in advance.
March 29, 2009 at 7:12 pm
Database Expiry date is not for deleting old backups; it indicates when the file can be overwritten. But since you are using the maintenance plans the file name will always be new so it will never trigger that.
Instead of using that, use the "Maintenance Plan Cleanup" task, set it to delete backups older then 6 days.
Thanks.
Mohit K. Gupta, MCITP: Database Administrator (2005), My Blog, Twitter: @SQLCAN[/url].
Microsoft FTE - SQL Server PFE
* Some time its the search that counts, not the finding...
* I didn't think so, but if I was wrong, I was wrong. I'd rather do something, and make a mistake than be frightened and be doing nothing. :smooooth:[/font]
March 29, 2009 at 8:15 pm
mohit is correct.
Expiration is for overwriting backups, like if you had multiple ones in a file. (which is a bad idea)
March 30, 2009 at 6:55 am
Steve Jones - Editor (3/29/2009)
mohit is correct.Expiration is for overwriting backups, like if you had multiple ones in a file. (which is a bad idea)
I'm not saying you're wrong, in fact I agree, but I'm curious why you said that.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
March 30, 2009 at 7:11 am
Which part? The multiple backups in one file? I'd say that it's a poor practice because are increasing your risk. Every file has the chance of corruption, bad blocks, something going wrong. If you put multiple backups in one file, and it corrupts, you can lost multiple days worth of backups, which would mean that either you go back to tape, which might break your SLA and defeat the purpose of keeping more than one backup on disk.
Or you are restoring from more than 2 days ago. Potentially not restoring at all.
March 30, 2009 at 7:47 am
Yep, that was it. I was just curious what your thought processes were. I do agree.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
March 30, 2009 at 11:18 am
Grant/Steve,
Going to pop another question about backups that I am curious about; I always have done backups directly to file using BACKUP DATABASE DBNAME TO DISK = ''... But I have acquired some servers where they used Backup Devices instead (SQL 2000), they are backup files also. I have yet to discover an advantage to using backup devices over just direct backups? I changed the backup because one device held backups for more the one day and I didn't like the idea of that because if the device went then I was out of backups for whole week. Can you guys think of an reason other then they left it because it was in 6.5 for backwards compatibility?
Mohit.
Mohit K. Gupta, MCITP: Database Administrator (2005), My Blog, Twitter: @SQLCAN[/url].
Microsoft FTE - SQL Server PFE
* Some time its the search that counts, not the finding...
* I didn't think so, but if I was wrong, I was wrong. I'd rather do something, and make a mistake than be frightened and be doing nothing. :smooooth:[/font]
March 30, 2009 at 12:10 pm
My memories of 6.5 are fuzzy (and painful) but I think you could backup directly to disk even then, but I could be wrong.
The one reason I can think of to use a device is because you change it without changing the backup scripts. As long as the device name is the same, you can change where the device stores information, but you don't have to modify the scripts.
However, since I do backups to individual files, I have to change the names every time anyway. So I don't see the savings possible in something like this.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
March 30, 2009 at 12:16 pm
you could go to disk in v6.5, did it for years. Never to tape directly since that was slow, and error prone.
Devices are there precisely to have the same script/code on every server. So you could a one script that backed up everything to once device. This was left over from the Sybase/tape world, and I think it's a poor practice as well for the same reason.
It's too easy to code around the need for the same name these days to do that. If it were 400 lines of script I could see devices working well, but with simple T-SQL/VBScript/Powershell, why do it?
March 30, 2009 at 12:23 pm
Chandio, for the way you are describing your set up, you will need to write a script to check the dates and delete them after they expire. You can do that in T-sql and incorporate it into your backup jobs, or you can write it as a shell script or some other language like python and then make it an operating system job.
Another option is to use a 3rd party program, such as RedGate sql backup, which will manage that for you.
---
Timothy A Wiseman
SQL Blog: http://timothyawiseman.wordpress.com/
March 30, 2009 at 12:23 pm
Thanks guys ;-).
Urg yaa 6.5 is nightmare but I have to support 2 Production and 1 Dev/Test install of 6.5. Heh you can backup directly to file in 6.5 but for some reason I keep running into issues when I restore.
When I backup to the Device I get a backup that is 100+MB, same database when "dump" to the file goes to only 10MB file. So when I restored the database on other server it cased way too much grief. So I just do Device Backups/Restores; even though it is annoying heh.
Mohit.
Mohit K. Gupta, MCITP: Database Administrator (2005), My Blog, Twitter: @SQLCAN[/url].
Microsoft FTE - SQL Server PFE
* Some time its the search that counts, not the finding...
* I didn't think so, but if I was wrong, I was wrong. I'd rather do something, and make a mistake than be frightened and be doing nothing. :smooooth:[/font]
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply