Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase «««23456»»»

Risky Backups Expand / Collapse
Author
Message
Posted Tuesday, January 13, 2009 9:51 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Yesterday @ 8:12 AM
Points: 70, Visits: 796
I'm curious how many people verify their backups. I found that step can take twice as long as performing the backup itself.
Post #635582
Posted Tuesday, January 13, 2009 9:52 AM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Wednesday, May 9, 2012 10:26 AM
Points: 891, Visits: 1,958
I both like and don't like the concept of the backup file containing the date of backup, right now I don't code the date into the file name on our systems, and I don't use maintenance plans for backups. It's nice in that you can look at the file and see the database name and backup date, but the file has a timestamp that also shows the date, so the information almost seems redundant since the file timestamp is not altered when the file is restored. Plus, the thought of digging in to the system tables (though I love working with system tables!) to find file names to delete just really bugs me for some reason. I prefer to have my system just overwrite the backup and not worry about it. On occasion a backup will fail and something will have squirreled-up the backup file, in which case I delete it and do a backup with overwrite and that seems to take care of it.
Post #635585
Posted Tuesday, January 13, 2009 9:58 AM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Wednesday, May 9, 2012 10:26 AM
Points: 891, Visits: 1,958
don.schaeffer (1/13/2009)
I'm curious how many people verify their backups. I found that step can take twice as long as performing the backup itself.

I always verify all backups at the SQL Server level, but that doesn't verify against the data, just that the backup is structurally sound. My guy who does the actual Tivoli backups confirmed that he does compares, but it might just be at the computed CRC value. Tivoli is a pretty bloody complex system, he said he'd have to research exactly what a verify consists of to give me a better answer.

Yeah, it could easily double your backup time, though with compressed backups....
Post #635593
Posted Tuesday, January 13, 2009 10:24 AM
Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Tuesday, August 19, 2014 8:15 AM
Points: 3,214, Visits: 2,325
All I have to say is:

If you do not want to get hit by a train ...
do not sit on the railroad tracks !




Regards
Rudy Komacsar
Senior Database Administrator

"Ave Caesar! - Morituri te salutamus."
Post #635627
Posted Tuesday, January 13, 2009 10:33 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Thursday, April 24, 2014 11:20 AM
Points: 31, Visits: 340
Just remember your backup is only as good as the restore of the data. If the restore fails then as far as the customer is concern you didn't backup their data.:D
Post #635636
Posted Tuesday, January 13, 2009 10:51 AM


SSCoach

SSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoach

Group: General Forum Members
Last Login: Friday, June 27, 2014 12:43 PM
Points: 15,444, Visits: 9,596
I do each backup to separate files. Name with DB name and datetime YYYYMMDDHHMM (hours and minutes matters with log backups). Single file = single point of failure = not a good idea.

I test the backups at least weekly.


- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread

"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
Post #635654
Posted Tuesday, January 13, 2009 11:14 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Thursday, April 24, 2014 11:20 AM
Points: 31, Visits: 340
Yes you can setup to go to minutes
Post #635676
Posted Tuesday, January 13, 2009 12:00 PM
Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Friday, August 10, 2012 6:08 PM
Points: 1,156, Visits: 801
Having seen corrupt backup catalogs, disk failures, and the like, I prefer simplicity on recovery; so my vote and practice is to separate the backups, not over-write existing files, and permanantly archive date-named regular intervals.
Post #635722
Posted Tuesday, January 13, 2009 12:25 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, May 16, 2013 12:15 PM
Points: 9, Visits: 66
Always run a verification. It is also a real good idea to run restores periodically.

One of the worst feelings I have had was pulling a backup from tape (approx 6 hours) and restoring (another 6 hours) to find the database could not be brought back on-line. After a call to Microsoft support we determined the best course of action was a previous days backup.

It was a very good thing the backup from the previous day worked, and the nature of the business allowed re-processing the missing day's work.

Post #635749
Posted Tuesday, January 13, 2009 12:42 PM


SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Friday, February 4, 2011 7:20 AM
Points: 977, Visits: 1,499
This is funny to me, because until my 1st 2k8 installation Christmas week, I didn't know that SQL Server would actually append to an existing disk file. That didn't stop me from anally not selecting 'Append to existing media" when doing a manual backup.

Size, simplicity, manual file manipulation. Those are all good enough reasons for me. I wouldn't want to be the stranger picking up the pieces that came across something named "ALL_SYSTEM_DBS.BAK." There really isn't any difference between multiple DBs in a single file, and multiple files in a single folder.

I'll stick to separate files.


Tom Garth
Vertical Solutions

"There are three kinds of men. The one that learns by reading. The few who learn by observation. The rest of them have to pee on the electric fence for themselves." -- Will Rogers
Post #635764
« Prev Topic | Next Topic »

Add to briefcase «««23456»»»

Permissions Expand / Collapse