SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Risky Backups


Risky Backups

Author
Message
Steve Jones
Steve Jones
SSC Guru
SSC Guru (66K reputation)SSC Guru (66K reputation)SSC Guru (66K reputation)SSC Guru (66K reputation)SSC Guru (66K reputation)SSC Guru (66K reputation)SSC Guru (66K reputation)SSC Guru (66K reputation)

Group: Administrators
Points: 66012 Visits: 19120
Comments posted to this topic are about the item Risky Backups

Follow me on Twitter: @way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
Frank Rosser
Frank Rosser
Valued Member
Valued Member (54 reputation)Valued Member (54 reputation)Valued Member (54 reputation)Valued Member (54 reputation)Valued Member (54 reputation)Valued Member (54 reputation)Valued Member (54 reputation)Valued Member (54 reputation)

Group: General Forum Members
Points: 54 Visits: 137
Our rule of thumb is:

1. Never overwrite an existing backup file.

2. Always have at least 2 separate, usable backup files on availiable media.

The first was to handle the situation where an ad-hoc backup was run outside of the usual backup cycle, plus it makes it easy to quickly check if a backup file exists. The second was insurance against media failure.

The solution was to timestamp all backup files to give them a unique name. It does make the backup/recovery scripts more complex to write, but the extra effort is worth the peace of mind.



John McC
John McC
Right there with Babe
Right there with Babe (730 reputation)Right there with Babe (730 reputation)Right there with Babe (730 reputation)Right there with Babe (730 reputation)Right there with Babe (730 reputation)Right there with Babe (730 reputation)Right there with Babe (730 reputation)Right there with Babe (730 reputation)

Group: General Forum Members
Points: 730 Visits: 1678
I usually have about two weeks worth of backups on the server, each database in its own folder and separate files, which are baked up nightly to a remote location. I think it's a case of belt and braces (and maybe a second set of each) just to be safe.

Once bitten once fired w00t

-------------------------------------------------------------------------
Normal chaos will be resumed as soon as possible. Crazy
SQLPhil
SQLPhil
SSCommitted
SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)

Group: General Forum Members
Points: 1582 Visits: 740
I've only ever backed up to a single file when taking short-term baselines of environments.

But as a general rule it's back up each of my databases to their own individual file.
Ðiamond Geeze?
Ðiamond Geeze?
Old Hand
Old Hand (395 reputation)Old Hand (395 reputation)Old Hand (395 reputation)Old Hand (395 reputation)Old Hand (395 reputation)Old Hand (395 reputation)Old Hand (395 reputation)Old Hand (395 reputation)

Group: General Forum Members
Points: 395 Visits: 59
We have a separate folder for each database, and a separate file for each backup. Backup files are stored on a separate hard disk and on tape. Having separate files for each backup, full, differential & transaction logs, allows us to quickly copy backups from one machine to another as we only need to copy the latest backup file.

Keith
edwardelliott
edwardelliott
SSC Veteran
SSC Veteran (235 reputation)SSC Veteran (235 reputation)SSC Veteran (235 reputation)SSC Veteran (235 reputation)SSC Veteran (235 reputation)SSC Veteran (235 reputation)SSC Veteran (235 reputation)SSC Veteran (235 reputation)

Group: General Forum Members
Points: 235 Visits: 351
The only time I put more than one backup in a file is when I am setting up mirroring and I put in the full then transaction log backup to save time.

For actual backup purposes I prefer to give each backup it's own file with the date and timestamp - this way if you need to restore you know exactly when the backup was taken.
SuperDBA-207096
SuperDBA-207096
SSCrazy
SSCrazy (2K reputation)SSCrazy (2K reputation)SSCrazy (2K reputation)SSCrazy (2K reputation)SSCrazy (2K reputation)SSCrazy (2K reputation)SSCrazy (2K reputation)SSCrazy (2K reputation)

Group: General Forum Members
Points: 2025 Visits: 711
Steve,
As a general rule, I backup to a different file every time - the only exception would be if I'm working in Dev or test to do an ad-hoc backup that I'm going to use once.

It's a good idea to keep at least a couple of backups on the machine in case something goes wrong for a quick restore... in some cases though there's just not enough disk!

Mark
Jason Miller-476791
Jason Miller-476791
SSC Veteran
SSC Veteran (222 reputation)SSC Veteran (222 reputation)SSC Veteran (222 reputation)SSC Veteran (222 reputation)SSC Veteran (222 reputation)SSC Veteran (222 reputation)SSC Veteran (222 reputation)SSC Veteran (222 reputation)

Group: General Forum Members
Points: 222 Visits: 694
I agree with your state concerning multiple backups in a single file. Even with all of the redundancies built into our infrastructure.

For our investment accounting system I created a procedure to dump the dbs (full) twice a day. Once before nightly processing, and once after. Then between the two, during the day, dump the transaction logs every 10 minutes.

The procedure tags all filenames with a time stamp. TSM copies all of the files to our DR site. I'm told intra-daily, not sure of the exact time frame. But we keep a rolling 3 days worth of files here, two weeks on disk at DR, and indefinately on tape at DR and also at Iron Mountain.

Honor Super Omnia-
Jason Miller
Ben Moorhouse
Ben Moorhouse
SSC Veteran
SSC Veteran (239 reputation)SSC Veteran (239 reputation)SSC Veteran (239 reputation)SSC Veteran (239 reputation)SSC Veteran (239 reputation)SSC Veteran (239 reputation)SSC Veteran (239 reputation)SSC Veteran (239 reputation)

Group: General Forum Members
Points: 239 Visits: 444
I do backups for various solutions - not just SQL server, and with every one I backup to individual files.
I just keep the filename format the same eg. ddmmyyyyDatabaseBackup.mdb = 13012009DatabaseBackup.mdb

This removes the single point of failure, and also makes it easy to delete the older files.
Because I use the same syntax, restores are easy because they can be scripted.
Jason Miller-476791
Jason Miller-476791
SSC Veteran
SSC Veteran (222 reputation)SSC Veteran (222 reputation)SSC Veteran (222 reputation)SSC Veteran (222 reputation)SSC Veteran (222 reputation)SSC Veteran (222 reputation)SSC Veteran (222 reputation)SSC Veteran (222 reputation)

Group: General Forum Members
Points: 222 Visits: 694
Ben Moorhouse (1/13/2009)
I do backups for various solutions - not just SQL server, and with every one I backup to individual files.
I just keep the filename format the same eg. ddmmyyyyDatabaseBackup.mdb = 13012009DatabaseBackup.mdb

This removes the single point of failure, and also makes it easy to delete the older files.
Because I use the same syntax, restores are easy because they can be scripted.



I prefer the dates YYYYMMDD easier to sort, at least for me.

Honor Super Omnia-
Jason Miller
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search